> It seems all rules on voting are predicated on the question being binary
ASF votes are meant to be - as far as possible - a formality confirming
consensus, or something to resolve irreconcilable disagreements. The
discussion section describes how to build consensus when there are multiple
options, or multiple areas of disagreement on a proposal, by using indicative
votes (with multiple options, via e.g. instant runoff), that are not binding
and can be used to modify the proposal so that the vote is on a binary question
with broad support.
> Regarding the PMC roll call, is there any definition of "active on the
> project and want to participate"?
There are a lot of points to nail down, and the roll call was something that
only barely squeezed a win in indicative votes on the private list, and is very
much still up for debate - including the window (a week would also seem fine).
There's also a question over the vote floor, both for procedural and CEP votes.
There was a clear majority for super-majority decisions, and for determining
the "active electorate" by _some_ mechanism (dev@ and private@ participation
were discussed as well), but to avoid perverse voting incentives we need to
determine a floor for _votes in favour_ rather than _participants_, else we
disincentivise voting against proposals that have not yet reached a quorum.
The proposal currently requires a super-majority of the "active electorate" as
well, but this is probably too strong, and simple majority of the active
electorate, plus super-majority of voters is probably more than sufficient to
claim consensus.
> Will the PMC roll call apply to the PMC itself? That was my original read of
> it but looking closer, its an email to dev@.
That's the idea, but we're aiming to keep as much in public as possible.
> The bar regarding code review
This is another whole rabbit hole of a discussion, but:
- I agree that we should carve out some extra cheap consensus options, such as
perhaps tests; if we can source a community list of clearly defined items that
would be great
- The 2 +1 votes does not mean both need to have reviewed the change, it just
means that two committers have taken a look and agreed adequate work appears to
have been done; a skim of the patch and knowledge of the experience of the
proposer and reviewer will often suffice, but it means new contributors and
relatively junior committers are less likely to accidentally commit something
with wider ramifications than they realise. The practical implications should
be minimal. I have tried to clarify that in the document, with a separate item
expressly requiring one review for all changes.
- I hope to strengthen the requirement to 3 + 1 votes, at least two of which
committers, with at least two concrete reviews for any moderate complexity
work, but this is for another discussion
On 04/06/2020, 18:29, "Murukesh Mohanan" <murukesh.moha...@gmail.com> wrote:
A couple of thoughts:
1. It seems all rules on voting are predicated on the question being
binary. Perhaps we should also tack on a section for cases where we have to
pick among multiple options (a simple plurality, maybe).
2. Should this itself be a CEP? (E.g., Python's governance model was
proposed in PEPs 8010 through 8016 ([1][2] etc.) and codified in PEP 13
[3], PHP's voting system was iterated upon recently in their equivalent, an
RFC [4]) Or perhaps not, since the current CEP description suggests that
CEPs are exclusively for code changes? (If that's the case, we could
discuss that at a later date, and move on with this proposal first.)
[1]: https://www.python.org/dev/peps/pep-8015/
[2]: https://www.python.org/dev/peps/pep-8016/
[3]: https://www.python.org/dev/peps/pep-0013/
[4]: https://wiki.php.net/rfc/abolish-narrow-margins
Yours,
Murukesh Mohanan
On Fri, 5 Jun 2020 at 01:54, Joshua McKenzie <jmcken...@apache.org> wrote:
> Hello project!
>
> The pmc has been discussing how we make decisions as a pmc, how we make
> decisions as a project of committers and contributors, what decisions are
> made where, and how those decisions are ratified and by whom. We came to
> the conclusion that there's value in having a more formal (though
> lightweight) structure around these topics as well as start to enumerate
> some expectations on how we interact with each other on the project as it
> matures.
>
> A link to the current draft of the governance doc is here:
>
>
https://docs.google.com/document/d/1wOrJBkgudY2BxEVtubq9IbiFFC3d3efJSj9OIrGcqQ8/edit#
>
> The doc is only 2 pages long; if you're interested in engaging in a
> discussion about how we evolve and collaborate as a project, please take
> some time to read through the doc, think through things, and engage on
this
> thread here.
>
> Thanks everyone, and looking forward to a great discussion!
>
> ~Josh McKenzie
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
