On Fri, May 10, 2013 at 2:08 PM, Noah Slater <[email protected]> wrote: > I am not thrilled about the idea of increasing lazy consensus time. If > you're engaged with the mailing list, then you can pitch in. If not, then > things are going to happen in your absence. I think that three days is a > fair trade-off between wanting to move quickly, and wanting to make sure > that people with day-jobs can contribute in their spare time. > > Note that some projects have it in their by-laws that weekends and holidays > don't count. I think I would be +0 on that change, if somebody wanted to > propose it. > > I would ask though: what problem are we actually trying to solve here? I'm > not aware of any instance when something passed on lazy consensus that was > later considered to be a mistake. And by extension, I know of zero > instances where an increased waiting period would have changed anything. > > So why bother? :) > > However, I do think we have some confusion about how decision-making > actually happens. Like, if I want to do X, is lazy consensus okay? Do I > need a vote? If I need a vote, what sort of vote? Majority approval? > Majority consensus? Single Transferable Vote? I think we ought to discuss > these things, and document them in a set of by-laws. > > And yes, I use "NOTICE" to mean "this thing happened" or "this thing will > happen". i.e. It's not something I'm opening up for discussion or lazy > consensus. It's just a statement of intention, or fact. > > I think perhaps it would be a good idea to document the tags we're expected > to use. (Though, I think, it can only ever be a recommendation. People will > forget, etc.) > > I am happy to start using "PROPOSAL" to mean "this is a proposal and lazy > consensus is in effect". > > Okay, so I just read this again: > > http://rave.apache.org/docs/governance/lazyConsensus.html > > Wow. What a great document. > > So, it makes it clear that you can actually just *assume* lazy consensus in > everything you do. (Very important!) So no need to explicitly start a > thread to try and get it. If you're confident, you can just go ahead and do > the thing. Woop.
Yep. That's what I was after with my definition clarification. In line with what I was saying. > > So, to summarise how I think we should document this in our by-laws: > > 1) Most of the time, you can assume you have consensus for whatever it is > you want to do. So have at it! Yes. Yes. As above. Yes. > > 2) Some of the time, you might be a little unsure. In those instances, you > should make a proposal to the dev@ list, and tag the subject with > "PROPOSAL". Mention that lazy consensus is in effect, and after 72 hours > you can proceed. +1 > > 3) There are some specific things that always need a proposal to be made. > That is, you cannot assume consensus. You must make the proposal, and give > 72 hours for people to object. Those things are: [...] +1 > > And how about this for the tags we're using: > > DISCUSS - This is an open discussion with no time limit > > REQUEST - This is a request for some action to be taken (prepare release > notes, testing, merge, etc) > > PROPOSAL - This is a concrete proposal with consensus in effect and a 72 > hour time limit > > VOTE - This is a formal vote with a 72 hour time limit > > NOTICE - This is a notice of action taken, or action about to be taken > (i.e. no discussion or consensus needed) > > ANNOUNCE - This is a project level announcement +1 I think PROPOSAL helps here. This way I can filter VOTE and PROPOSAL and make sure I make time to address those threads when I have an opinion, and to do it within 72 hours. I would be +1 on not counting weekends. And this agrees with my assessment that DISCUSS is not really the place to set a time limit. Benoit, does this address your concerns? I've said my interpretation of your objections but I don't want to misrepresent you. When I read "abuse" I read it as "A DISCUSS thread is really not the place to expect a fast response and therefore taking action after 72 hours feels like an abuse."
