Our by-laws, at a very minimum, should include: - Definitions of roles - Definitions of voting rules - Decision categories and the associated voting rules
I am +1 for CTR. I think that we should trust committers to perform whatever review is necessary before committing somebody else's changeset/patch. That is, if a committer spots a patch that they like, they are free to commit that using CTR. On 22 November 2013 11:44, Kasper Sørensen <[email protected]> wrote: > Hi all, > > For some time we've had this DRAFT bylaws document on the wiki: > https://wiki.apache.org/metamodel/Bylaws > > As Noah pointed out in another thread [1], the current bylaws wiki page > raises a few concerns. And the question of Commit-The-Review (CTR) or > Review-Then-Commit (RTC) is once again opened. > > I call for a discussion on what people's preferences are in terms of the > things we want to have in our bylaws. The current wiki page is a very close > adaptation of the Kafka project's bylaws, and maybe that was a wrong move, > seeing that it didn't leave much room for us to come up with something from > our own standpoints. > > My personal feelings on bylaws: I am thinking maybe we can cut down on the > number of things we want to regulate, to make our own life easier. I think > committers could be granted the right to follow a CTR process. > Contributions from newcomers should obviously by reviewed by submitting > patch files or pull requests and having a voting/approval procedure. Lazy > concensus in such situations would maybe require more than 1 vote (2 or 3), > since it's coming from a newcomer. > > Hope to get a lot of valuable feedback on this. And if anyone wants to take > the lead on the bylaws I would be grateful, since I am myself a bit of a > newcomer in this area! > > Kasper > > [1] Called "How to vote on a patch in JIRA". -- Noah Slater https://twitter.com/nslater
