From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: a few thoughts on the schedule |
Date: | 2015-05-20 13:15:14 |
Message-ID: | CANP8+j++RGHvRiQss9tDH+ZT0h0tFYRPbPos2WxGQ4z=5yOHPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 20 May 2015 at 03:13, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Tue, May 19, 2015 at 04:55:11PM -0400, Robert Haas wrote:
> > On Tue, May 19, 2015 at 1:35 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> > > I think part of that is saying "no" more efficiently, upfront. Which is
> > > why I really want the triage step.
> > > a) It's much better for the project to not have several "junior"
> reviewers
> > > first spend time on a patch, then have a small flamefest, and then
> > > have somebody "senior" reject a patch in its entirety. That's a
> waste
> > > of everyone's effort and frustrating.
> > > b) It's not that bad to hear a "no" as a new contributor soon after
> > > submission. It's something entirely different to go through a long
> > > bikeshedding, several revisions of reworking, just to be told in the
> > > end that it was a bad idea from the get go.
> >
> > I agree this would help. Figuring out how to do it in a reasonable
> > way would help a lot. If we could get say 4 committers to go through
> > at the start of each CommitFest and each comment very briefly on 25%
> > of the patches each (yes, no, or maybe, and a bit of justification), I
> > bet that would streamline things considerably. If we could get each
> > committer to go through 50% of the patches and do this, then each
> > patch would get a quick opinion from two committers right at the
> > outset. That would be even nicer.
>
> Brief committer appraisals are unhelpful individually, but patterns
> matter. I
> would make the questionnaire as simple as necessary to get 4-7 committer
> evaluations per patch. Prefer 30-second analyses from each of five
> committers, not 30-minute analyses from two. Starting point:
>
> Q: How much effort would it take to write, from scratch, a committable
> patch for this feature?
> A: Small | Medium | Large
>
> Q: Relative to the that effort level, how valuable is this feature once
> committed?
> A: Negative | Low | Medium | High
>
> Q: How suitable is the chosen design?
> A: Wrong | Inconclusive | Right
>
> That should suffice to highlight doomed patches. With great submission
> notes,
> one can answer all three questions without opening the diff itself. Each
> appraiser could cover every patch of a CommitFest in an hour or two.
I'm happy to participate as a "triager" and will follow whatever process we
decide.
I would very much like to make this something we do via the CF app.
I believe we should include in our thinking how we nurture and grow
reviewers, contributors and committers. I am more likely to treat a
low-value patch seriously if it is an early contribution from someone, for
example.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Shulgin, Oleksandr | 2015-05-20 13:16:20 | [PATCH] Generalized JSON output functions |
Previous Message | Srinivas Karthik V | 2015-05-20 13:14:57 | PostgreSQL 8.3 index page count clarification |