*https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-05-17
<https://www.mediawiki.org/wiki/Scrum_of_scrums/2017-05-17>*
*= 2017-05-17 =*
== Call outs:==
* Please comment on the Reading team's Reading List service RfC:
https://phabricator.wikimedia.org/T164990
* Please update extensions you maintain to add a compatibility policy!
** see https://lists.wikimedia.org/pipermail/wikitech-l/2017-May/088190.html
** if you are not sure, just go with 'rel'
== Reading ==
=== Web ===
* Dealing with fallout from Parser element update.
* Some wikiove: Thank to RelEng for your assistance and SWAT deploys to
return things to normal <3
* Some prevalent log errors fixed.
* Investigating EventLogging duplication bugs with a view to looping in
Analytics.
* Upcoming: We'll be deploying some print styles to the mobile site for
offline use cases; We will be setting up a TextExtracts HTML service (
https://phabricator.wikimedia.org/T165017 ) on REST.
==== Reading Infrastructure ====
* Reading List service RfC: https://phabricator.wikimedia.org/T164990
* doc day: compatibility policy field for mw.org {{Extension}} template
** see https://lists.wikimedia.org/pipermail/wikitech-l/2017-May/088190.html
** please update your extensions pages! (if you are not sure just go with
'rel' )
* Page Content Service planning
==== Android ====
* Breakage related to parser output change appears all clear.
* CSS/JS cross-platform integration work continues.
* Beta release planned for next week.
* Current release board:
https://phabricator.wikimedia.org/project/view/2352/
==== iOS ====
* Last Week
** 5.5 - https://phabricator.wikimedia.org/project/view/2602/
*** Enhanced search visibility: https://phabricator.wikimedia.org/T130159
*** Update feed design: https://phabricator.wikimedia.org/T141767
* This Week
** 5.5 - https://phabricator.wikimedia.org/project/view/2602/
*** Analytics https://phabricator.wikimedia.org/T164801
*** Update `In the news` feed logic and design:
https://phabricator.wikimedia.org/T148739
*** Other bug fixes & enhancements
== Editing ==
=== Parsing ===
* https://gerrit.wikimedia.org/r/#/c/333997/ will be merged next week
(minor breaking change in preprocessor -- announcement in tech news 2 weeks
+ editors have been fixing up affected pages)
* Linter fixes necessary to redeploy it on large wikis not yet complete --
expecting to have them done end of week
* This update is a repetition of what has already been mentioned on the
relevant gerrit patches and phab tickets. Parsoid can now handle the
mw-parser-output <div> core change -- by requesting the api to not wrap
output of action=parse. The ParsoidBatchAPI change to do this is part of
1.30.0-wmf.2 and needs to ride the m/w train with the corresponding core
patch.
* https://gerrit.wikimedia.org/r/#/c/354059/ <-- heads up to Flow, CX, VE,
MCS folks; require a +1 from you all
=== Language ===
* No blockers.
* ContentTranslation OOjs UI migration continue.
* CX API end point migration work in progress in services team.
== Research ==
* Reader segmentation test survey went out on 15 May
** https://phabricator.wikimedia.org/T131949
== German Technical Wishlist ==
* Preparing for the Vienna Hackathon.
* RevisionSlider is now a default feature on all wikis.
== Wikidata ==
* Preparing for the Vienna Hackathon.
* Had to work around a Travis/HHVM bug:
https://gerrit.wikimedia.org/r/353872
* Cleaning up user-facing messages in the constraint checks API:
https://phabricator.wikimedia.org/T164354
* Moving forward with the "forms of a lexeme entity" UI:
https://phabricator.wikimedia.org/T160052
== Fundraising Tech ==
* Looking at disabling TLS1.0 - PCI has deprecated it for a while now
** What is the plan for the main cluster?
* Updating thank you letters and sending code
* Fixing currency display in Civi
* Library-ization work
* Preparing for a decent-sized CentralNotice deploy
== Technical Operations ==
* '''Blocking'''
** None
* '''Blocked'''
** No one
* Updates
** Work ongoing on goals (Kubernetes, SE Asia caching PoP, Swift)
** SMW has been removed from wikitech
** Preliminary support for Debian Stretch in labs (on a per project basis)
** HHVM 3.18 rolled out in production
- my apologies for cross-posting -
Hey all,
tomorrow the RevisionSlider [1] will be available as a default feature for
all users on all wikis. The RevisionSlider adds a slider view to the diff
page so that you can easily move between revisions. The slider view is
collapsed by default, and will load by clicking on it. It can also be
turned off entirely in the user preferences. The RevisionSlider has been a
default feature on German, Arabic and Hebrew Wikipedia for 6 months and a
beta feature on all wikis for 8 months. In addition to the users of the
default feature, the extension is used by more than 38K beta feature users
[2] and we have spent the past months addressing the issues raised.
The feature fulfills a wish from the German Community’s Technical Wishlist
[3], is inspired by DerHexer's revisionjumper gadget [4] and based on a
prototype <https://meta.wikimedia.org/wiki/Community_Tech/RevisionSlider>by
the WMF's Community Tech Team
<https://meta.wikimedia.org/wiki/Community_Tech> [5].
Thanks to everyone who tested RevisionSlider and gave valuable feedback to
improve the feature! We hope that RevisionSlider will continue to serve all
contributors well.
Lea (for WMDE's Technical Wishes team)
[1] https://www.mediawiki.org/wiki/Extension:RevisionSlider
[2] https://grafana.wikimedia.org/dashboard/db/mediawiki-revisionslider
[3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes
[4] https://en.wikipedia.org/wiki/User:DerHexer/revisionjumper
[5] https://meta.wikimedia.org/wiki/Community_Tech/RevisionSlider
--
Lea Voget
Product Manager Technical Wishlist
Produktmanager Technische Wunschliste
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi, the Wikimedia Foundation has published a draft of its Annual Plan
FY2017-18
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/…>
and it welcomes your review.
I want to highlight here the improvements that we are proposing to the
developer events (co)organized by the WMF. From local to global:
The Technical Collaboration team proposes to combine multiple activities
(often disconnected) in a single program focusing on onboarding new
developers
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/…>.
We
want to work with the Wikimedia technical community to bring a new wave of
developers to our projects, and events play an important role.
Local developer events
We want to support developers and organizations willing to reach out to
specific groups and geographies. We are hoping to see many local developer
meetups and small hackathons or workshops around the World, starting small
and simple. We should be able to offer introductory materials, contacts
with Wikimedia developers in the region, maybe travel budget to send
experienced volunteers to help mentoring the in the bigger events, maybe
travel budget to invite the best newcomers to our regional and global
events.
Adding tech to regional Wikimedia events
Last year we experimented organizing technical workshops in WikiArabia, and
others have done similar efforts in other regional events (for instance, a
small hackathon next to WikiConference India). We want to work with the
organizers of these regional events in order to attract experienced
Wikimedia developers and newcomers, organize developer activities, and also
improve the collaboration between the technical and non-technical
contributors in these regions.
Better retention of newcomers at the Wikimedia and Wikimania hackathons
Although we don't expect major changes in the organization of the Wikimedia
Hackathon and the hackathon at Wikimania, we want to focus better on new
developers onboarding and retention. In every Hackathon we meet many new
developers, but the retention rates are very low. We want to review what we
can do before, during, and after these apparently successful events in
order to retain newcomers better. One hypothesis is that we should focus
call for participation, scholarships, and Wikimedia Foundation
participation in providing a great experience to new volunteers who have
gone through local and regional events, and also "junior" developers coming
from wiki projects through the development of bots, gadgets, tools,
templates.
A smaller and more focused Wikimedia Developer Summit
After some discussions between Community Engagement, Technology, and
Product, we have decided to propose a different approach for the Wikimedia
Developer Summit. Organized by the Technology department as part of
their technical
community building
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2017-2018/…>
efforts, we want the Summit to finally become the venue where the toughest
technical problems are discussed between the stakeholders directly related.
We want to reduce the size/budget of the event, separate it from the WMF
AllHands, and define its main themes well in advance.
A Program Committee <https://phabricator.wikimedia.org/T160996> would
decide these main themes to be discussed at the Summit. We also want to
explore the possibility of tackling some of these themes at the Wikimedia
Hackathon and Wikimania, where we could get most stakeholders involved with
just a little extra effort (since many of them would be attending anyway).
We believe that this approach will serve better the Wikimedia technical
community that we have, and also the the community that we want to have,
with a new wave of developers joining our various projects.
--
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Hi all,
you can now declare in the extension infobox what compatibility policy is
being followed. Most extensions follow one of two policies:
* The master branch of the extension should remain compatible with older
versions of MediaWiki core (supported versions, maybe even older ones).
Developers updating the extension after a core change are expected to leave
B/C code so that the extension keeps working with both versions of core.
Users of the extension should use the master branch no matter what core
version they are running (unless it is really old, in which case they are
on their own).
* Extension release branches (REL1_XX branches, which are created
automatically if the extension is hosted on gerrit) are compatible with
matching core branches. Developers updating the extension after a core
change are free to remove old logic, but should backport security fixes to
supported branches. Users of the extension should use master with MediaWiki
master, and the corresponding branch with a MediaWiki release (e.g. the
REL1_27 extension branch if they use MediaWiki 1.27).
For extensions you maintain, please add the right template parameter to
{{Extension}}:
|compatibility policy = master
or
|compatibility policy = rel
This will be a great help to developers who are doing mass extension
changes after a breaking core change.
For more details, see https://phabricator.wikimedia.org/T156500
During the Q&A yesterday, Victoria mentioned information provided to her by
the MediaWiki Stakeholders' Group and other attendees at EMWCon, the
Enterprise MediaWiki conference held in March 2017. At the conference,
Victoria Coleman asked the attendees for their input on how the third-party
MediaWiki community benefits the Wikimedia Foundation and what support that
community would like from the Foundation. A group of EMWCon attendees
worked together at the EMWCon Create Camp the last day of the conference
and continued their discussion electronically the following week. The
result of these discussions including some recent updates is the write-up
below. The contributors include (listed alphabetically): Cindy Cicalese,
Bernadette Clemente, Bryan Davis, Markus Glaser, Richard Heigl, Mark
Hershberger, Chris Koerner, James Montalvo, Tobias Oetterer, Lex Sulzer,
Gergő Tisza, Daren Welsh, and Brian Wolff. [Please note that James and
Daren participated in this discussion as individuals, not on behalf of
NASA.]
--------------
What is the third-party MediaWiki community, and how does it benefit the
Wikimedia Foundation?
A substantial, growing community of MediaWiki users and developers outside
the Wikimedia movement has evolved, creating wikis that vary in size,
number of editors, number of readers, access restrictions, and activity.
The benefits of this third-party community to the Wikimedia Foundation
include:
- A direct contribution to the Wikimedia mission: One of the many
third-party uses of MediaWiki is to collect and develop free educational
content. The amount of such content produced by non-Wikimedia wikis is
roughly comparable to that of Wikimedia wikis [0]. Wikis like Appropedia or
the Geek Feminism Wiki offer important, if narrow, contributions to the
body of free knowledge. The Wikimedia movement currently does not have the
capacity to provide in-depth content for similar niche topics; and these
projects lack alternatives to MediaWiki without increased costs, lower
quality, or a significantly less open content production model.
- A larger and healthier developer community:
- More developers: Third-party MediaWiki developers
contribute new features - visualizations, data management, integration with
external data sources and data formats, and more - through core patches and
new extensions [1]. While community health statistics are not yet fully
reliable, preliminary data shows that about half of all Wikimedia git
commits for all repos hosted by Wikimedia come from independent developers
[2]. For MediaWiki core, third-party developers seem to account for a
quarter of the commits and third of the pull requests. Anecdotally, many
experienced MediaWiki developers got involved by starting their own wiki,
and better support for MediaWiki as generic free wiki software would likely
increase the number of such developers. This is especially important as the
current developer community seems to be on an unsustainable course [3].
- More resources: Enterprise use of MediaWiki provides an
alternative source of funding for MediaWiki development. With the Wikimedia
Foundation hitting fundraising limits despite increasingly aggressive
banner campaigns, this might help prevent funding from becoming a
bottleneck in the growth of MediaWiki.
- More diversity: Use of MediaWiki outside Wikimedia
projects, especially in enterprise settings, results in the involvement of
professionals with backgrounds atypical to Wikimedia projects and the
Wikimedia Foundation (e.g. knowledge management professionals) which leads
to a greater diversity of backgrounds and expertise in the community.
- More testing: More eyes make MediaWiki bugs more likely
to be revealed. By exercising the software in different ways with
additional extensions beyond those that the Wikimedia project wikis use,
bugs are discovered that might not otherwise be detected. Some large
organizations using MediaWiki have their own IT departments that perform
information security or accessibility reviews of MediaWiki code that
surface vulnerabilities and other issues. Once found, third-party
developers often contribute patches to address these bugs and issues.
- Increased innovation and editor retention in the Wikimedia editor
community: The wide variety of different third-party use cases present
different perspectives that feed fresh ideas back into the Wikimedia
community for novel approaches to knowledge creation, management, and
delivery as well as new user engagement and retention. Users of third-party
wikis are an untapped resource from which the Wikimedia Foundation can
learn. Observing such users interacting with third-party wikis spurs
innovation to the benefit of the Wikimedia community. Such users also find
it much easier to adapt to the Wikipedia user interface and social norms.
Imagine someone coming to Wikipedia and thinking, “I can edit this. It’s
just like at work.” Users of enterprise wikis often tend to be
subject-matter experts, a highly desirable demographic for Wikipedia.
--------------
What organizations use MediaWiki, and what are third-party wikis used for?
In 2015, the MediaWiki Stakeholders’ Group surveyed third-party users of
MediaWiki [4]. While the typical respondents to that survey were from
small organizations with 25 or less people, the close to forty attendees of
the recent EMWCon Spring 2017 conference tended to be from much larger
organizations [5]. These included:
- NASA: Seventeen wikis functioning both as historical documents as well as
collaborative workspaces supporting real time International Space Station
operations
- Intellipedia: the go to reference place in the United States intelligence
community with 350 million page views since its inception
- Diplopedia: United States Department of State wiki with 100,000 users
- Statipedia: United States government statistics agency wiki for
scientific and administrative information and glossaries
- Maryland Department of Transportation: an internal policy manual for
12,000 employees and an external resource for engineering and regulation
management modeled after the wikis at the Missouri and Michigan Departments
of Transportation
- MITRE: 80+ unique wikis to support blast injury preventions standards
recommendation, science and technology investment roadmapping, specialized
software tool catalogues, task planning, process workflow, job placement,
malware attribution enumeration and characterization, network operations
best practices, etc.
- VistaPrint: just celebrated the 10 year anniversary of the global
documentation wiki for its 10,000 employees with 8,000 readers, 1,000
active contributors over 30 days, 250,000 articles, and 2.5 million edits
- Memorial Sloan Kettering Cancer Clinic: documentation of a standard set
of terminology and definitions
- Genesys: documentation for software to create and manage call centers
- Columbia University: collaborative research project on historical Tibetan
newspapers
- Large oil and gas companies have not only implemented MediaWiki
internally but work together on a regular basis to discover improvements
based on common business needs
- Organizations using wikis to document business practices of service
redesign in health care
- Non-profits sharing historical information and enabling families to
contribute information about members of Halls of Fame
- Organizations such as the United States Department of Energy, United
States Army Corps of Engineers, Los Alamos National Laboratory, General
Electric, Safran Electrical Power, and University of Paderborn
--------------
What does the third-party MediaWiki community wish for from the Wikimedia
Foundation?
The MediaWiki Stakeholders’ Group maintains a wishlist of MediaWiki
features requested by the third-party community [6]. At EMWCon Spring 2017,
attendees discussed areas in which they would like to work in partnership
with the Wikimedia Foundation to improve MediaWiki and the MediaWiki
software ecosystem. The most important of these issues are:
- Ease of MediaWiki and extension installation, upgrade, maintenance, and
configuration management
- Improved mediawiki.org extension directory increasing findability and
accuracy for users and developers [7]
- Improved MediaWiki user and developer documentation on mediawiki.org
augmented with Wikimedia project and third-party “best practices” -
security, scalability, template management, data backup, wiki farms,
getting end-user contributors, etc.
- Marketing by Wikimedia Foundation or through Wikimedia Foundation
communication channels (e.g. the blog) of MediaWiki as a viable third-party
solution, especially in enterprises, answering such questions as “Why not
SharePoint/Confluence?”
- Regularly scheduled Wikimedia Foundation and third-party developer
community events to demonstrate innovative approaches and best practices in
third-party wikis to the Wikimedia Foundation and third-party developer
communities
- A MediaWiki Roadmap
The third-party MediaWiki community members are dedicated advocates for the
use of MediaWiki. Members of this community seek to grow the collaborative
relationship with the Wikimedia Foundation through grant applications to
the Wikimedia Foundation as well as ongoing discussions to help direct work
on these items inside the Wikimedia Foundation as well as in the
third-party MediaWiki community.
[0] 100M Wikimedia wiki pages and 90M non-Wikimedia wiki pages are tracked
by Wikistats: http://wikistats.wmflabs.org/
[1] A ballpark estimate based on mediawiki.org categories weighted by lines
of code indicates that about 20% of the MediaWiki extensions on gerrit are
used by Wikimedia Foundation. The remaining extensions comprise 1.75M lines
of code: that equates to 400 person-years of effort or $55M with the
standard COCOMO model. The Semantic MediaWiki extension alone is estimated
to have a $1.5M development cost per
https://www.openhub.net/p/smw/estimated_cost.
[2] https://www.mediawiki.org/wiki/Community_metrics#wikimedia.biterg.io
[3] https://phabricator.wikimedia.org/T160508
[4] https://www.mediawiki.org/wiki/MediaWiki_Usage_Report_2015
[5] https://www.mediawiki.org/wiki/EMWCon_Spring_2017
[6]
https://www.mediawiki.org/wiki/MediaWiki_Stakeholders%27_Group/Tasks/Featur…
[7] https://phabricator.wikimedia.org/T155029 and item #11 on
https://www.mediawiki.org/wiki/Developer_Wishlist/2017/results
- my apologies for cross posting -
Hey all,
today the TwoColConflict extension (= Two Column Edit Conflict View) [1]
got deployed as a beta feature to all wikis.
The Two Column Edit Conflict View is a new interface for the edit conflict
resolution page. It highlights differences between the editor's and the
conflicting changes to make it easier to copy and paste pieces of the text
and resolve the conflict. [2] [3] The feature aims to fulfill a request
for a more user-friendly edit conflict resolution from the German-speaking
community's Technical Wishlist. Therefore, the focus of the feature lays on
providing a more user-friendly interface and does not aim to improve the
current diff engine. The concept & implementation of the feature was widely
discussed with many different users onwiki and in real life and got
developed over the past months. [3]
The beta feature has already been available on deWP, meta, heWP, arWP for
more than 2 months and on fiWP for a few weeks.
As much as we don't want anyone to run into an edit conflict, we'd love to
receive feedback on the new interface in case you have one! The feature can
be activated in the beta feature section, and the feedback link provided
there will bring you to: https://www.mediawiki.org/wiki
/Help_talk:Two_Column_Edit_Conflict_View.
Thanks to everyone who gave feedback so far and helped us to further
improve the feature!
Birgit (for WMDE's Technical Wishes team)
[1] https://www.mediawiki.org/wiki/Extension:TwoColConflict (extension
manual for developers)
[2] https://www.mediawiki.org/wiki/Help:Two_Column_Edit_Conflict_View
(Multilingual help page & central feedback page for all users)
[3] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/Edit_Conflicts
(English-speaking project page with documentation of research, prototype
testing and feedback loops)
[4] https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes (Technical Wishes
project page)
--
Birgit Müller
Community Communications Manager
Software Development and Engineering
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
In April 2017 the Wikimedia Foundation's TechOps Labs and Community
Tech Tool Labs support teams merged into the Wikimedia Cloud Services
team [0][1]. This new team is in charge of Wikimedia Labs, Tool Labs,
the Labs database replicas (in partnership with the DBA team), data
dump servers (in partnership with Ariel), Quarry, and PAWS.
One component of the internal Foundation pitch for creating the team
was that this would provide an opportunity to break with the past and
undertake a rebranding effort designed to address the 'Labs labs labs
problem' [2], as well as to raise awareness in the Wikimedia
communities of the products and services offered under the Cloud
Services umbrella.
I'm happy to present the initial outline of the rebranding effort:
<https://wikitech.wikimedia.org/wiki/User:BryanDavis/Rebranding_Cloud_Servic…>.
I would like to invite anyone interested in the future of Labs and
Tool Labs to read the outline of rebranding tasks and provide feedback
on gaps in the plan or aspects of the rebranding proposal that will
conflict with other projects. This is a consultation and not consensus
based decision making process. Not all things are possible in this
space due to various restrictions including trademarks and copyrights.
This consultation will stay open until at least 2017-05-26 to collect
initial feedback. The entire Cloud Services team will also be present
at the Vienna hackathon to discuss the topic in person with people who
are there and interested.
[0]: https://lists.wikimedia.org/pipermail/wikimedia-l/2017-February/086343.html
[1]: https://www.mediawiki.org/wiki/Wikimedia_Cloud_Services_team
[2]: https://wikitech.wikimedia.org/wiki/Labs_labs_labs
Bryan
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Manager, Cloud Services Boise, ID USA
irc: bd808 v:415.839.6885 x6855