I'd prefer the mail vote before major changes (this is also the preferred Apache guideline if I'm not mistaken).
Writing down the basics on a wiki makes it clearer and also easier for new contributors to get involved. This page is somewhat related though (at least for voting): http://www.apache.org/foundation/voting.html On Fri, Sep 5, 2014 at 12:50 PM, Stephan Ewen <[email protected]> wrote: > Hi! > > I think part of the discussion that arose around the proposed Java/Scala > and RPC/Akka changes comes from the fact that we have not clearly written > down the community/committing rules anywhere yet. In particular, how do we > treat proposed major changes. > > Most of us (including me) worked under the assumption that committers can > commit small fixes immediately, and those can be vetoed (reverted) in > hind-sight by others (has not yet happened, though). > > Anything that has impact on other people goes through pull requests, and is > then discussed upon, revised, or rejected. This seems to be the model that > many other Apache projects use (like Mahout for example, Sebastian, correct > my if I am wrong there). > > That has seemed to work so far, and in that sense, the use of Akka for > example is still a proposal only. > > For major refactorings like the RPC/Actor one, it makes sense to try and > reach consensus before the implementation effort, because it is too much > work to do it without knowing that it will be accepted. This may be a vote, > but I would prefer it to be rather lightweight, like dropping a mail on the > dev list, giving people an early chance to voice concerns. > > Does it make sense to write these simple rules down somewhere (wiki?), so > that it is transparent? > > Stephan >
