Re: [9.4 CF 1] The Commitfest Slacker List - Mailing list pgsql-hackers

From Greg Smith
Subject Re: [9.4 CF 1] The Commitfest Slacker List
Date
Msg-id 51EDBD5A.2080900@2ndQuadrant.com
Whole thread Raw
In response to Re: [9.4 CF 1] The Commitfest Slacker List  (Josh Berkus <josh@agliodbs.com>)
List pgsql-hackers
On 6/24/13 12:57 PM, Josh Berkus wrote:
> Maciej is correct that this policy also belongs on the "how to submit a
> patch" wiki page.  I will remedy that.

I just reviewed and heavily updated the new section you added to 
https://wiki.postgresql.org/wiki/Submitting_a_Patch  That included the 
idea that the reviewed patch should be similar in size/scope to the 
submitted one, as well a slightly deeper discussion of how to fit this 
work into a feature review quote.

I find myself needing to explain this whole subject to potential feature 
sponsors enough that I've tried a few ways of describing it.  The 
closest analog I've found so far is the way "carbon offset" work is 
accounted for.  I sometimes refer to the mutual review as an "offsetting 
review" in conversation, and I threw that term into the guidelines as well.

As far as motivating new reviewers goes, let's talk about positive 
feedback.  Anything that complicates the release notes is a non-starter 
because that resource is tightly controlled by a small number of people, 
and it's trying to satisfy a lot of purposes.  What I would like to see 
is an official but simple "Review Leaderboard" for each release instead.

Each time someone writes a review and adds it to CF app with a "Review" 
entry, the account that entered it gets a point.  Sum the points at the 
end and there's your weighted list for T-shirt prizes.  It should be 
possible to get that count with a trivial SELECT query out of the CF 
database, and then produce a simple HTML table at the end of each CF or 
release.  Anything that takes more work than that, and anything that 
takes *any* time that must come from a committer, is too much accounting.

This idea would be a bit unfair to people who review big patches instead 
of little ones.  But an approach that disproportionately rewards new 
contributors working on small things isn't that terrible.  As long as 
the review tests whether the code compiles and passes the regression 
tests, that's good enough to deserve a point.  I'd be happy if we 
suddenly had a problem where people were doing only that to try game 
their leaderboard ranking.

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
Next
From: Tom Lane
Date:
Subject: Re: Comma Comma Comma 8601