project-template
project-template copied to clipboard
opencontainers
GOVERNANCE: Proposing a motion is a LGTM by default
To avoid uncertainty like this.
This is more than a typo-fix, so it probably deserves an all-maintainers vote to confirm the change. I'm going to remove the co-sponsor requirement in a separate PR, and we can batch those two together for a single vote if that would make life easier for maintainers.
On Thu, Sep 08, 2016 at 11:33:06AM -0700, Vincent Batts wrote:
actually no, that is like LGTM'ing your own PR, which we disallow. Rejected
We have a much more relaxed quorum requirement for PRs (2 LGTMs, vs. ⅔ for voted proposals). And the motivation for blocking self-LGTMs is 1:
to ensure equal amounts of review for every pull request, no matter who wrote it
Non-maintainers may submit pull requests (and need two other folks to LGTM it), so that's consistent. But non-maintainers cannot propose motions, so every proposal is reviewed equally even if you allow sponsor votes.
If, I cannot convince folks that sponsor(s) should be allowed to vote, my next proposal would be to remove them from the quorum count. With wording like:
A quorum is established when at least two-thirds of non-sponsor maintainers have voted.
but ick ;).
If we block sponsor votes but keep them in the quorum, I think we'll be raising our quorum requirement too high. It's a shame when a vote fails because folks didn't notice it 2.
As I mentioned on the list, I'd rather the proposer's acceptance be implied unless they state otherwise. If they don't agree with the proposal, it seems silly IMO for them to be proposing it.
(Not sure if my vote counts here, but just in case:) Rejected
On Thu, Sep 08, 2016 at 12:17:09PM -0700, Tianon Gravi wrote:
As I mentioned on the list, I'd rather the proposer's acceptance be implied unless they state otherwise. If they don't agree with the proposal, it seems silly IMO for them to be proposing it.
You don't buy my “reject a proposal they consider crazy” workflow 1? ;). I think it's easy to stick a LGTM in your propsal, so I like ca46aab34 as it stands. But if that seems like too high a bar, I'm ok with language like:
Unless the sponsor(s) explicitly LGTM/REJECT the proposal, the submitting the proposal counts as a LGTM.
Both that wording and ca46aab34 allow sponsor(s) to vote, which @vbatts is concerned about 2 but I think is appropriate 3. Do you have any problems with sponsor(s) voting in general?
(Not sure if my vote counts here, but just in case:) Rejected
I'm not sure how pull-approve is setup for this site, but my understanding is that the maintainers are the union of all OCI project maintainers (in which case your vote counts).
Subject: Re: [runtime-spec VOTE]: Tag d3c3763b as v1.0.0-rc2 (closes
2016-09-08 13:47 UTC)
Date: Thu, 8 Sep 2016 11:08:16 -0700
Message-ID: <[email protected]>
Yeah, I don't have any problem with the proposer voting -- I think your reasoning makes sense regarding that, I just think that the situations in which someone would propose something they actually disagree with are small enough that it's worth optimizing our already high-overhead process for the default common case (which is that the proposer agrees with what they're proposing).
On Thu, Sep 08, 2016 at 12:33:31PM -0700, Tianon Gravi wrote:
… I just think that the situations in which someone would propose something they actually disagree with are small enough that it's worth optimizing our already high-overhead process for the default common case (which is that the proposer agrees with what they're proposing).
Maybe I've just absorbed too much “Explicit is better than implicit” 1 ;). Anyhow, updated to make proposing a motion an explicit LGTM with ca46aab → 30f6050.
Heh, I generally agree, but in this case, I'm more partial to "Simple is better than complex."
30f60503bd426778a53f22ff81475a6b2da31c4d LGTM :+1:
Might as well say "unless sponsor explicitly REJECT" rather than or LGTM, but it doesn't break any logic being this way.
30f6050 LGTM
On Thu, Sep 8, 2016, 15:51 Tianon Gravi [email protected] wrote:
Heh, I generally agree, but in this case, I'm more partial to "Simple is better than complex."
30f6050 https://github.com/opencontainers/project-template/commit/30f60503bd426778a53f22ff81475a6b2da31c4d LGTM 👍
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opencontainers/project-template/pull/18#issuecomment-245718978, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF6YWVFeYt92E_6UKLIPnM81Yad32qks5qoGdYgaJpZM4J4Sms .
On Thu, Sep 08, 2016 at 12:59:48PM -0700, Vincent Batts wrote:
Might as well say "unless sponsor explicitly REJECT" rather than or LGTM, but it doesn't break any logic being this way.
Good point. Replaced “LGTM or REJECT” with “REJECT or ABSTAIN” in 30f6050 → ee50249.
ee50249 LGTM
On Thu, Sep 8, 2016, 16:10 Tianon Gravi [email protected] wrote:
ee50249 https://github.com/opencontainers/project-template/commit/ee50249470ef9cb01618deb4f1a107e3740129a3 LGTM
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opencontainers/project-template/pull/18#issuecomment-245724242, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEF6Rrb8_DyFvWtM5FqgxC_3AwkRvT6ks5qoGuhgaJpZM4J4Sms .
