Hello and welcome to the latest edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_1st>
A quick list of notable items...
== Monday ==
US Holiday (Labor Day), thus no deploys
== Tuesday ==
* Commons to will get the new CirrusSearch as the primary search engine
** <https://www.mediawiki.org/wiki/Search>
* MediaWiki deploy
** group1 to 1.24wmf19: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf19>
== Wednesday ==
* Weekly fundraising banner test
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf19 (all Wikipedias)
** group0 to 1.24wmf20 (test/test2/testwikidata/mediawiki)
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Answer inline!
On Fri, Aug 29, 2014 at 10:51 AM, <
wikitech-ambassadors-request(a)lists.wikimedia.org> wrote:
>
> 5. Re: Community Consultation for Media Viewer now live (Kim
> Bruning)
>
> ------------------------------
>
> Message: 5
> Date: Fri, 29 Aug 2014 09:33:35 +0200
> From: Kim Bruning <kim(a)bruning.xs4all.nl>
> To: Coordination of technology deployments across languages/projects
> <wikitech-ambassadors(a)lists.wikimedia.org>
> Cc: translators-l(a)lists.wikimedia.org
> Subject: Re: [Wikitech-ambassadors] Community Consultation for Media
> Viewer now live
> Message-ID: <20140829093335.A12879(a)bruning.lan>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hmm...
> This consultation presents Media Viewer as a Fait Accompli.
>
> when this is addressed on talk, there's an answer like:
> "Hi Daniele, please notice this is not intended as a forum to
> discuss WMF's general behaviour".
>
> Might be wise to back off or modify the wmf's stated position a bit.
>
>
Hi Kim,
I hope to clarify this a bit: this is not Yet Another Page to express one's
general opinions/feelings about MediaViewer. If people want to talk to
Lila, Erik, and so on, there are lots of better venues to do so and which
users have already discovered in these weeks: this instead is a place for
direct communication aimed at the *Multimedia team*, for clear requests
that that team can act upon.
Unlike regular feedback pages, this is a consultation which will "identify
any critical issues with this new experience", or, the way Erik puts it,
"[...] the listed planned improvements
<https://meta.wikimedia.org/wiki/Community_Engagement_(Product)/Media_Viewer…>
[...]
are based both on user feedback, survey data and user testing. This
consultation is more about "If we do these things, what's left that is
really important to you?" For example, did we overlook something? Let us
know!
That's why we ask that the users "be specific about what problem the
suggestion would solve, whom it would help, and for what purpose (viewing,
editing, re-using files, etc.)".
WMF staff will need to review /proposals/ and sort them (more info about
how this will be done on the consultation page itself). As much as I can
understand/sympathize with complaints, or compliments!, those are not items
I can put in a list of things which MV should, could or must have :)
Also, at the top of the page I read that "If agreed upon critical issues
cannot be resolved in the near term, the Wikimedia Foundation will
temporarily move the feature back into opt-in beta globally". If MV was
really a Fait Accompli, that wouldn't be there, IMHO.
Suggestions about improvements to the pages are definitely welcome.
HTH!
Erica
Elitre (WMF)
> Politically speaking: it is wise to take pains not to treat something as a
> fait accompli, even or especially when you would like for it to be so.
> ;-)
>
> Otherwise, some people may feel like they are cornered, and that they
> *have* to fight [*]. Always leave an "out" so they can feel safe and thus
> stay reasonable.
>
> sincerely,
> Kim Bruning
>
> [*] For folks who get the heebie jeebies talking about feelings,
> pretend that by "some people" I may actually mean utility-optimizing
> (bounded) rational agents. Obv, don't make the only optimal reply be "Have
> at
> ye!"
>
> ( ps In general I think it would be rather wise if projects were actually
> co-initiated by WMF&Community, in that case you don't get
> situations like this. As of 2014 afaik there's still no clear on-wiki
> pathway to rq features/changes? If I missed it, I'd promote that to
> pieces!)
>
Greetings,
Please note that the time of the IRC chat was changed to 18:00 (UTC)
i.e. one hour earlier than previously announced. (
https://commons.wikimedia.org/w/index.php?diff=next&oldid=132667852 )
You can see how it converts to your timezone using this tool:
http://www.timeanddate.com/worldclock/fixedtime.html?msg=Structured+Data+IR…
On Fri, Aug 22, 2014 at 10:48 AM, Fabrice Florin <fflorin(a)wikimedia.org> wrote:
> Greetings!
>
> We invite you to join a discussion about Structured Data on Commons, to help
> us plan our next steps for this project.
>
> The Structured Data initiative proposes to store and retrieve information
> for media files in machine-readable data on Wikimedia Commons, using
> Wikidata tools and practices, as described on our new project page (1).
>
> The purpose of this project is to make it easier for users to read and write
> file information, and to enable developers to build better tools to view,
> search, edit, curate and use media files. To that end, we propose to
> investigate this opportunity together through community discussions and
> small experiments. If these initial tests are successful, we would develop
> new tools and practices for structured data, then work with our communities
> to gradually migrate unstructured data into a machine-readable format over
> time.
>
> The Multimedia team and the Wikidata team are starting to plan this project
> together, in collaboration with many community volunteers active on
> Wikimedia Commons and other wikis. We had a truly inspiring roundtable
> discussion about Structured Data at Wikimania a few weeks ago, to define a
> first proposal together (2).
>
> We would now like to extend this discussion to include more community
> members that might benefit from this initiative. Please take a moment to
> read the project overview on Commons, then let us know what you think, by
> answering some of the questions on its talk page (3).
>
> We also invite you to join a Structured Data Q&A on Wednesday September 3 at
> 19:00 UTC, so we can discuss some of the details live in this IRC office
> hours chat. Please RSVP if you plan to attend (4).
>
> Lastly, we propose to form small workgroups to investigate workflows, data
> structure, research, platform, features, migration and other open issues. If
> you are interested in contributing to one of these workgroups, we invite you
> to sign up on directly on our hub page (5) -- and help start a sub-page for
> your workgroup.
>
> We look forward to some productive discussions with you in coming weeks. In
> previous roundtables, many of you told us this is the most important
> contribution that our team can make to support multimedia in coming years.
> We heard you loud and clear and are happy to devote more resources to bring
> it to life, with your help.
>
> We are honored to be working with the Wikidata team and talented community
> members like you to take on this challenge, improve our infrastructure and
> provide a better experience for all our users.
>
> Onward!
>
>
> Fabrice — for the Structured Data team
>
>
> (1) Structured Data Hub on Commons:
> https://commons.wikimedia.org/wiki/Commons:Structured_data
>
> (2) Structured Data Slides:
> https://commons.wikimedia.org/wiki/File:Structured_Data_-_Slides.pdf
>
> (3) Structured Data Talk Page:
> https://commons.wikimedia.org/wiki/Commons_talk:Structured_data
>
> (4) Structured Data Q&A (IRC chat on Sep. 3):
> https://commons.wikimedia.org/wiki/Commons:Structured_data#Discussions
>
> (5) Structured Data Workgroups:
> https://commons.wikimedia.org/wiki/Commons:Structured_data#Workgroups
>
>
> _______________________________
>
> Fabrice Florin
> Product Manager, Multimedia
> Wikimedia Foundation
>
> https://www.mediawiki.org/wiki/User:Fabrice_Florin_(WMF)
--
Guillaume Paumier
Hi all,
A community consultation about the new Media Viewer software feature is
taking place at [1], until September 7. The Wikimedia Foundation hopes to
hear your suggestions for improvement of the editor and reader experience,
focusing on the most urgent needs for the tool. We encourage you all to
participate, and welcome contributions and suggestions that work towards
improving the experience for all.
Discussions are in English, but you can contribute feedback in other
languages.
Thank you,
rachel
[1]
https://meta.wikimedia.org/wiki/Community_Engagement_%28Product%29/Media_Vi…
--
Rachel diCerbo
Director of Community Engagement (Product)
Wikimedia Foundation
Rdicerb (WMF) <https://wikimediafoundation.org/wiki/User:Rdicerb_%28WMF%29>
@a_rachel <https://twitter.com/a_rachel>
Hi,
The report covering Wikimedia engineering activities in July 2014 is now
available.
Wiki version:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July
Blog version:
https://blog.wikimedia.org/2014/08/26/engineering-report-july-2014/
We're also proposing a shorter version of this report focusing on priority
goals for this quarter:
https://www.mediawiki.org/wiki/Wikimedia_Engineering/Report/2014/July/summa…
Below is the HTML text of the report's summary.
As always, feedback is appreciated on the usefulness of the report and its
summary, and on how to improve them.
------------------------------------------------------------------
Major news in July include:
- a recap of how the Operations team collaborated with the RIPE NCC
<https://blog.wikimedia.org/2014/07/09/how-ripe-atlas-helped-wikipedia-users/>
to
measure the delivery of Wikimedia sites to users in Asia and elsewhere;
- an analysis of the impact of the San Francisco data center
<https://blog.wikimedia.org/2014/07/11/making-wikimedia-sites-faster/> on
the speed of Wikimedia sites;
- the launch of the new native Wikipedia app for iOS
<https://blog.wikimedia.org/2014/07/31/official-wikipedia-app-available-on-i…>
;
- a first look at the content translation tool
<https://blog.wikimedia.org/2014/07/16/first-look-at-the-content-translation…>
.
HHVM <https://www.mediawiki.org/wiki/HHVM>
HHVM (HipHop Virtual Machine
<https://en.wikipedia.org/wiki/HipHop_Virtual_Machine>) is aimed to improve
the speed of Wikimedia sites. The Beta cluster
<https://www.mediawiki.org/wiki/Beta_cluster> (the testing environment that
best simulates our sites) is now running HHVM. The latest MediaWiki-Vagrant
<https://www.mediawiki.org/wiki/MediaWiki-Vagrant> and Labs-vagrant
<https://wikitech.wikimedia.org/wiki/Labs-vagrant> (virtual machine
environments that make it easier for developers to apply their code to
Wikimedia sites) use HHVM by default.
Mobile Apps <https://www.mediawiki.org/wiki/Wikimedia_Apps>
In July, the Mobile Apps team launched the new native iOS Wikipedia app,
following on from the successful launch of the Android app in June. The app
has the same features as the Android app, including the ability to edit
both anonymously and logged in, saved pages for offline reading, and your
recently visited pages. The iOS app also contains an onboarding screen
which is displayed the first time the app is launched, asking users to sign
up. An update to the Android app was released, containing the Android
version of the onboarding screen, as well as a a night mode for reading in
dark environments, a font size selector, and a references display that
makes browsing references easier. Next month, the team plans to continue
improvements to page styling, and begin designing a dialogue that displays
the first time a user taps edit to help them make their edit successfully.
Mobile Web <https://www.mediawiki.org/wiki/Mobile_web_projects>
This month, the team continued to focus on wrapping up the collaboration
with the Editing team to bring VisualEditor to tablet users on the mobile
site. We also began working to design and prototype our first new Wikidata
contribution stream, which we will build and test with users on the beta
site in the coming month.
Flow <https://www.mediawiki.org/wiki/Flow>
In July, the Flow team built the ability for users to subscribe to
individual Flow discussions, instead of following an entire page of
conversations. Subscribing to an individual thread is automatic for users
who create or reply to the thread, and users can choose to subscribe (or
unsubscribe) by clicking a star icon in the conversation's header box.
Users who are subscribed to a thread receive notifications about any
replies or activity in that thread. To support the new
subscription/notification system, the team created a new namespace, Topic,
which is the new "permalink" URL for discussion threads; when a user clicks
on a notification, the target link will be the Topic page, with the new
messages highlighted with a color. The team is currently building a new
read/unread state for Flow notifications, to help users keep track of the
active discussion topics that they're subscribed to.
VisualEditor <https://www.mediawiki.org/wiki/VisualEditor>
In July, the team working on VisualEditor converged the mobile and desktop
designs, made it possible to see and edit HTML comments, improved access to
re-using citations, and fixed over 120 bugs and tickets
<https://bugzilla.wikimedia.org/buglist.cgi?list_id=333021&order=priority%2C…>.
The team also expanded its scope to cover all MediaWiki editing tools as
well, as the new Editing Team.
The new design is possible due to the significant progress made in
cross-platform support in the interface code. This now provides
responsively-sized windows that can work on desktop, tablet and phone with
the same code. HTML comments are occasionally used to alert editors to
contentious issues without disrupting articles for readers. Making them
prominently visible avoids editors accidentally stepping over expected
limits. Re-using citations with its simple dialog is now available in the
toolbar so that it is easier for users to find.
Other improvements include an array of performance fixes targeted at
helping mobile users especially. We fixed several minor instances where
VisualEditor would corrupt the page. We also installed better monitoring of
corruptions if they occur. The mobile version of VisualEditor, currently
available for beta testers, moved towards stable release. We fixed some
bugs and editing issues, and improving loading performance. Our work to
support languages made some significant gains, nearing the completion of a
major task to support IME <https://en.wikipedia.org/wiki/Input_method> users.
The work to support Internet Explorer uncovered some more issues as well as
fixes.
SUL finalization <https://www.mediawiki.org/wiki/SUL_finalisation>
In July, the SUL finalisation team worked on developing features to ease
the workload that the finalisation will place on the community, and to
minimise the impact on those users that are affected. A feature is being
developed that allows users to log in with their pre-finalisation
credentials, so that everyone who is affected is still able to access their
account; this feature is mostly complete from a back-end engineering
standpoint but now needs design and product refinement, and will hopefully
be completed by late August. A feature to globally rename users in a manner
that does not create clashing accounts was completed and deployed. A
feature is being developed to allow accounts to be globally merged, so that
clashing local-only accounts that were globalised by the finalisation can
be consolidated into a single global account; this feature is in the early
stages of implementation and no estimate is possible at this time. A
feature is being developed to allow local-only account holders to request
rename and globalisation before the finalisation, and also feeds these
rename requests to the appropriate community processes in a manner that
reduces the workload of community; this feature is in the design phase, and
will likely be ready for implementation in early August.
Phabricator migration
<https://www.mediawiki.org/wiki/Phabricator/Migration>
Phabricator's "Legalpad" application (a tool to manage trusted users
<http://fab.wmflabs.org/T364>) was set up on a separate server that
provides provides Single-User Login authentication with wiki credentials.
We implemented the ability to restrict access to tasks in a certain project
<http://fab.wmflabs.org/T95> and worked on initial migration code to import
data from Bugzilla reports into Phabricator tasks. We also set up a data
backup system for Phabricator, and upgraded the dedicated Phabricator
server to Ubuntu Trusty. A more detailedsummary email
<http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077684.html> about
the status of the Phabricator migration was sent to wikitech-l.
MediaWiki core front-end libraries
<https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework>
In July, the Request for comment for refactoring MediaWiki's skin system
(which handles the appearance of wiki sites) was re-written and discussed
with members of the community and staff. Work on the proposed system is
scheduled to begin in August, alongside creating an Agora
<https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design> theme for, and
server-side version of, OOjs UI <https://www.mediawiki.org/wiki/OOjs_UI>, a
toolkit used to compose complex widgets. In addition to the RfC work, a
well-attended meeting was held for teams using or considering using OOjs
UI, including Editing, Multimedia and Growth. From that meeting, several
issues were identified as blockers to increased acceptance of the toolkit.
The most prominent blocker is the lack of an Agora theme for OOjs UI at
this time. Creating this theme has thus been prioritized and will be
completed as soon as possible. The Design team
<https://www.mediawiki.org/wiki/Design> has committed to delivering
necessary assets by mid-August. Discussion about changes to OOjs UI also
surfaced the desire to be able to create widgets on the server and then
bind to them on the client (a feature proposed as part of the skinning
RfC). This functionality is thus now planned to be implemented in OOjs UI
before the skin refactoring begins.
Metrics and dashboards standardization
<https://www.mediawiki.org/wiki/Analytics/Research_and_Data>
This month we completed the documentation for the Active Editor Model
<https://meta.wikimedia.org/wiki/Research:Modeling_monthly_active_editors>,
a set of metrics for observing sub-population trends and setting product
team goals. We also engaged in further work on the new page views
definition. An interim solution for Limited-duration Unique Client
Identifiers (LUCIDs) was also developed and passed to the Analytics
Engineering team for review.
We analyzed trends in mobile readership and contributions, with a
particular focus on the tablet switchover and the release of the native
Android app. We found
<https://meta.wikimedia.org/wiki/Research:Mobile_editor_engagement/Editor_ac…>
that
in the first half of 2014 mobile surpassed desktop in the rate at which new
registered users become first-time editors and first-time active editors in
many major projects, including the English Wikipedia. An update on mobile
trends will be presented at the upcoming Monthly Metrics meeting on July 31.
Content API <https://www.mediawiki.org/wiki/Services>
The brand new Services <https://www.mediawiki.org/wiki/Services> group
started design and prototyping work on the storage service
<https://www.mediawiki.org/wiki/Requests_for_comment/Storage_service> (see
code <https://github.com/gwicke/rashomon>) and REST API
<https://www.mediawiki.org/wiki/Requests_for_comment/Content_API> (see code
<https://github.com/gwicke/restface>). The storage service now has early
support for bucket creation and multiple bucket types. We decided to
configure the storage service as a back-end for the REST API server. This
means that all requests will be sent to the REST API, which will then route
them to the appropriate storage service without network overhead. This
design lets us keep the storage service buckets very general by adding
entry point specific logic in front-end handlers. The interface is still
well-defined in terms of HTTP requests, so it remains straightforward to
run the storage service as a separate process. We refined the bucket design
to allow us to add features very similar to Amazon DynamoDB
<https://en.wikipedia.org/wiki/Amazon_DynamoDB> in a future iteration.
There is also an early design for light-weight HTTP transaction support.
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
Sorry for the short notice, but later today we will be deploying an update
that will redirect tablet users by default to the MobileFrontend interface
(which has been updated to better accommodate tablets). Users can still
switch back to the desktop interface if they prefer it.
There is one minor local update that we want project administrators to make
that is related to this update. Please edit your local instance of the
MediaWiki:Mobile-frontend-terms-url to include the URL to the mobile
version of the WMF Terms of Use in your language. The links to the
translations can be found at
https://m.wikimediafoundation.org/wiki/Terms_of_Use.
For example, I went ahead and set
https://de.wikipedia.org/wiki/MediaWiki:Mobile-frontend-terms-url to:
//m.wikimediafoundation.org/wiki/Terms_of_Use/de
This will enable the Terms of Use link at the bottom of each page in the
mobile/tablet interface.
More information about the tablet redirect will be posted to the WMF blog
later today.
Regards,
Ryan Kaldari
Hi,
I am excited to announce that on Tuesday, August 26, we will be
deploying the GlobalCssJs extension,[1] which enables per-user
JavaScript and CSS across public Wikimedia wikis. Users will be able to
create global.js[2] and global.css[3] subpages on Meta-Wiki and these
pages will automatically be loaded across all public Wikimedia wikis.
There is documentation available[4] if you want to load JavaScript on a
subset of all wikis (e.g., all Wikisources, all French language
projects, etc.).
Some users currently have manually set up global JavaScript/CSS by
creating local user subpages (e.g., monobook.js/css subpages) to load
their global scripts. For these users, the deployment of the extension
will mean that modules will be loaded twice, and they will no longer be
included in global scope[5]. A script has been prepared to delete these
page if they were created in the standard format. Users can signup at a
Meta-Wiki page[6] to have this done on their behalf once the extension
is deployed.
Thanks,
-- Legoktm
[1] https://www.mediawiki.org/wiki/Extension:GlobalCssJs
[2] https://meta.wikimedia.org/wiki/Special:MyPage/global.js
[3] https://meta.wikimedia.org/wiki/Special:MyPage/global.css
[4] https://www.mediawiki.org/wiki/Help:Extension:GlobalCssJs
[5] https://www.mediawiki.org/wiki/Help:Extension:GlobalCssJs#Variables
[6] https://meta.wikimedia.org/wiki/GlobalCssJs
Hey folks :)
Just an update on badges support on Wikidata. We will be rolling out
support for badges on Wikidata on August 19th. At this point you will
be able to store the information that a given article is a good or
featured article on English Wikipedia for example. More badges can be
added on request. One week later we will enable showing those badges
on Wikipedia/Wikisource/Wikiquote in the language links in the
sidebar.
If your Wikipedia wants them to be removed from the wikitext please
get in touch with Amir. He has a bot to do it for you.
You can try out the Wikidata-side of it on our test system:
https://test.wikidata.org/wiki/Q296
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.