Please join us for the following tech talk:
Tech Talk: The Very Basics of Phabricator
Date: September 24
Time: 1800 UTC
<http://www.timeanddate.com/worldclock/fixedtime.html?msg=Phab+Tech+Talk&iso…>
Link to live YouTube stream <http://www.youtube.com/watch?v=-fpkHyCGX1Y>
IRC channel for questions: #wikimedia-office
Google+ page
<https://plus.google.com/u/0/b/103470172168784626509/events/c8qe7l0vtf4v6u07…>,
another
place for questions
Talk description:
Phabricator' will soon replace the task/issue tracking tools 'Bugzilla'
and 'RT' in Wikimedia. The planning tools 'Trello', 'Mingle' and the code
review tool 'Gerrit' will follow.
This session explains what's been going on lately and the plan for the next
weeks, in which RT and Bugzilla will be deprecated. We will provide a short
introduction to Phabricator's basic functionality, followed by answering
your questions.
Andre manages bug reports in Wikimedia's 'Bugzilla' and helps Chase and
Mukunda with migrating everything to Phabricator.
Thanks!
Rachel
All,
As you may have heard, Freenode found some compromised servers on their
networks. Network traffic, including SSL traffic, may have been sniffed by
a third party.
This likely affects many Wikimedia IRC users, including users who do not
speak English, so please forward this notice and translate as needed for
the benefit of other Wikimedians.
If you have not changed your nickserv password on September 15 or later,
please do so now.
>From the Freenode blog:
"Before changing your password, please check your email address in /msg
nickserv info and, if needed, update it – see /msg nickserv help set email
(remember to check your new email for the verification key). This will
ensure that we can send you a password reset email should, for whatever
reason, your password change not work properly. If you have no email set on
your account or an email set that you cannot access, we cannot send
password resets to you, so do please keep this up-to-date.
"To change your password use /msg nickserv set password newpasshere
"Since traffic may have been sniffed, you may also wish to consider any
channel keys or similar secret information exchanged over the network."
Please direct questions to Freenode IRC ops. They are voiced in the
#freenode channel.
Pine
tl,dr: MediaWiki needs a more human-friendly interface for using videos in
wiki pages. https://www.mediawiki.org/wiki/Extension:Video significantly
improves the video experience in MediaWiki. The extension is not
feature-complete yet, but *you* can help!
Now for the longer version:
Basically all video player extensions for MediaWiki are parser tags, and as
such, they're not the easiest to use, and some of the less popular ones
might have security issues and whatnot, given the lack of sufficient
attention from skilled developers. It's not obvious to the layperson that
<youtube>oUCEN-XvC7g</youtube> renders the YouTube video "First hands-on
with the Nokia X family", published by Nokia [1]. Better yet, choosing
"Embed" on YouTube gives you the following code snippet, which -- obviously
-- doesn't render the video on an average MediaWiki installation: <iframe
width="560" height="315" src="//www.youtube.com/embed/oUCEN-XvC7g"
frameborder="0" allowfullscreen></iframe>
David Pean (of ArmchairGM/social tools fame [2]) identified this problem
back in 2007 and he wrote the Video extension to solve the problem. Despite
being enabled on ArmchairGM until AGM was migrated to the standard Wikia
codebase (in late 2010/early 2011 [3]), this great extension was
unfortunately never quite finished, and while the basic concept mostly
works, plenty of areas could use developer attention to make this *the*
best video embedding extension out there for MediaWiki.
Unlike your average parser hook for embedding videos, the Video extension
adds a new Video: namespace and two special pages for handling videos.
Videos are added via Special:AddVideo, which doesn't actually upload the
underlying .flv/.mpg/.avi/.mp4/.whatever, but rather stores some metadata
about the video and uploader with the unique, user-supplied name. Therefore
after adding the video to the wiki via Special:AddVideo, [1] could be
embedded via syntax such as [[Video:First hands-on with the Nokia X
family|300px]] on a wiki page.
In late 2011 I published a cleaned-up version of the Video extension, and
John Du Hart signficantly improved the extension's architecture and reduced
code duplication. Despite this, the extension received basically only minor
maintenance commits until today/yesterday [4], when I got rid of some
legacy code and further improved the video undeletion workflow [5]. Certain
key elements are nevertheless missing from the extension's current
implementation and I know I'm not able to code all of these on my own,
which is precisely why I'm asking you to consider helping out with this
project.
Things such as Special:WhatLinksHere support for videos, better undeletion
code (the current implementation is a very dirty core hack that does the
job, but it's not what we want to aim for in the long run), more i18n,
support for *your* favorite video service...and of course, bug fixes such
as having the relevant caches correctly purged when a video is deleted so
that deleted videos no longer show up on pages that embed them, for example.
Some of the related, FOSS-licensed extensions from which code could be
borrowed include:
* WikiVid [6], a similar special page based approach to video embedding,
written by profilic MediaWiki developer Daniel Friesen (Dantman); never
finished, supports embedding via wiki link syntax and has some code related
to tracking which pages use which videos (the download link doesn't appear
to be working, but I have a copy of the source code if there's ever a need
for that)
* WikiaVideo [7], Wikia's older video extension which was at some point
enabled on all Wikia wikis (before being deprecated in favor of newer video
extensions). It seemed to have been based on David's Video extension,
though it required some core hacks [8] and whatnot. I'm not sure when it
got removed from the repository and I was too lazy to dig up the precise
date and/or commit, but the linked version should give you a general idea
of how the extension worked. Unlike David's Video extension, this extension
required no custom database tables, but it instead reused core tables such
as filearchive, image or oldimage for storing information about the videos.
An interesting approach, but nevertheless not the one I'd have gone with.
Some parts of WikiaVideo have already been incorporated into Video, such as
Hulu provider code (/extensions/Video/providers/HuluVideo.php) or some of
the Special:Undelete integration code
(/extensions/Video/VideoPageArchive.php).
Let's put the "media" back to "MediaWiki"!
[1] https://www.youtube.com/watch?v=oUCEN-XvC7g
[2] https://www.mediawiki.org/wiki/Social_tools
[3] http://wikiindex.org/ArmchairGM
[4] depending on your timezone, the position of the stars, and other
factors to take into consideration when dealing with dates and times
[5]
https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FVideo/68176b583de…
[6] https://www.mediawiki.org/wiki/Extension:WikiVid
[7]
https://github.com/svn2github/wikia/tree/673dadc4a2d47698589ac3294893f9163e…
[8]
https://github.com/svn2github/wikia/tree/673dadc4a2d47698589ac3294893f9163e…
Thanks and regards,
--
Jack Phoenix
MediaWiki developer
Hi, I had to switch computers the other day, which resulted in my having
to reinstall git-review, and now it... doesn't work. Basically there are
two problems: for every new repository I use, I now need to add a
commit-msg hook to the .git directory, and also ssh doesn't work at all,
so I have to use https login every time.
Does anyone know how to fix either of these? They are both incredibly
annoying and make it borderline unusable (in particular because I have
no idea what my password is).
Thanks.
-I
Several of the engineers and advisors developing components for front
end standardization met Friday to check status, set direction, and
identify upcoming obstacles
Big take aways:
= MediaWiki theme for OOjs UI =
* Should be finalized this week by Trevor and Bartosz
* Server side to follow in the next couple of weeks
= Icon system =
* Bartosz has done the early work for a Grunt task that takes SVGs
and a JSON config to generate colored SVG and PNG renderings and the
corresponding LESS markup for them
Notes and additional items from the discussion can be found on mw.org [1]
Follow up items:
* Generate prospective roadmap [Trevor]
* Raise Template RFC w/ arch committee and make a decision [Brion]
* Find out if Derk-Jan (cc'd) can join us next time
* Discuss Server-side OOUI at next meeting
Please update as necessary if you attended and I've forgotten or
misrepresented anything.
thanks all
--tomasz
[1] - https://www.mediawiki.org/wiki/FrontEndStandardsGroup/Weekly-Sept_19_2014
This week only, we will have a Thursday 21:00 UTC meeting to discuss
Aude's proposed Linker refactor:
<https://www.mediawiki.org/wiki/Requests_for_comment/Linker_refactor>
The time is:
* UTC: Thursday 21:00
* US PDT: Thursday 14:00
* Europe CEST: Thursday 23:00
* Australia AEST: Friday 07:00
Next week, it will be back to the usual time of Wednesday UTC.
A few hours ago, we discussed Andrew Wight's RFC "Page protection as a
component", with the few people who were in #wikimedia-office at the
usual time despite no meeting being announced. My apologies for the
lack of an announcement. Logs are available at:
<https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.20…>
-- Tim Starling
All,
Thanks to new architecture developments within the Memento Project, we are pleased to announce the availability of Version 1.0.0 of the Memento Headers time travel Extension for MediaWiki. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3].
This extension only supplies the headers necessary to work with Memento clients [4], and does not provide all of the features of Memento for a MediaWiki installation. it relies upon an external TimeGate server, provided online by the Memento Project, to actually provide the datetime negotiation necessary for web time travel.
Memento clients allow one to select a past date and time to browse, and then browse the web as if it were that date and time. Installing the Memento Headers extension in a MediaWiki installation allows Memento clients to seamlessly transition from using web archives to wikis, allowing one to view past versions of web pages without interruption.
Earlier today, we announced the availability of version 2.1.0 of the full Memento extension. That extension provides additional functionality, such as ensuring that old revisions of images and templates match the revision of the page in which they are embedded. The Memento Headers extension does NOT provide such functionality. The Memento Headers extension only provides the headers necessary for Memento clients to find the oldid pages in MediaWiki installations that best match the datetime requested by the user.
As noted in the earlier announcement, the Memento protocol is currently used by major web archives [5] and supported by the International Internet Presevation Consortium [6]. Though we have the support of web archives, the Memento team also considers time travel in MediaWiki to be a major use of the protocol. Videos [7] and [8] show Memento at work in the web at large, the latter paying attention to navigation within Wikipedia. Video [9] shows Memento at work in the full Memento MediaWiki extension.
We really look forward to any feedback the Wikimedia community can provide on this new exciting (though limited) way to provide and experience Memento.
On behalf of the Memento Team,
Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University
Email: sjone(a)cs.odu.edu
Research group: http://ws-dl.blogspot.com
Twitter: @shawnmjones
—
[1] https://github.com/mementoweb/mediawiki-memento-headers/releases/tag/v1.0.0
[2] https://www.mediawiki.org/wiki/Extension:MementoHeaders
[3] http://ws-dl-05.cs.odu.edu/demo-headers/index.php/Main_Page
[4] http://bit.ly/memento-for-chrome
[5] http://mementoweb.org/depot/
[6] http://netpreserve.org/
[7] http://www.youtube.com/watch?v=0_70lQPOOIg
[8] http://www.youtube.com/watch?v=WtZHKeFwjzk
[9] https://www.youtube.com/watch?v=ciClYjTnscs
All,
Thanks to a few informal code reviews, version 2.1.0 of the Memento time travel Extension for MediaWiki has been released. The extension can be downloaded via [1]. Information on the extension is available at [2]. A demonstration wiki equipped with the extension is available at [3].
This release incorporates changes to enrich the code based on additional review and feedback from members of the WikiMedia team. The extension fixed a few bugs, now supports the newer JSON-based i18n system, and has removed three configuration options in order to streamline the code.
We fully appreciate the feedback we’ve received and appreciate any additional feedback the community can provide. Our goal is to make the extension as solid as possible for MediaWiki users everywhere.
The extension works with Memento clients [4]. Memento clients allow one to select a past date and time to browse, and then browse the web as if it were that date and time. Installing this extension in a MediaWiki installation allows Memento clients to seamlessly transition from using web archives to wikis, allowing one to view the past versions of web pages without interruption. This has numerous applications, from avoiding spoilers [5] to studying the evolution of legal discourse.
Additionally, this extension attempts to address the issue of "temporal coherence", ensuring that old revisions of images and templates match the revision of the page they are embedded in. This functionality is still optional and experimental, but has received some interest from the community.
Earlier this summer, we presented our experiences with reconstructing the past using MediaWiki [6, 7], and demonstrated using the extension to avoid spoilers in Game of Thrones [8, 9, 10] at WikiConference USA 2014.
The extension is fully compliant with RFC 7089 [11], which specifies the Memento protocol. The effort was supported in part by the Andrew W. Mellon Foundation and is a joint effort between Old Dominion University and Los Alamos National Laboratory. Videos [12] and [13] show Memento at work in the web at large, the latter paying attention to navigation within Wikipedia.
The Memento protocol is currently used by major web archives [14] and supported by the International Internet Presevation Consortium [15]. Though we have the support of web archives, the Memento team also considers time travel in MediaWiki to be a major use of the protocol.
We really appreciate the feedback from the Wikimedia team and look forward to additional assistance and improvements.
Thank you again, on behalf of the Memento Team,
Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University
Email: sjone(a)cs.odu.edu
Research group: http://ws-dl.blogspot.com
Twitter: @shawnmjones
—
[1] https://github.com/mementoweb/mediawiki/releases/tag/v2.1.0
[2] https://www.mediawiki.org/wiki/Extension:Memento
[3] http://ws-dl-05.cs.odu.edu/demo/
[4] http://bit.ly/memento-for-chrome
[5] http://ws-dl.blogspot.com/2013/12/2013-12-18-avoiding-spoilers-with.html
[6] http://wikiconferenceusa.org/wiki/Submissions:Reconstructing_the_past_with_…
[7] http://www.slideshare.net/shawnmjones/reconstructing-the-past-with-media-wi…
[8] http://wikiconferenceusa.org/wiki/Submissions:Using_the_Memento_Mediawiki_E…
[9] http://www.slideshare.net/shawnmjones/using-the-memento-mediawiki-extension…
[10] https://www.youtube.com/watch?v=ciClYjTnscs
[11] http://tools.ietf.org/html/rfc7089
[12] http://www.youtube.com/watch?v=0_70lQPOOIg
[13] http://www.youtube.com/watch?v=WtZHKeFwjzk
[14] http://mementoweb.org/depot/
[15] http://netpreserve.org
Just a few thoughts:
* I agree that the tone of the email that started this discussion about
software quality standards was unnecessarily critical. Even in production
releases, users may find occasional bugs.
* The intent of HHVM implementation and James' quick response to the
problem report are nice to see.
* The perfect should not be the enemy of the good, especially for opt-in
pre-production releases.
* Regarding standards for different release phases, I would need to think
more about that but hope that someone will set up a proposed checklist on
MediaWiki.org. We have some quality experts like Chris McMahon and their
input would be helpful.
Pine