MediaWiki

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

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

6 proposals, 65 editors, 110 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites

Tracked in Phabricator
Task T71445

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.

See Also:

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. —Mainframe98 talk 09:39, 6 February 2017 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]

Support (T71445)

  1. Info-farmer (talk) 05:42, 6 February 2017 (UTC)[reply]
  2. —Mainframe98 talk 09:35, 6 February 2017 (UTC)[reply]
  3. Amir E. Aharoni (talk) 14:07, 6 February 2017 (UTC)[reply]
  4. Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)[reply]
  5. BDavis (WMF) (talk) 17:46, 6 February 2017 (UTC)[reply]
  6. EBernhardson (WMF) (talk) 17:59, 6 February 2017 (UTC)[reply]
  7. Daniel Mietchen (talk) 22:49, 6 February 2017 (UTC)[reply]
  8. Jack Phoenix (Contact) 23:08, 6 February 2017 (UTC)[reply]
  9. [[kgh]] (talk) 23:20, 6 February 2017 (UTC)[reply]
  10. SamanthaNguyen (talk) 23:31, 6 February 2017 (UTC)[reply]
  11. Santhosh.thottingal (talk) 03:47, 7 February 2017 (UTC)[reply]
  12. Ladsgroup (talk) 07:21, 7 February 2017 (UTC)[reply]
  13. Sunfyre (talk) 07:27, 7 February 2017 (UTC)[reply]
  14. Nikerabbit (talk) 08:18, 7 February 2017 (UTC)[reply]
  15. Yamaha5 (talk) 09:29, 7 February 2017 (UTC)[reply]
  16. Matěj Suchánek (talk) 14:03, 7 February 2017 (UTC)[reply]
  17. Samuele2002 (talk) 22:22, 7 February 2017 (UTC)[reply]
  18. MHolloway (WMF) (talk) 22:37, 7 February 2017 (UTC)[reply]
  19. Tgr (WMF) (talk) 09:14, 8 February 2017 (UTC)[reply]
  20. Seddon (WMF) (talk) 11:49, 8 February 2017 (UTC)[reply]
  21. Mohamedudhuman05 (talk) 17:44, 8 February 2017 (UTC)[reply]
  22. Whatamidoing (WMF) (talk) 19:03, 8 February 2017 (UTC)[reply]
  23. Bgwhite (talk) 19:18, 8 February 2017 (UTC)[reply]
  24. Enterprisey (talk) 20:40, 8 February 2017 (UTC)[reply]
  25. ExplodingPoPUps (talk) 02:14, 11 February 2017 (UTC)[reply]
  26. — Mr. Stradivarius ♪ talk ♪ 09:28, 11 February 2017 (UTC)[reply]
  27. BSitzmann (WMF) (talk) 23:30, 11 February 2017 (UTC)[reply]
  28. Helder 17:40, 12 February 2017 (UTC)[reply]
  29. Mglaser (talk) 10:33, 13 February 2017 (UTC)[reply]
  30. James Martindale (talk) 17:12, 13 February 2017 (UTC)[reply]
  31. TerraCodes (talk) 21:13, 13 February 2017 (UTC)[reply]
  32. Framawiki (talk) 18:39, 14 February 2017 (UTC)[reply]
  33. Quiddity (WMF) (talk) 20:21, 14 February 2017 (UTC)[reply]
  34. Dave Braunschweig (talk) 21:58, 14 February 2017 (UTC)[reply]

Add a welcome bot to Gerrit for first time contributors

Tracked in Phabricator
Task T73357

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)

Endorsements (T73357)

Support (T73357)

  1. Dvorapa (talk) 07:42, 6 February 2017 (UTC)[reply]
  2. TomášPolonec (talk) 08:28, 6 February 2017 (UTC)[reply]
  3. —Mainframe98 talk 09:40, 6 February 2017 (UTC)[reply]
  4. Jdforrester (WMF) (talk) 16:27, 6 February 2017 (UTC)[reply]
  5. Miriya52 (talk) 21:33, 6 February 2017 (UTC)[reply]
  6. SamanthaNguyen (talk) 22:34, 7 February 2017 (UTC)[reply]
  7. Samuele2002 (talk) 23:20, 7 February 2017 (UTC)[reply]
  8. Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)[reply]
  9. BSitzmann (WMF) (talk) 23:32, 11 February 2017 (UTC)[reply]
  10. Jerrykim306 (talk) 12:51, 12 February 2017 (UTC)[reply]
  11. B20180 (talk) 13:52, 14 February 2017 (UTC)[reply]
  12. Framawiki (talk) 18:39, 14 February 2017 (UTC)[reply]

Enable and document "WIP" workflow status in Gerrit

Tracked in Phabricator
Task T135245

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 :

Untested, the change would be something like: 

diff --git a/project.config b/project.config
index 151eebd..93291e1 100644
--- a/project.config
+++ b/project.config
@@ -12,6 +12,7 @@
        owner = group ldap/ops
        label-Code-Review = -2..+2 group Project Owners
        label-Code-Review = -1..+1 group Registered Users
+       label-WIP = -1..+0 group Registered Users
        create = group Project Owners
        editTopicName = group Registered Users
        viewDrafts = group JenkinsBot
@@ -78,6 +79,11 @@
        value = +2 Looks good to me, approved
        copyAllScoresOnTrivialRebase = true
        copyAllScoresIfNoCodeChange = true
+[label "WIP"]
+       function = AnyWithBlock
+       value = -1 Work in progress
+       value =  0 Ready for reviews
+       copyMinScore = true
 [access "refs/meta/dashboards/*"]
        create = group Project Owners
        create = group platform-engineering

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

Endorsements (T135245)

Support (T135245)

  1. Liuxinyu970226 (talk) 08:04, 6 February 2017 (UTC)[reply]
  2. Tim Landscheidt 11:34, 6 February 2017 (UTC)[reply]
  3. ·addshore· talk to me! 12:24, 6 February 2017 (UTC)[reply]
  4. --Marco Aurelio (talk • meta) 19:53, 6 February 2017 (UTC)[reply]
  5. Santhosh.thottingal (talk) 03:47, 7 February 2017 (UTC)[reply]
  6. Nikerabbit (talk) 08:17, 7 February 2017 (UTC)[reply]
  7. Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)[reply]
  8. Tpt (talk) 09:19, 8 February 2017 (UTC)[reply]
  9. Cindy.cicalese (talk) 14:22, 8 February 2017 (UTC)[reply]
  10. BDavis (WMF) (talk) 01:21, 9 February 2017 (UTC)[reply]
  11. Smalyshev (WMF) (talk) 17:55, 10 February 2017 (UTC)[reply]
  12. BSitzmann (WMF) (talk) 23:32, 11 February 2017 (UTC)[reply]
  13. James Martindale (talk) 17:11, 13 February 2017 (UTC)[reply]
  14. Thiemo Mättig (WMDE) 15:45, 14 February 2017 (UTC)[reply]

Implement a way to bring GitHub pull requests into gerrit

Tracked in Phabricator
Task T37497

First: Find the various GitHub mirrors of MediaWiki. Turn one into an up-to-date clone of our codebase.


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)[reply]
  2. This is certainly a pain point. However, I would like us to talk with GitHub about making the canonical repositories more discoverable than the mirrors. Currently we have quite some problems: some official repositories are not indexed and there are no repository-specific links back to gerrit, let alone rel=canonical URLs. --Nemo 18:19, 14 February 2017 (UTC)[reply]

Support (T37497)

  1. Dvorapa (talk) 07:39, 6 February 2017 (UTC)[reply]
  2. Liuxinyu970226 (talk) 08:04, 6 February 2017 (UTC)[reply]
  3. —TheDJ (Not WMF) (talk • contribs) 09:17, 6 February 2017 (UTC)[reply]
  4. Abbe98 (talk) 11:36, 6 February 2017 (UTC)[reply]
  5. ·addshore· talk to me! 12:24, 6 February 2017 (UTC)[reply]
  6. Daniel Mietchen (talk) 22:47, 6 February 2017 (UTC)[reply]
  7. — MusikAnimal talk 22:51, 6 February 2017 (UTC)[reply]
  8. ebrahimtalk 11:42, 7 February 2017 (UTC)[reply]
  9. Samuele2002 (talk) 23:19, 7 February 2017 (UTC)[reply]
  10. Enterprisey (talk) 20:41, 8 February 2017 (UTC)[reply]
  11. Smalyshev (WMF) (talk) 17:56, 10 February 2017 (UTC)[reply]
  12. — Mr. Stradivarius ♪ talk ♪ 09:11, 11 February 2017 (UTC)[reply]
  13. Helder 17:40, 12 February 2017 (UTC)[reply]
  14. Mglaser (talk) 10:32, 13 February 2017 (UTC)[reply]
  15. James Martindale (talk) 17:11, 13 February 2017 (UTC)[reply]
  16. TerraCodes (talk) 21:12, 13 February 2017 (UTC)[reply]
  17. would definitely motivate to contribute more often. Ijon (talk) 00:43, 14 February 2017 (UTC)[reply]
  18. BrentLaabs (talk) 01:04, 14 February 2017 (UTC)[reply]
  19. Ljonka (talk) 11:02, 14 February 2017 (UTC)[reply]
  20. B20180 (talk) 13:52, 14 February 2017 (UTC)[reply]
  21. Thiemo Mättig (WMDE) 15:44, 14 February 2017 (UTC)[reply]
  22. Framawiki (talk) 18:40, 14 February 2017 (UTC)[reply]

Organize a Wikimedia developer contest to recognize and promote best projects

Tracked in Phabricator
Task T147545

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

Endorsements (T147545)

Support (T147545)

  1. Iazyges (talk) 05:22, 6 February 2017 (UTC)[reply]
  2. Info-farmer (talk) 05:38, 6 February 2017 (UTC)[reply]
  3. ThurnerRupert (talk) 12:37, 6 February 2017 (UTC)[reply]
  4. Felipe (talk) 13:57, 6 February 2017 (UTC)[reply]
  5. Miriya52 (talk) 21:33, 6 February 2017 (UTC)[reply]
  6. Samuele2002 (talk) 05:53, 7 February 2017 (UTC)[reply]
  7. Tgr (WMF) (talk) 09:13, 8 February 2017 (UTC)[reply]
  8. Enterprisey (talk) 20:41, 8 February 2017 (UTC)[reply]
  9. Calexit (talk) 22:40, 9 February 2017 (UTC)[reply]
  10. RichardHeigl (talk) 23:05, 9 February 2017 (UTC)[reply]
  11. BSitzmann (WMF) (talk) 23:29, 11 February 2017 (UTC)[reply]
  12. Helder 17:40, 12 February 2017 (UTC)[reply]
  13. B20180 (talk) 13:51, 14 February 2017 (UTC)[reply]
  14. Framawiki (talk) 18:41, 14 February 2017 (UTC)[reply]

Add a welcome bot to Differential for first time contributors

Tracked in Phabricator
Task T135186

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

Endorsements (T135186)

  1. Welcoming new contributors is something which is definitely needed, but they mostly use some advice on the issue at hand rather than boilerplate text. If we really needed a bot for that, we could just use NewUserMessage on wikitechwiki, right? If the welcome bot is especially smart and can give custom advice, I may find it more interesting. Meanwhile, I invite everyone to help patches by newcomers, which I used to monitor at Gerrit/Reports/Open changesets by newbie owner. --Nemo 18:16, 14 February 2017 (UTC)[reply]

Support (T135186)

  1. Iazyges (talk) 05:22, 6 February 2017 (UTC)[reply]
  2. David1010 (talk) 06:48, 6 February 2017 (UTC)[reply]
  3. Dvorapa (talk) 07:42, 6 February 2017 (UTC)[reply]
  4. TomášPolonec (talk) 08:28, 6 February 2017 (UTC)[reply]
  5. —Mainframe98 talk 09:34, 6 February 2017 (UTC)[reply]
  6. AKlapper (WMF) (talk) 12:49, 6 February 2017 (UTC)[reply]
  7. Jdforrester (WMF) (talk) 16:26, 6 February 2017 (UTC)[reply]
  8. Miriya52 (talk) 21:33, 6 February 2017 (UTC)[reply]
  9. Samuele2002 (talk) 22:21, 7 February 2017 (UTC)[reply]
  10. SamanthaNguyen (talk) 22:34, 7 February 2017 (UTC)[reply]
  11. Tgr (WMF) (talk) 09:14, 8 February 2017 (UTC)[reply]
  12. Ljonka (talk) 11:01, 14 February 2017 (UTC)[reply]
  13. B20180 (talk) 13:51, 14 February 2017 (UTC)[reply]
  14. Framawiki (talk) 18:38, 14 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Code_Contribution_(Process,_Guidelines,_etc.)&oldid=5733678"