User:Tgr (WMF)/test

Enable and document "WIP" workflow status in Gerrit
Currently there is no standard, easily parsable-by-machine way to mark a Gerrit change as work in progress (WIP). This means that either dashboards and queries need to be filtered by a human brain, or each developer has to amend their search strings by excluding "DO NOT MERGE", "WIP", -1 votes by the changeset owner, etc. and hope that they don't miss false negatives.

Add a new label "WIP", inspired by OpenStack's "Workflow" label. Its "neutral" value is 0 ("Ready for reviews"). If it is "voted" to -1 ("Work in progress"), the change cannot be submitted. This vote will stick with new uploads until it is changed back to 0.

For searches, this will allow Gerrit users to restrict search results by adding "label:WIP+0" to their filters.

Mailing list (wikitech-l) discussion summary from greg: https://lists.wikimedia.org/pipermail/wikitech-l/2016-May/085611.html How to do it from Tim L (from Sept 2015) https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083172.html :

Related: T52842: Add "Work in progress" button/status to Gerrit workflow to reduce dashboard noise

Endorsements (T135245)

 * 1) Tgr (WMF) (talk) 21:25, 5 February 2017 (UTC)

Implement a way to bring GitHub pull requests into gerrit
First: Find the various GitHub mirrors of MediaWiki. Turn one into an up-to-date clone of our codebase.


 * https://github.com/mediawiki
 * https://github.com/mediawiki/mediawiki-svn
 * https://github.com/mediawiki/mediawiki-trunk-phase3

Next, harder step: Make an interface to accept GitHub pull requests as merge requests in Gerrit, or do two-way syncing automatically via a bot.

Erik: "although I'm guessing that falls into the "hard" category, it could give us huge wins in terms of casual contribution.

Chad: "Yeah, that's definitely not straightforward--would need some careful thought to make sure we're doing it in a way that makes sense on our end too."

Organize a Wikimedia developer contest to recognize and promote best projects
This is a known model: organizing a developer contest in order to find great projects and the great people behind them. Do we have any precedent in Wikimedia?

This is a proposal targeting the Technical Collaboration annual plan FY2017-18. We would need to be in sync with the rest of Community Engagement, Product, and Comms. If you like the idea, let's plan for it and let's request the necessary budget.

How this could work:
 * Being the first edition, the requirement would be to just be a stable and active project during 2016. In future edition we might want to restrict eligibility for new projects only, if there are enough of them.
 * We could have different categories:
 * Projects using Wikimedia APIs (one option would be to start small only with this category, then grow other categories if needed in future editions).
 * Extensions
 * Gadgets
 * Bots
 * Templates
 * Skins
 * The criteria to select winners could be a combination of qualitative factors (innovation, originality, usefulness...) and popularity. A jury would be in charge of the selection.
 * Potential prizes:
 * Organization of a small hackathon or workshop with the winner and a selection of developers, UX designers and users to improve the project and get new ideas.
 * Invitation to the Wikimedia Hackathon / Summit / Wikimania with some extra spice (i.e. some days of leisure and you can invite a partner).
 * Invitation to a special activity organized by a Wikimedia partner e.g. a workshop at the Internet Archive, a guided tour to NASA premises, an activity by any GLAM institution... also with some extra leisure spice for the winner and one partner.
 * Wikimedia merchandising, books, knowledge-related subscriptions...
 * Of course media coverage in the form of press release, blog post, promotional video...

Add a welcome bot to Differential for first time contributors
See also - T73357: Add a welcome bot to Gerrit for first time contributors

OpenStack is using this bot for Gerrit: https://github.com/openstack-infra/jeepyb/blob/master/jeepyb/cmd/welcome_message.py

Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites
MediaWiki: CSS/JS pages on any non-large wiki are usually a mess. Occasionally, we'll discover that wikis have been loading external resources for months and no one noticed. In addition, the local sysops maintaining those pages usually don't know JavaScript and are copy-pasting what someone else told them to do. Even when that's not the case, mistakes can result in code with obvious syntax errors being sent to readers for long periods of time.

Various proposals have floated around over the years. The wikitech-l threads have some good discussion on some of the reasons why this is difficult for smaller wikis.
 * Wikitech-l:
 * No longer allow gadgets to be turned on by default for all users on Wikimedia sites (specifically about Gadgets though)
 * Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)
 * Wikimedia-l:
 * Next steps regarding WMF<->community disputes about deployments
 * Superprotect user right, Comming to a wiki near you

See Also:
 * T39230: Provide standard way to create/run QUnit tests for Gadgets and user scripts (bug 37230)
 * T53651: Auto-generated gadget documentation with JsDuck (bug 51651)
 * T71550: Move code in enwiki MediaWiki:Common.js and Gadgets to MediaWiki software
 * T1238: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets)

Add a welcome bot to Gerrit for first time contributors
Something akin to https://review.openstack.org/#/c/124398/ - The "Welcome, new contributor!" message is quite a nice touch

-

See Also: T64324: Visually indicate when a Phabricator user is new (Welcome culture)