-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GOVERNANCE: Proposing a motion is a LGTM by default #18
base: main
Are you sure you want to change the base?
Conversation
On Thu, Sep 08, 2016 at 11:33:06AM -0700, Vincent Batts wrote:
We have a much more relaxed quorum requirement for PRs (2 LGTMs, vs. ⅔ to ensure equal amounts of review for every pull request, no matter Non-maintainers may submit pull requests (and need two other folks to If, I cannot convince folks that sponsor(s) should be allowed to vote, A quorum is established when at least two-thirds of non-sponsor but ick ;). If we block sponsor votes but keep them in the quorum, I think we'll |
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:) |
On Thu, Sep 08, 2016 at 12:17:09PM -0700, Tianon Gravi wrote:
You don't buy my “reject a proposal they consider crazy” workflow 1? Unless the sponsor(s) explicitly LGTM/REJECT the proposal, the Both that wording and ca46aab allow sponsor(s) to vote, which
I'm not sure how pull-approve is setup for this site, but my
|
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). |
ca46aab
to
30f6050
Compare
To avoid uncertainty like [1]. I think an explicit LGTM is easy to add [2], but Tianon points out that there's already a lot to remember when proposing a vote, and most of the time the sponsor(s) will be in favor of the motion they're proposing [3]. [1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/5qj2hATVxew/-ljDGQB0AQAJ Subject: Re: [runtime-spec VOTE]: Tag d3c3763b as v1.0.0-rc2 (closes 2016-09-08 13:47 UTC) Date: Thu, 8 Sep 2016 13:48:38 -0400 Message-ID: <CANcsyS6q5neOqT+MLxhFDvDKPLGaYpY=HKy0p4pMjs3zexQs_A@mail.gmail.com> [2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/5qj2hATVxew/yu0x3ix1AQAJ 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: <20160908180816.GZ14866@odin.tremily.us> [3]: opencontainers#18 (comment) Subject: GOVERNANCE: Require explicit sponsor votes Signed-off-by: W. Trevor King <wking@tremily.us>
On Thu, Sep 08, 2016 at 12:33:31PM -0700, Tianon Gravi wrote:
Maybe I've just absorbed too much “Explicit is better than implicit” |
Heh, I generally agree, but in this case, I'm more partial to "Simple is better than complex." 30f6050 LGTM 👍 |
Might as well say "unless sponsor explicitly REJECT" rather than or LGTM, 30f6050 LGTM On Thu, Sep 8, 2016, 15:51 Tianon Gravi notifications@github.com wrote:
|
To avoid uncertainty like [1]. I think an explicit LGTM is easy to add [2], but Tianon points out that there's already a lot to remember when proposing a vote, and most of the time the sponsor(s) will be in favor of the motion they're proposing [3]. [1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/5qj2hATVxew/-ljDGQB0AQAJ Subject: Re: [runtime-spec VOTE]: Tag d3c3763b as v1.0.0-rc2 (closes 2016-09-08 13:47 UTC) Date: Thu, 8 Sep 2016 13:48:38 -0400 Message-ID: <CANcsyS6q5neOqT+MLxhFDvDKPLGaYpY=HKy0p4pMjs3zexQs_A@mail.gmail.com> [2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/5qj2hATVxew/yu0x3ix1AQAJ 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: <20160908180816.GZ14866@odin.tremily.us> [3]: opencontainers#18 (comment) Subject: GOVERNANCE: Require explicit sponsor votes Signed-off-by: W. Trevor King <wking@tremily.us>
30f6050
to
ee50249
Compare
ee50249 LGTM |
ee50249 LGTM On Thu, Sep 8, 2016, 16:10 Tianon Gravi notifications@github.com wrote:
|
…late into merge-project-template To fulfill the TOB's [1]: Both of the proposed projects would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. which was approved with this vote [2]. Generated with: $ git pull git://github.com/opencontainers/project-template.git master $ git checkout --ours .pullapprove.yml README.md $ git checkout --theirs CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md $ git add .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md $ git commit I think there are a few improvements we could make to these template docs [3,4,5], but the TOB vote happened before I'd floated those. If/when they land, we can pull the updated versions into this repository via a follow-up merge. * 'master' of git://github.com/opencontainers/project-template: (33 commits) .pullapprove.yml: Reset on push, ignore authors, and require sign-offs GOVERNANCE.md: fix typo GOVERNANCE and RELEASES: split the files project-governance: Make voting more generic proposals: release approval process explain security@ email proposal: fix a typo proposals: release-approval-process fix a grammar thing release-approval: Add non-spec unanimous quorum reduction release-approval: Shuffle to make more DRY proposals: release-approval-process: fixup additional typos proposals: release approval process: improve REJECT feedback proposals: release approval process: add information to projects proposals: release approval process: add language about mailing list proposals: release approval process: add quorum language proposals: release-approval-process: add voting members language proposals: release approval process: clarify utility of GitHub proposals: release approval process: use consistent language for rejects proposals: release approval process: one month pre-releases proposals: release approval process 3 rcs required proposals: release approval process to one week for apps ... Conflicts: .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md [1]: https://github.com/opencontainers/tob/blob/8997b1aa221b3b61d4305bede41c257b879bdeeb/proposals/tools.md#governance-and-releases [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/rZ4luMa-pxY Subject: VOTE Required: approve new projects: image-tools, runtime-tools Date: Wed, 07 Sep 2016 22:37:32 +0000 Message-ID: <CAD2oYtMLMFQouEVU7HTO-EKnW6vKu82dGT+0mziXZzCyqngj=A@mail.gmail.com> [3]: opencontainers/project-template#18 Subject: GOVERNANCE: Proposing a motion is a LGTM by default [4]: opencontainers/project-template#19 Subject: GOVERNANCE: Drop the co-sponsor requirement [5]: opencontainers/project-template#20 Subject: MAINTAINERS_GUIDE|CONTRIBUTING: Make generic enough for all OCI Projects
…late into merge-project-template To fulfill the TOB's [1]: Both of the proposed projects would incorporate the Governance and Releases processes from the OCI project template: https://github.com/opencontainers/project-template. which was approved with this vote [2]. Generated with: $ git pull git://github.com/opencontainers/project-template.git master $ git checkout --ours .pullapprove.yml README.md $ git checkout --theirs CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md $ git add .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md $ git commit I think there are a few improvements we could make to these template docs [3,4,5], but the TOB vote happened before I'd floated those. If/when they land, we can pull the updated versions into this repository via a follow-up merge. * 'master' of git://github.com/opencontainers/project-template: (33 commits) .pullapprove.yml: Reset on push, ignore authors, and require sign-offs GOVERNANCE.md: fix typo GOVERNANCE and RELEASES: split the files project-governance: Make voting more generic proposals: release approval process explain security@ email proposal: fix a typo proposals: release-approval-process fix a grammar thing release-approval: Add non-spec unanimous quorum reduction release-approval: Shuffle to make more DRY proposals: release-approval-process: fixup additional typos proposals: release approval process: improve REJECT feedback proposals: release approval process: add information to projects proposals: release approval process: add language about mailing list proposals: release approval process: add quorum language proposals: release-approval-process: add voting members language proposals: release approval process: clarify utility of GitHub proposals: release approval process: use consistent language for rejects proposals: release approval process: one month pre-releases proposals: release approval process 3 rcs required proposals: release approval process to one week for apps ... Conflicts: .pullapprove.yml CONTRIBUTING.md LICENSE MAINTAINERS_GUIDE.md README.md [1]: https://github.com/opencontainers/tob/blob/8997b1aa221b3b61d4305bede41c257b879bdeeb/proposals/tools.md#governance-and-releases [2]: https://groups.google.com/a/opencontainers.org/forum/#!topic/tob/rZ4luMa-pxY Subject: VOTE Required: approve new projects: image-tools, runtime-tools Date: Wed, 07 Sep 2016 22:37:32 +0000 Message-ID: <CAD2oYtMLMFQouEVU7HTO-EKnW6vKu82dGT+0mziXZzCyqngj=A@mail.gmail.com> [3]: opencontainers/project-template#18 Subject: GOVERNANCE: Proposing a motion is a LGTM by default [4]: opencontainers/project-template#19 Subject: GOVERNANCE: Drop the co-sponsor requirement [5]: opencontainers/project-template#20 Subject: MAINTAINERS_GUIDE|CONTRIBUTING: Make generic enough for all OCI Projects Signed-off-by: W. Trevor King <wking@tremily.us>
Catching up with opencontainers/tob@729e1ecf (Merge pull request opencontainers#18 from RobDolinMS/master, 2016-09-18). I'd rather drop the parenthetical entirely and link to a place that listed OCI Projects, but we don't have a canonical target for that yet (opencontainers/tob#2) and the current closest instance seems to be the GitHub section in [1] (which doesn't have the "OCI Project" words). [1]: https://www.opencontainers.org/community Signed-off-by: W. Trevor King <wking@tremily.us>
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.