Re: [9.4 CF 1] The Commitfest Slacker List

From: Greg Smith <greg(at)2ndQuadrant(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [9.4 CF 1] The Commitfest Slacker List
Date: 2013-07-22 23:16:42
Message-ID: 51EDBD5A.2080900@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-07-22 23:17:59 Re: Comma Comma Comma 8601
Previous Message Tom Lane 2013-07-22 23:09:13 Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.