Developer Wishlist/2017/Code Contribution (Process, Guidelines, etc.)

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

Support (T135186)

 * 1) Iazyges (talk) 05:22, 6 February 2017 (UTC)
 * 2) David1010 (talk) 06:48, 6 February 2017 (UTC)
 * 3) Dvorapa (talk) 07:42, 6 February 2017 (UTC)
 * 4) TomášPolonec (talk) 08:28, 6 February 2017 (UTC)
 * 5) &mdash; Mainframe98  talk 09:34, 6 February 2017 (UTC)
 * 6) AKlapper (WMF) (talk) 12:49, 6 February 2017 (UTC)
 * 7) Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)
 * 8) Miriya52 (talk) 21:33, 6 February 2017 (UTC)
 * 9) Samuele2002 (talk) 22:21, 7 February 2017 (UTC)
 * 10) SamanthaNguyen (talk) 22:34, 7 February 2017 (UTC)
 * 11) Tgr (WMF) (talk) 09:14, 8 February 2017 (UTC)

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)

Endorsements (T71445)

 * 1) Wikia introduced a JavaScript review process] in order to prevent insecure JavaScript, after some issues with it. After some starting problems, it now functions well. It might be something to look into. &mdash; Mainframe98 talk 09:39, 6 February 2017 (UTC)
 * 2) I'd give it a hundred votes if I could. It is a relatively quiet problem for now because it only causes problems with inconsistency, problematic testing, and broken extensions. But it will bite us in a much worse way some day if not addressed. It's sad that we have to do it, because the freedom to change gadgets quickly is awesome, but it's also very dangerous. Amir E. Aharoni (talk) 14:10, 6 February 2017 (UTC)
 * 3) The current state is an insane security risk, makes it near-impossible to have good tooling (tests, using a real IDE etc), results in low-quality and inconsistent code and missed opportunities for knowledge transfer, and makes it very cumbersome (and in some cases error-prone - e.g. gadget vs. personal subpage loading differences) to test changes before applying them (to the point that people often prefer testing on live code and temporarily breaking it). Tgr (WMF) (talk) 09:19, 8 February 2017 (UTC)
 * 4) Little problems, such as typos and accidental duplications in common.css and common.js, have caused multiple problems with both reading and editing at smaller wikis in the last few years. A simple, sane process should prevent these problems in the future. Whatamidoing (WMF) (talk) 19:03, 8 February 2017 (UTC)

Support (T71445)

 * 1) Info-farmer (talk) 05:42, 6 February 2017 (UTC)
 * 2) &mdash; Mainframe98  talk 09:35, 6 February 2017 (UTC)
 * 3) Amir E. Aharoni (talk) 14:07, 6 February 2017 (UTC)
 * 4) Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)
 * 5) BDavis (WMF) (talk) 17:46, 6 February 2017 (UTC)
 * 6) EBernhardson (WMF) (talk) 17:59, 6 February 2017 (UTC)
 * 7) Daniel Mietchen (talk) 22:49, 6 February 2017 (UTC)
 * 8) Jack Phoenix (Contact) 23:08, 6 February 2017 (UTC)
 * 9) &#91;&#91;kgh&#93;&#93; (talk) 23:20, 6 February 2017 (UTC)
 * 10) SamanthaNguyen (talk) 23:31, 6 February 2017 (UTC)
 * 11) Santhosh.thottingal (talk) 03:47, 7 February 2017 (UTC)
 * 12) Ladsgroup (talk) 07:21, 7 February 2017 (UTC)
 * 13) Sunfyre (talk) 07:27, 7 February 2017 (UTC)
 * 14) Nikerabbit (talk) 08:18, 7 February 2017 (UTC)
 * 15) Yamaha5 (talk) 09:29, 7 February 2017 (UTC)
 * 16) Matěj Suchánek (talk) 14:03, 7 February 2017 (UTC)
 * 17) Samuele2002 (talk) 22:22, 7 February 2017 (UTC)
 * 18) MHolloway (WMF) (talk) 22:37, 7 February 2017 (UTC)
 * 19) Tgr (WMF) (talk) 09:14, 8 February 2017 (UTC)
 * 20) Seddon (WMF) (talk) 11:49, 8 February 2017 (UTC)
 * 21) Mohamedudhuman05 (talk) 17:44, 8 February 2017 (UTC)
 * 22) Whatamidoing (WMF) (talk) 19:03, 8 February 2017 (UTC)
 * 23) Bgwhite (talk) 19:18, 8 February 2017 (UTC)
 * 24) Enterprisey (talk) 20:40, 8 February 2017 (UTC)

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)

Support (T73357)

 * 1) Dvorapa (talk) 07:42, 6 February 2017 (UTC)
 * 2) TomášPolonec (talk) 08:28, 6 February 2017 (UTC)
 * 3) &mdash; Mainframe98  talk 09:40, 6 February 2017 (UTC)
 * 4) Jdforrester (WMF) (talk) 16:27, 6 February 2017 (UTC)
 * 5) Miriya52 (talk) 21:33, 6 February 2017 (UTC)
 * 6) SamanthaNguyen (talk) 22:34, 7 February 2017 (UTC)
 * 7) Samuele2002 (talk) 23:20, 7 February 2017 (UTC)
 * 8) Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)

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

Support (T135245)

 * 1) Liuxinyu970226 (talk) 08:04, 6 February 2017 (UTC)
 * 2) Tim&#160;Landscheidt 11:34, 6 February 2017 (UTC)
 * 3)  ·addshore·  talk to me! 12:24, 6 February 2017 (UTC)
 * 4) --Marco Aurelio (talk &bull; meta) 19:53, 6 February 2017 (UTC)
 * 5) Santhosh.thottingal (talk) 03:47, 7 February 2017 (UTC)
 * 6) Nikerabbit (talk) 08:17, 7 February 2017 (UTC)
 * 7) Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)
 * 8) Tpt (talk) 09:19, 8 February 2017 (UTC)
 * 9) Cindy.cicalese (talk) 14:22, 8 February 2017 (UTC)
 * 10) BDavis (WMF) (talk) 01:21, 9 February 2017 (UTC)
 * 11) Smalyshev (WMF) (talk) 17:55, 10 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."

Endorsements (T37497)

 * 1) if this would be a general use interface between github and gerrit as well for other gerrits and projects i'd find it an excellent contribution. i am wondering if https://gerrit.googlesource.com/plugins/github/+/master/README.md does already what you r talking about here? ThurnerRupert (talk) 12:36, 6 February 2017 (UTC)

Support (T37497)

 * 1) Dvorapa (talk) 07:39, 6 February 2017 (UTC)
 * 2) Liuxinyu970226 (talk) 08:04, 6 February 2017 (UTC)
 * 3) —Th e DJ (Not WMF) (talk • contribs) 09:17, 6 February 2017 (UTC)
 * 4) Abbe98 (talk) 11:36, 6 February 2017 (UTC)
 * 5)  ·addshore·  talk to me! 12:24, 6 February 2017 (UTC)
 * 6) Daniel Mietchen (talk) 22:47, 6 February 2017 (UTC)
 * 7) &mdash;  MusikAnimal  talk  22:51, 6 February 2017 (UTC)
 * 8) ebrahimtalk 11:42, 7 February 2017 (UTC)
 * 9) Samuele2002 (talk) 23:19, 7 February 2017 (UTC)
 * 10) Enterprisey (talk) 20:41, 8 February 2017 (UTC)
 * 11) Smalyshev (WMF) (talk) 17:56, 10 February 2017 (UTC)

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...

Support (T147545)

 * 1) Iazyges (talk) 05:22, 6 February 2017 (UTC)
 * 2) Info-farmer (talk) 05:38, 6 February 2017 (UTC)
 * 3) ThurnerRupert (talk) 12:37, 6 February 2017 (UTC)
 * 4) Felipe (talk) 13:57, 6 February 2017 (UTC)
 * 5) Miriya52 (talk) 21:33, 6 February 2017 (UTC)
 * 6) Samuele2002 (talk) 05:53, 7 February 2017 (UTC)
 * 7) Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)
 * 8) Enterprisey (talk) 20:41, 8 February 2017 (UTC)
 * 9) Calexit (talk) 22:40, 9 February 2017 (UTC)
 * 10) RichardHeigl (talk) 23:05, 9 February 2017 (UTC)