User:Tgr (WMF)/test

Implement a way to bring GitHub pull requests into gerrit

Tracked in Phabricator
Task T37497

Vote Endorse

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. sdfsdf Tgr (WMF) (talk) 02:55, 6 February 2017 (UTC)
2. cccc Tgr (WMF) (talk) 07:45, 8 February 2017 (UTC)

Support (T37497)

1. Tgr (WMF) (talk) 02:55, 6 February 2017 (UTC)

Enable and document "WIP" workflow status in Gerrit

Tracked in Phabricator
Task T135245

Vote Endorse

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)

1. 1. Tgr (WMF) (talk) 21:25, 5 February 2017 (UTC)
2. AAAA Tgr (WMF) (talk) 02:46, 6 February 2017 (UTC)

Support (T135245)

• Tgr (WMF) (talk) 02:43, 6 February 2017 (UTC)

1. Tgr (WMF) (talk) 02:46, 6 February 2017 (UTC)
2. SSethi (WMF) (talk) 02:58, 6 February 2017 (UTC)
3. Tgr (WMF) (talk) 07:44, 8 February 2017 (UTC)
4. Tgr (WMF) (talk) 19:09, 1 March 2017 (UTC)

Organize a Wikimedia developer contest to recognize and promote best projects

Tracked in Phabricator
Task T147545

Vote Endorse

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)

1. asasas Tgr (WMF) (talk) 02:49, 6 February 2017 (UTC)

Support (T147545)

• Tgr (WMF) (talk) 02:20, 6 February 2017 (UTC)
• Tgr (WMF) (talk) 02:21, 6 February 2017 (UTC)
• Supported byTgr (WMF)Tgr (WMF) (talk) 02:38, 6 February 2017 (UTC)
• Supported byTgr (WMF)Tgr (WMF) (talk) 02:38, 6 February 2017 (UTC)

Add a welcome bot to Differential for first time contributors

Tracked in Phabricator
Task T135186

Vote Endorse

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. fkjgndfgkjbn Tgr (WMF) (talk) 02:57, 6 February 2017 (UTC)

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

Tracked in Phabricator
Task T71445

Vote Endorse

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)

Support (T71445)

1. SSethi (WMF) (talk) 02:59, 6 February 2017 (UTC)

Add a welcome bot to Gerrit for first time contributors

Tracked in Phabricator
Task T73357

Vote Endorse

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)