User:Tgr (WMF)/test
Implement a way to bring GitHub pull requests into gerrit
[edit]
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)
[edit]- sdfsdf Tgr (WMF) (talk) 02:55, 6 February 2017 (UTC)
- cccc Tgr (WMF) (talk) 07:45, 8 February 2017 (UTC)
Support (T37497)
[edit]Enable and document "WIP" workflow status in Gerrit
[edit]
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)
[edit]Support (T135245)
[edit]- Tgr (WMF) (talk) 02:46, 6 February 2017 (UTC)
- SSethi (WMF) (talk) 02:58, 6 February 2017 (UTC)
- Tgr (WMF) (talk) 07:44, 8 February 2017 (UTC)
- Tgr (WMF) (talk) 19:09, 1 March 2017 (UTC)
Organize a Wikimedia developer contest to recognize and promote best projects
[edit]
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)
[edit]Support (T147545)
[edit]- 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
[edit]
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)
[edit]Support (T135186)
[edit]Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites
[edit]
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:
- Wikimedia-l:
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)
[edit]Support (T71445)
[edit]- SSethi (WMF) (talk) 02:59, 6 February 2017 (UTC)
Add a welcome bot to Gerrit for first time contributors
[edit]
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)