Re: a few thoughts on the schedule

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: a few thoughts on the schedule
Дата
Msg-id CANP8+j++RGHvRiQss9tDH+ZT0h0tFYRPbPos2WxGQ4z=5yOHPg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: a few thoughts on the schedule  (Noah Misch <noah@leadboat.com>)
Ответы Re: a few thoughts on the schedule  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On 20 May 2015 at 03:13, Noah Misch <noah@leadboat.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@anarazel.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/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Srinivas Karthik V
Дата:
Сообщение: PostgreSQL 8.3 index page count clarification
Следующее
От: "Shulgin, Oleksandr"
Дата:
Сообщение: [PATCH] Generalized JSON output functions