[Development] [Qt-creator] [FYI] commit/review policy refactored

Oswald Buddenhagen oswald.buddenhagen at qt.io
Wed Jul 13 15:17:53 CEST 2016

On Wed, Jul 13, 2016 at 01:10:20PM +0200, Kai Köhne wrote:
> Oswald Buddenhagen wrote:
> > On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote:
> > > "Make sure that your commit matches the Qt Commit Policy.
> > >
> > > > 1. Invite relevant reviewers.
> > > > * Always invite the respective domain experts, not somebody convenient.
> > >
> > > Scrap the 'not somebody convenient'. It's the job of the reviewer to decide
> > > what he can approve.
> > >
> > it's the responsibility of both sides. don't pretend that these social dynamics
> > don't exist.
> Well, in doubt the blame is always on the approver, not on the contributor.
when the outcome is predictable, it doesn't matter who is technically
responsible. by inviting a reviewer (in particular, just *one* reviewer)
you're expressing an expectation.

> Also, it's perfectly fine to add 'convenient' people, be it only to
> check commit logs, or notify them about stuff.
then you're not inviting them to an actual review, and you're expected
to state that, and disregard their approval in case they still give it.

> > every approver is a contributor by definition. ;) 
> Not every contributor is an approver though, so it makes IMO more sense to put stuff specific to approvers into the reviewers section.
> Or prefix them with "For contributors that are also approvers:".
you're mixing things up. this is about the roles in any given
contribution, not about the titles anyone may hold. this is indicated by
the use of definite articles in the section headers (apart from the fact
that "reviewer" is no defined title in the first place).

> I think 'consensus' instead of 'broad expert consensus' is enough too :)
the point was about clarifying that the opinion of one actual expert
weights more than half a dozen me-too's from non-experts.

> My point is: This text reads like a proverbial stick you want to use
> against fellows that overstep their limits (as you perceive it).
that's exactly the point of anything that calls itself a policy.
otherwise it would be a convention.

> I'm somewhat skeptical that putting down draconical rules somewhere on
> the wiki helps on this , but whatever.
no, but it helps when it's written down clearly and the majority gives
the impression of expecting that these rules are followed. given that
this page just codifies the usual practice of the last five years, it
seems reasonable to think that this is the case.

More information about the Development mailing list