Public service reminder: consider adding yourself to http://www.mediawiki.org/wiki/Git/Reviewers if you want to get auto-added to review changesets in a certain repository, and to the relevant column in https://www.mediawiki.org/wiki/Developers/Maintainers if you want for people to sometimes add you as a reviewer.
Thanks to Merlijn van Deen for setting up the reviewer-adding bot.
I'd point out that there is also an option in your gerrit prefs to get an email whenever someone touches a certain repo or a certain path in a certain repo.
-bawolff On 2013-09-24 4:24 PM, "Sumana Harihareswara" sumanah@wikimedia.org wrote:
Public service reminder: consider adding yourself to http://www.mediawiki.org/wiki/Git/Reviewers if you want to get auto-added to review changesets in a certain repository, and to the relevant column in https://www.mediawiki.org/wiki/Developers/Maintainers if you want for people to sometimes add you as a reviewer.
Thanks to Merlijn van Deen for setting up the reviewer-adding bot.
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
P.S. https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews is still useful as a guide to getting reviewed faster. :-)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Can we get the bot to pester people if patches sit too long unreviewed? That's the other thing that might be off-putting to a new contributor. --scott On Sep 24, 2013 3:24 PM, "Sumana Harihareswara" sumanah@wikimedia.org wrote:
Public service reminder: consider adding yourself to http://www.mediawiki.org/wiki/Git/Reviewers if you want to get auto-added to review changesets in a certain repository, and to the relevant column in https://www.mediawiki.org/wiki/Developers/Maintainers if you want for people to sometimes add you as a reviewer.
Thanks to Merlijn van Deen for setting up the reviewer-adding bot.
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
P.S. https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews is still useful as a guide to getting reviewed faster. :-)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Le 24/09/13 22:18, C. Scott Ananian a écrit :
Can we get the bot to pester people if patches sit too long unreviewed? That's the other thing that might be off-putting to a new contributor. --scott
If those people are already ignoring the email asking for review, they will surely ignore the bot one :-/
Well sometimes a bot bump is appropriate. Sometimes I do +1 on a change with the intention of doing a further review later, but then I forget.
Our core developers get a lot of patches to review. Once something drops down past the first page in gerrit, it's lost forever.
Backing up here, I'm assuming that our focus is on fostering new developers. Old hands know who to add as reviewers, and know to pester them if they don't get a review in a reasonable time. I'm wondering if there's some way the bot can shepherd the review process a little further past the "add reviewers" stage.
For example, can we identify "new contributors" -- those with less than N patches merged, say? Have the bot target those for help with reviewers, and then maintain, say, a status board where we can keep an eye on those patches and make sure they make it through the process? --scott
On Tue, Sep 24, 2013 at 2:56 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
Our core developers get a lot of patches to review. Once something drops down past the first page in gerrit, it's lost forever.
We should organize a sprint to give some old patches some love!
-Chad
Le 24/09/13 23:56, C. Scott Ananian a écrit :
Our core developers get a lot of patches to review. Once something drops down past the first page in Gerrit, it's lost forever.
I have enough people asking me for review that I only rely on my Gerrit dashboard. So indeed, old patches are usually out of my view.
Last time I looked at the rotting changes in mediawiki/core, most of them received some reviews and are pending actions from the original author. We should probably triage them and then either finish the code or abandon it.
Backing up here, I'm assuming that our focus is on fostering new developers. Old hands know who to add as reviewers, and know to pester them if they don't get a review in a reasonable time. I'm wondering if there's some way the bot can shepherd the review process a little further past the "add reviewers" stage.
For example, can we identify "new contributors" -- those with less than N patches merged, say? Have the bot target those for help with reviewers, and then maintain, say, a status board where we can keep an eye on those patches and make sure they make it through the process?
The OpenStack Foundation (they use Gerrit and a similar workflow of core people approving changes), has build a review dashboard that assign a score to changes:
http://status.openstack.org/reviews/
Related code is on github:
https://github.com/openstack-infra/reviewday#reviewday
The score algorithm is in reviewday/mergeprop.py [1]. As an example a regression hotfix get a score of 350 while a minor feature get 35. As the patch get older, it will receives additional points to bump it.
They then have all core people on a rolling one day duty where their role is to approve changes, assign reviewers and ask them to do reviews. That is tedious, but only for a day:
https://wiki.openstack.org/wiki/Nova/ReviewDays
We can surely reuse reviewday for our own use, that will need some code written to interact with Bugzilla to fetch the keywords/priority and assign scores.
I am to busy to babysit such a project on a labs instance, but will be more than happy to get the change merged upstream if need be (tip folks are in #openstack-infra).
[1] https://github.com/openstack-infra/reviewday/blob/master/reviewday/mergeprop...
wikitech-l@lists.wikimedia.org