Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Thu, May 9, 2013 at 7:26 PM, Noah Slater nsla...@apache.org wrote: I'm not sure what you find offensive in my email. I was pointing out that your understanding of lazy consensus is incorrect. And the arguments you make from that misunderstanding are similarly incorrect. You came close to making a concrete proposal, but fell slightly short of the mark. Things like this, for instance: So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. This is too vague to really talk about. What is something tagged as [DISCUSS]? What gets tagged with [DISCUSS]? Is it two weeks, or one month? There are many things that need clarifying before we can move forward productively. When I commented on some of the inaccuracies in your email, you started to rail against me. Coming up with things like suggesting that people have ignored objections, or that people are abusing the process, or that things are borderline. But you have not actually given any concrete examples. So, again, it is practically impossible to have a discussion. The purpose of this discuss thread was discussing hence the tag [DISCUSS]. Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. All I wanted is discussing what I considered an abuse and make some proposals. It should have been more clear. Anyway If you didn't found it clear or wanted it more precise then it's all that should have been asked. Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. And sorry but you have no authority on my mind to define what *I* call an abuse. I am not suggesting that we don't discuss things, or that some thing shouldn't be discussed. I am saying that you do not need to give the whole community a set of options before you make any sort of decision. That is the surest way I can think of to make sure that no decisions ever get made, and that CouchDB continues to grow more and more sclerotic. The problem the last few years is actually more like this: a smart, passionate user comes along with an idea that they believe will benefit the project. When they suggest it, they are met with a bunch of objections. But they are objections in the form of I don't like this idea because it's not exactly like how I would do it. Which wouldn't be so bad, if those people actually went ahead and did anything. But they don't. So what this forms is a big wall of stop energy that nothing ever gets passed. Not only the problem is that some proposed threads didn't have discussions at all, either purely or violently objected or simply ignored. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions to make an idea happen, the problem is more like: working on taking all new ideas in a positive manner, and being open even if the idea sounds stupid at first. Also listening about differences. Something that we still have to work on imo. That and taking ideas in consideration more rapidly. But that has nothing with lazy consensus. Not everything require to take decisions, some are just questions to validate a point or a concept related to the project or an idea someone can have. I see hints of this in your response. It sounds like you're saying that before we do anything, we have to discuss it, and everybody needs a chance to review the options, and then we can move forward. But to me, that sounds a big sticking pile of bureaucratic crap that we're heaping on to the project because we're too afraid of change or loss of control. That exactly my thinking about the lazy concensus *by default*: a buraucratic crap and a way to not share the control with the community or make it harder to do it. And this discussion make me think that my next proposal to go to a RTC policy [1] will have the same kind of reaction. But this is another topic,. [1] http://www.apache.org/foundation/glossary.html#ReviewThenCommit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 10:39 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Thu, May 9, 2013 at 7:26 PM, Noah Slater nsla...@apache.org wrote: I'm not sure what you find offensive in my email. I was pointing out that your understanding of lazy consensus is incorrect. And the arguments you make from that misunderstanding are similarly incorrect. You came close to making a concrete proposal, but fell slightly short of the mark. Things like this, for instance: So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. This is too vague to really talk about. What is something tagged as [DISCUSS]? What gets tagged with [DISCUSS]? Is it two weeks, or one month? There are many things that need clarifying before we can move forward productively. When I commented on some of the inaccuracies in your email, you started to rail against me. Coming up with things like suggesting that people have ignored objections, or that people are abusing the process, or that things are borderline. But you have not actually given any concrete examples. So, again, it is practically impossible to have a discussion. The purpose of this discuss thread was discussing hence the tag [DISCUSS]. Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. All I wanted is discussing what I considered an abuse and make some proposals. It should have been more clear. s/failed/felt Anyway If you didn't found it clear or wanted it more precise then it's all that should have been asked. Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. And sorry but you have no authority on my mind to define what *I* call an abuse. I am not suggesting that we don't discuss things, or that some thing shouldn't be discussed. I am saying that you do not need to give the whole community a set of options before you make any sort of decision. That is the surest way I can think of to make sure that no decisions ever get made, and that CouchDB continues to grow more and more sclerotic. The problem the last few years is actually more like this: a smart, passionate user comes along with an idea that they believe will benefit the project. When they suggest it, they are met with a bunch of objections. But they are objections in the form of I don't like this idea because it's not exactly like how I would do it. Which wouldn't be so bad, if those people actually went ahead and did anything. But they don't. So what this forms is a big wall of stop energy that nothing ever gets passed. Not only the problem is that some proposed threads didn't have discussions at all, either purely or violently objected or simply ignored. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions to make an idea happen, the problem is more like: working on taking all new ideas in a positive manner, and being open even if the idea sounds stupid at first. Also listening about differences. Something that we still have to work on imo. That and taking ideas in consideration more rapidly. But that has nothing with lazy consensus. Not everything require to take decisions, some are just questions to validate a point or a concept related to the project or an idea someone can have. I see hints of this in your response. It sounds like you're saying that before we do anything, we have to discuss it, and everybody needs a chance to review the options, and then we can move forward. But to me, that sounds a big sticking pile of bureaucratic crap that we're heaping on to the project because we're too afraid of change or loss of control. That exactly my thinking about the lazy concensus *by default*: a buraucratic crap and a way to not share the control with the community or make it harder to do it. And this discussion make me think that my next proposal to go to a RTC policy [1] will have the same kind of reaction. But this is another topic,. [1] http://www.apache.org/foundation/glossary.html#ReviewThenCommit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and make some proposals. Sure. I've invited you to make your proposals. I really hope you do! Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. I am asking you to provide specific examples. We can't talk about this meaningfully with them. Not only the problem is that some proposed threads didn't have discussions at all Decision making does not require discussion. Sometimes discussion is good. Sometimes it is needless. either purely or violently objected or simply ignored Third time you say this without any evidence. Please provide evidence. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. Why is that a bad thing? Stuff gets recycled. I'm grateful that things are picked up eventually.(Unless your problem is with the credit. Which I don't give two shits about. That's some meaningless ego thing.) The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions One of three things must be the case: 1) You don't understand how lazy consensus works, and so you perceive it as a way to force through decisions without discussion. 2) You understand how lazy consensus works, but you disagree with it on principal, because you believe _all decisions_ require discussion. (Please note how broad the category of all is in this context.) 3) You understand how lazy consensus works, and can see it has useful application, but you believe that somebody on this project used lazy consensus to ram through a decision which should have been handled with a discussion. Please clarify which one of these is the case, and if it is 3, please provide a reference to the thread where you believe this happened. working on taking all new ideas in a positive manner, and being open even if the idea sounds stupid at first. Also listening about differences. Something that we still have to work on imo. Agree. It would be good if we got better at this. That exactly my thinking about the lazy concensus *by default*: a buraucratic crap and a way to not share the control with the community or make it harder to do it. Then I think you must misunderstand what bureaucratic means. Two possible definitions: 1) Making it harder for people to do things by imposing rules, and policy, adding additional steps you must go through to get anything done. 2) Making it easier for people to do things by simplifying rules, and streamlining policy, and removing steps you must go through to get anything done. Most people would say bureaucratic means 1. And I think most people would say that imposing the requirement of discussion, followed by a 1 month wait period before _any_ decision can be made qualifies. And I think most people would say that lazy consensus is more along the lines of 2. And this discussion make me think that my next proposal to go to a RTC policy [1] will have the same kind of reaction. I expect so. We have version control for a reason. And from what I have seen across the rest of the foundation, RTC is imposed by sclerotic projects paralysed by their fear. I am open to having this conversation, but I am requesting that you make things more concrete. Specifically: 1) Provided references for your statements about certain threads where this abuse is happening. 2) Draft a set of by-laws that we can debate. -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit On Fri, May 10, 2013 at 4:48 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and make some proposals. Sure. I've invited you to make your proposals. I really hope you do! Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. I am asking you to provide specific examples. We can't talk about this meaningfully with them. Not only the problem is that some proposed threads didn't have discussions at all Decision making does not require discussion. Sometimes discussion is good. Sometimes it is needless. either purely or violently objected or simply ignored Third time you say this without any evidence. Please provide evidence. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. Why is that a bad thing? Stuff gets recycled. I'm grateful that things are picked up eventually.(Unless your problem is with the credit. Which I don't give two shits about. That's some meaningless ego thing.) The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions One of three things must be the case: 1) You don't understand how lazy consensus works, and so you perceive it as a way to force through decisions without discussion. 2) You understand how lazy consensus works, but you disagree with it on principal, because you believe _all decisions_ require discussion. (Please note how broad the category of all is in this context.) 3) You understand how lazy consensus works, and can see it has useful application, but you believe that somebody on this project used lazy consensus to ram through a decision which should have been handled with a discussion. Please clarify which one of these is the case, and if it is 3, please provide
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
Benoit, Please produce a draft of the by-laws you would like to see. Thanks, On 10 May 2013 19:30, Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit On Fri, May 10, 2013 at 4:48 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and make some proposals. Sure. I've invited you to make your proposals. I really hope you do! Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. I am asking you to provide specific examples. We can't talk about this meaningfully with them. Not only the problem is that some proposed threads didn't have discussions at all Decision making does not require discussion. Sometimes discussion is good. Sometimes it is needless. either purely or violently objected or simply ignored Third time you say this without any evidence. Please provide evidence. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. Why is that a bad thing? Stuff gets recycled. I'm grateful that things are picked up eventually.(Unless your problem is with the credit. Which I don't give two shits about. That's some meaningless ego thing.) The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions One of three things must be the case: 1) You don't understand how lazy consensus works, and so you perceive it as a way to force through decisions without discussion. 2) You understand how lazy consensus works, but you disagree with it on principal, because you believe _all decisions_ require discussion. (Please note how broad the category of all is in this context.) 3) You understand how lazy consensus works, and
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. Jan -- On May 10, 2013, at 19:30 , Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit On Fri, May 10, 2013 at 4:48 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and make some proposals. Sure. I've invited you to make your proposals. I really hope you do! Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. I am asking you to provide specific examples. We can't talk about this meaningfully with them. Not only the problem is that some proposed threads didn't have discussions at all Decision making does not require discussion. Sometimes discussion is good. Sometimes it is needless. either purely or violently objected or simply ignored Third time you say this without any evidence. Please provide evidence. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. Why is that a bad thing? Stuff gets recycled. I'm grateful that things are picked up eventually.(Unless your problem is with the credit. Which I don't give two shits about. That's some meaningless ego thing.) The problem is not to force decisions (yes I call it forcing) by using lazy consensus without prior discussions One of three things must be the case: 1) You don't understand how lazy consensus works, and so you perceive it as a way to force through decisions without discussion. 2) You
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
It's also perfectly fine to respond saying woah there cowboy, we need to discuss this first. On 10 May 2013 19:47, Jan Lehnardt j...@apache.org wrote: Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. Jan -- On May 10, 2013, at 19:30 , Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit On Fri, May 10, 2013 at 4:48 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and make some proposals. Sure. I've invited you to make your proposals. I really hope you do! Also I don't have to give concrete examples since the problem I describe use lazy-consensus all the time and only propose 72 hours to react is the abuse. You may disagree with that but this is what I call an abuse. I am asking you to provide specific examples. We can't talk about this meaningfully with them. Not only the problem is that some proposed threads didn't have discussions at all Decision making does not require discussion. Sometimes discussion is good. Sometimes it is needless. either purely or violently objected or simply ignored Third time you say this without any evidence. Please provide evidence. Worst case an idea/code from an ignored thread came 1 year or 2 year after is presented as a new thing. Why is that a bad thing? Stuff gets recycled. I'm grateful that things are picked up eventually.(Unless your problem is with the credit. Which I don't give two shits about. That's some meaningless ego thing.) The problem is not to force decisions (yes I call it forcing) by
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I'll hop in to repeat my observation one more time and offer evidence of the behavior which caused me to empathize with Benoit. In the recent email about old releases tagged [DISCUSS] Noah said: If nobody objects in 72 hours, I will assume lazy consensus and proceed. I like lazy consensus and consider it rolling and ubiquitous in the actions of committers and in play even as we make decisions with zero discussion. We act because we *believe* we would have consensus. In every case where there is no formal discussion I believe I am representing my best guess at what *would be* explicit consensus if it were discussed. This is my understanding of lazy consensus but I'm happy to be corrected. However, 72 hours seems antithetical to discussion. If you call for discussion because you want feedback, please give some time, especially when it's not urgent. I'm not sure it is necessary to say exactly how long. That's a concrete recommendation from me. I hope that is constructive and can help resolve this discussion. On May 10, 2013 11:50 AM, Noah Slater nsla...@apache.org wrote: It's also perfectly fine to respond saying woah there cowboy, we need to discuss this first. On 10 May 2013 19:47, Jan Lehnardt j...@apache.org wrote: Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. Jan -- On May 10, 2013, at 19:30 , Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit On Fri, May 10, 2013 at 4:48 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 09:39, Benoit Chesneau bchesn...@gmail.com wrote: Though I failed in this bad (imo) habit we took recently to propose decisions before discussing the foundations of this discussion. Not everything needs to be discussed. All I wanted is discussing what I considered an abuse and
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
Randall, I think I understand your argument. Would it be true to say that you think that DISCUSS threads should be reserved for actual discussion, and that we need a new tag for the threads which give notice about lazy consensus? On 10 May 2013 20:00, Randall Leeds randall.le...@gmail.com wrote: I'll hop in to repeat my observation one more time and offer evidence of the behavior which caused me to empathize with Benoit. In the recent email about old releases tagged [DISCUSS] Noah said: If nobody objects in 72 hours, I will assume lazy consensus and proceed. I like lazy consensus and consider it rolling and ubiquitous in the actions of committers and in play even as we make decisions with zero discussion. We act because we *believe* we would have consensus. In every case where there is no formal discussion I believe I am representing my best guess at what *would be* explicit consensus if it were discussed. This is my understanding of lazy consensus but I'm happy to be corrected. However, 72 hours seems antithetical to discussion. If you call for discussion because you want feedback, please give some time, especially when it's not urgent. I'm not sure it is necessary to say exactly how long. That's a concrete recommendation from me. I hope that is constructive and can help resolve this discussion. On May 10, 2013 11:50 AM, Noah Slater nsla...@apache.org wrote: It's also perfectly fine to respond saying woah there cowboy, we need to discuss this first. On 10 May 2013 19:47, Jan Lehnardt j...@apache.org wrote: Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. Jan -- On May 10, 2013, at 19:30 , Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept its use. All the rest is out of topic. Though the thing wasn't a question of ego. You missed the point. The problem was the lack of communication. But this is out of topic and I won't answer to that here. To make it more clear since you asked it. This discussion is about discussing the use of the lazy consensus *by default* and for me it should be just an option, not something use for anything. It all depends on the context. And in any case think more about the delay you give depending on the importance of the decision or the urgency. To say it another way: this discussion is about the proposed policy to use the lazy consensus *by default*. I hope it's clear now. And this discussion is perfectly legal imo. Voila. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 12:34 PM, Noah Slater nsla...@apache.org wrote: Randall, I think I understand your argument. Would it be true to say that you think that DISCUSS threads should be reserved for actual discussion, and that we need a new tag for the threads which give notice about lazy consensus? Or perhaps no tag, since my understanding of lazy consensus is that one needn't call for it, one surmises it through general awareness and sensitivity to what is and is not likely to be controversial or require input. In my description of lazy consensus I was sort of saying that every commit in CTR is an instance of lazy consensus wherein the committer has taken action they believe would be representative of a consensus opinion without actually asking for it, i.e. lazily. So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful that discussion suggests ample allotment of time for discussion. I don't believe we need a specific tag for lazy consensus because I agree with you that it's the default operating mode. On 10 May 2013 20:00, Randall Leeds randall.le...@gmail.com wrote: I'll hop in to repeat my observation one more time and offer evidence of the behavior which caused me to empathize with Benoit. In the recent email about old releases tagged [DISCUSS] Noah said: If nobody objects in 72 hours, I will assume lazy consensus and proceed. I like lazy consensus and consider it rolling and ubiquitous in the actions of committers and in play even as we make decisions with zero discussion. We act because we *believe* we would have consensus. In every case where there is no formal discussion I believe I am representing my best guess at what *would be* explicit consensus if it were discussed. This is my understanding of lazy consensus but I'm happy to be corrected. However, 72 hours seems antithetical to discussion. If you call for discussion because you want feedback, please give some time, especially when it's not urgent. I'm not sure it is necessary to say exactly how long. That's a concrete recommendation from me. I hope that is constructive and can help resolve this discussion. On May 10, 2013 11:50 AM, Noah Slater nsla...@apache.org wrote: It's also perfectly fine to respond saying woah there cowboy, we need to discuss this first. On 10 May 2013 19:47, Jan Lehnardt j...@apache.org wrote: Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. Jan -- On May 10, 2013, at 19:30 , Benoit Chesneau bchesn...@gmail.com wrote: I'm starting to think you don't read me carefully enough. I don't care about giving any evidence. The topic is about giving more time to the discussion. The principle of using *by default* lazy consensus is what I consider an abuse. I explained it why third time in that thread. And already did it before that mail. But you refuse to take my arguments in consideration keeping to ask me to show you how thing turned out to be wrong. Which is not the topic. The problem by using lazily consensus over a shot time is that you don't let people think about it much. Which wouldn't be a problem if there was an intense communication between people. But this isn't the case today. Some ideas are still coming from nowhere without preparation. Don't get me wrong I don't say that these ideas are bad or that there wasn't any thinking behind them. No the problem is you expect that people are able to answer it in 72 h or so. your time. Which don't let sometime the time to think much about it and give your opinion or possible changes to it. Sometimes you really want to tell a thing but finally can't do it because of timing issues. (Sometimes yes, you 3 days are really short). Maybe it could be just by saying it (like hey I really want to answer but i don't have the time) which I think could work. But I clearly think that in that case just giving more time or simply not using lazy consensus could just work. This is why I propose to adapt the time asked for a lazy consensus depending on the context, ie. not using 72 h by convenience. The delays proposed were just some suggestions. To be clear, I strongly disagree to use the lazy consensus as *the default* way to take decisions. The apache way considers it as an important and main way to build (some kind of) consensus. But main != default . It is also saying that we should try to build a consensus first. But not it is not saying that *lazy* consensus must be used by *default*. By culture I don't like anything that is lazy by default but I can accept
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 8:47 PM, Jan Lehnardt j...@apache.org wrote: Maybe what is missing from this is that lazy consensus leads to things that can never every be changed again. It is just a tool to keep a distributed team going. If we do a thing and it gets lazy consesus’d and implemented and even shipped, we can still *at any time* realise it was a mistake, make a course correction or revert and move on. It is unfortunately not true for everything. That is why lazy consensus is adapted to code but quite more complex to use in other cases. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
+1 - agree with all of Randall's points On Friday, 10 May 2013 at 20:39, Randall Leeds wrote: So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful that discussion suggests ample allotment of time for discussion. I don't believe we need a specific tag for lazy consensus because I agree with you that it's the default operating mode.
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 8:46 PM, Noah Slater nsla...@apache.org wrote: Benoit, Please produce a draft of the by-laws you would like to see. Thanks, I'm not sure what yo mean by-laws here. But I will draft a set of rules I have in mind. Not until next week anyway since I am working on some other topics right now. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 10 May 2013 20:39, Randall Leeds randall.le...@gmail.com wrote: So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful that discussion suggests ample allotment of time for discussion. I don't believe we need a specific tag for lazy consensus because I agree with you that it's the default operating mode. Randall, My only issue here is that I think URGENT misses the mark also. There are several community / project-level things that one might want to do where all you really ought to do is notify dev@ that you're about to do it. Some examples I can think of: * Big changes to the website * Big changes to the wiki * Changes in stuff like release procedure * Archiving releases * Planning marketing activity * Getting approval for small events * Getting branding approval There are plenty more. So, I guess what I'm trying to say is that I'm more than happy only using DISCUSS to mean here's an open ended discussion, but I want a tag that means here's something I'm about to do. I agree that we don't need a specific tag for lazy consensus, simply because lazy consensus is the default. But if DISCUSS is causing some people to think oh well, I'll read that next week when I have time then it would be handy to be able to explicitly tag a thread with this is something that is about to happen, so speak up now. And I don't think URGENT is the right tag. Because archiving a release isn't urgent. But I _will_ be moving ahead if I don't hear any objections about it. Do you see what I mean? On 10 May 2013 20:45, Benoit Chesneau bchesn...@gmail.com wrote: I'm not sure what yo mean by-laws here. But I will draft a set of rules I have in mind. Not until next week anyway since I am working on some other topics right now. - benoit Starting points: http://hadoop.apache.org/bylaws.html http://hc.apache.org/bylaws.html http://struts.apache.org/release/1.2.x/bylaws.html -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 1:16 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 20:39, Randall Leeds randall.le...@gmail.com wrote: So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful that discussion suggests ample allotment of time for discussion. I don't believe we need a specific tag for lazy consensus because I agree with you that it's the default operating mode. Randall, My only issue here is that I think URGENT misses the mark also. There are several community / project-level things that one might want to do where all you really ought to do is notify dev@ that you're about to do it. Some examples I can think of: * Big changes to the website * Big changes to the wiki * Changes in stuff like release procedure * Archiving releases * Planning marketing activity * Getting approval for small events * Getting branding approval There are plenty more. So, I guess what I'm trying to say is that I'm more than happy only using DISCUSS to mean here's an open ended discussion, but I want a tag that means here's something I'm about to do. I agree that we don't need a specific tag for lazy consensus, simply because lazy consensus is the default. But if DISCUSS is causing some people to think oh well, I'll read that next week when I have time then it would be handy to be able to explicitly tag a thread with this is something that is about to happen, so speak up now. And I don't think URGENT is the right tag. Because archiving a release isn't urgent. But I _will_ be moving ahead if I don't hear any objections about it. Do you see what I mean? Yes. If it's something worth bringing up to the list at all, and it's not urgent, then maybe one should wait longer than 72 hours before moving ahead. I know it's a small increase in workflow burden to keep a loop open for longer. How about [NOTICE]? You use that sometimes. What exactly do you use it for? That sounds a bit to me like you should read this, but I'm not expecting discussion. Perhaps that's a better tag for this sort of thing than [DISCUSS]?
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
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. But, if you are a bit hesitant, then you can make your proposal and explicitly state that lazy consensus is in operation. To wit: The concept of Lazy Consensus is very important in our project. Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. // [...] // Sometimes a member of the community will believe a specific action is the correct one for the community but are not sure enough to proceed with the work under the lazy consensus model. In these circumstances they can state Lazy Consensus is in operation. // What this means is that they make a proposal and state that they will start implementing it in 72 hours unless someone objects. 72 hours is chosen because it accounts for different timezones and non-apache commitments. Very well articulated. Also, note, that there ought to be certain circumstances where it is mandated that a proposal be made before the action is taken. For example: small events and branding approval. I think I would want those things to be proposed each time. 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! 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. 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: [...] 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 On 10 May 2013 21:23, Randall Leeds randall.le...@gmail.com wrote: On Fri, May 10, 2013 at 1:16 PM, Noah Slater nsla...@apache.org wrote: On 10 May 2013 20:39, Randall Leeds randall.le...@gmail.com wrote: So I'd prefer to see [DISCUSS] and [URGENT] used and just be mindful that discussion suggests ample allotment of time for discussion. I don't believe we need a specific tag for lazy consensus because I agree with you that it's the default operating mode. Randall, My only issue here is that I think URGENT misses the mark also. There are several community / project-level things that one might want to do where all you really ought to do is notify dev@ that you're about to do it. Some examples I can
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Fri, May 10, 2013 at 2:08 PM, Noah Slater nsla...@apache.org 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.
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
Cool! BTW, that should have read: PROPOSAL - This is a concrete proposal with lazy consensus in effect and a 72 hour time limit On 10 May 2013 22:27, Randall Leeds randall.le...@gmail.com wrote: On Fri, May 10, 2013 at 2:08 PM, Noah Slater nsla...@apache.org 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. -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Thu, May 9, 2013 at 2:02 AM, Noah Slater nsla...@apache.org wrote: On 7 May 2013 20:07, Benoit Chesneau bchesn...@gmail.com wrote: Lazy consensus give this false idea that because no-one objected in time then it's OK to process. This is not a false idea. This principal sites at the very core of how we do things at Apache. It is, the way I described it. Lazy consensus aren't here to obtain a real consensus. I won't repeat myself. I will just re-quote the apache documentation: Reasons for Votes People tend to avoid conflict and thrash around looking for something to substitute - somebody in charge, a rule, a process, stagnation. None of these tend to be very good substitutes for doing the hard work of resolving the conflict. Looking for consensus is harder than simply asking to a a vote where you can't really object and that is not really waiting an answer. That could be true if the expected response was not in a short delay or asked before a we 72 hours to gauge lazy consensus is a standard across all 130 Apache TLPs. It isn't a standard, but a convenience. It strikes the balance between being able to move quickly, and being considerate of other people's time. So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. I think this is much too long a time to expect people to wait before they can assume lazy consensus We need to become *lighter* in our decision making process, not heavier. Having said that, you are free to try and build consensus around your idea. Please note that unless consensus can be established to change the notice period, the status quo will be maintained, which is 72 hours. Sorry? I didn't ask for a lazy consensus, nor set a delay. I am trying to reach a... consensus ... I will summarize what have been discussed in time. If nonone object I would like to push the delay of such discussion to 2 weeks by default . I am -1 on this. I do not want to slow down the decision making process. We cannot stall our already embarrassingly slow velocity because some people in the community only check their Apache email once a fortnight. If you want to be involved more, check your email more. If you can't check your email more, then recognise that some decisions are going to be made in your absence. Lazy consensus were designed for votes on the code originally. Voting on the code is only requiring a lazy consensus most of the time. Voting on a decision that engage all the community shouldn't be lazy most of the time. Decisions on things that engage community should be presented as a choice. And since the objections made on lazy consensus can be properly ignored ( at least they had in the past) then it should only be used for things that doesn't require a real consensus or agreement from most. Lazy consensus should be used to determine the sense of the community when you estimate it doesn't require a real consensus. Lazy consensus should be used as a last resort not as a common tool to pass decisions. This is how they are described. Urgent thing should be marked as is on the ml, and probably only require some people. Also i really would like that such concensus should be optionnal not a common thing to use to pass ideas. This isn't natural at all. Lazy consensus is the *default* decision making process at Apache. We do it like this precisely because it is hard to co-ordinate a team when people are unreliable, busy, and distributed across the globe. It isn't. Lazy-consensus is a way to vote. We have different ways to vote: - Votes - Votes on release aren't lazy consensus, they require a majority (but no veto) - Lazy consensus : lazy consensus are generally used for a code update, change a word in a page, etc but not for other things. But votes aren't the default way to get decisions. Votes are a way to ask for a decision but shouldn't be used as the default to take these decisions. I won't quote the voting page again. As for the abuse of DISCUSS threads, I can only assume that is targeted at me, as I have been doing most of the project co-ordination the last few months. If you could provide specifics, that would be useful. No it isn't targeted at you. When I want to fix problems with people I contact them privately. I'm targeting the use of the lazy consensus to take decisions as a default. I would be happy to use the subject tag PROPOSAL when lazy consensus is being used, to separate these threads out from general DISCUSS threads. Please note, however, that in my mental model of how Apache works, a DISCUSS thread *is* a discussion that will default to lazy consensus. That is how I have always used that tag. If you think it's confusing, let's propose a new tag. I can see a lot of discussion threads that didn't ask for a consensus. Mail can be tagged or not, i have no strong opinion on that. Proposal doesn't fit well though,
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Thu, May 9, 2013 at 4:02 AM, Noah Slater nsla...@apache.org wrote: On 9 May 2013 01:02, Noah Slater nsla...@apache.org wrote: I would be happy to use the subject tag PROPOSAL when lazy consensus is being used, to separate these threads out from general DISCUSS threads. Please note, however, that in my mental model of how Apache works, a DISCUSS thread *is* a discussion that will default to lazy consensus. That is how I have always used that tag. If you think it's confusing, let's propose a new tag. I will note, actually, that the tag I put in the email thread is besides the point. That's just a matter of courtesy. The default model that we operate under is that if I announce my intentions to the dev@ list, then you have 72 hours to object. This works for two reasons: 1) People are elected to committer, primarily, because we *trust* them. That means we trust them to act in the best interests of the project. 2) If you care about this stuff, you need to be monitoring dev@ and you need to be voicing your objections. If you are not doing this, you cannot expect the project to slow down to suit your pace. This mail is not about trusting or not people. This not the topic at all. I tend to ignore people I don't trust. Also this isn't because you're interested in a topic that you have to be connected every-time. And I do think that important decisions can't be done on lazy consensus without to make sure you targeted most of the people that needed to be aware. This how it works, even in companies that take care about people. This thread is about trying to fix the usage of the lazy discuss votes. If they are used as a tool to pass ideas and if they really accept to be denied then I am strongly asking to adapt the delay depending on the importance on what is asked. Again I'm not speaking about code. But lazy consensus, or votes shouldn't be used as the default to make decisions imo. There are some things that are too important to leave to lazy consensus. For those things, we should explicitly say okay, if you're trying to do X then you need a formal vote with majority approval. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus.. You're wrong. What annoyed me is the use of lazy consensus as the default, and passing decisions based on silence of others. Some decisions need thinking. more than 72 hours. Especially when they come from nowhere. So no, I don't think anybody has abused anything. Unless you mean to suggest that somebody is being tricky and is trying to slip something past. That would be a very serious allegation, so you should make that explicit if you believe it to be the case. Again, if you have some exceptions in mind (releases, new committers, new PMC members, new chairs are all good examples) please bring them to the list, and we can start our first draft of the by-laws. This isn't the topic of this thread and I made the intent perfectly clear imo. This topic is about revisit the way lazy consensus are used in the couchdb project. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 9 May 2013 07:10, Benoit Chesneau bchesn...@gmail.com wrote: Lazy consensus aren't here to obtain a real consensus. You are incorrect. Lazy consensus _is_ consensus, and is an important part of our decision making process at Apache. To quote a very good page on how we use lazy consensus at Apache: Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don't have to insist people discuss and/or approve your plan, and you certainly don't need to call a vote to get approval. You just assume you have the communities support unless someone says otherwise. The key thing about lazy consensus is that it's easier for people to agree, by doing nothing, than it is to object, which requires an alternative to be proposed. This has two effects, firstly people are less likely to object for the sake of it and secondly it cuts down on the amount of unnecessary mail traffic and discussion. Lazy consensus means we can avoid waiting for a community based decision before proceeding. However, it does require everyone who cares for the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, but objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares. - http://rave.apache.org/docs/governance/lazyConsensus.html And to quote from the Apache community development site: Lazy consensus is the first, and possibly the most important, consensus building tool we have. Essentially lazy consensus means that you don't need to get explicit approval to proceed, but you need to be prepared to listen if someone objects. - http://community.apache.org/committers/decisionMaking.html Your assertion that lazy consensus is somehow not valid consensus is invalid. Lazy consensus is a very important method we use for building real consensus. That along with the three-valued-vote are our primary tools for consensus building. There are, approximately, two ways to build consensus and make a decision on this project: 1) You assume that nobody is going to object, announce your intentions, and wait 72 hours. If nobody objects, you can assume lazy consensus, and you can proceed. 2) Where it is likely that people might object, or where it is likely that there needs to be some discussion of the matter, you start a discussion thread. If it appears like there is a majority consensus on the issue, you call a vote. The vote formalises the consensus. And if it passes, you can proceed. Both of these approaches are valid, and useful ways of building consensus and making decisions. And they are both suited to different purposes. I won't repeat myself. I will just re-quote the apache documentation: Reasons for Votes People tend to avoid conflict and thrash around looking for something to substitute - somebody in charge, a rule, a process, stagnation. None of these tend to be very good substitutes for doing the hard work of resolving the conflict. You have quoted that out of context. What that section actually means is that when people disagree on something, there is a certain point after which an thread becomes repetitive and unproductive. And at that point, it is often easier to just tie the discussion off with a vote, and move on with the rest of your life. Ironically, this thread is approaching that situation. From reading the responses on this thread, I believe you are the only person who has a problem with the concept of lazy consensus and how we use it. However, I believe that people would be interested in starting work on a set of by-laws that codify our expectations. So, an example of what not to do next: stop thrashing about and take some definitive action. Make a concrete proposal and try to get consensus around it. (With another discussion thread, or a formal vote, or whatever you think is best.) If you look at the subject of this thread, that should indicate why you are not likely to make much progress here. You've asked us to stop abusing lazy consensus. But this is more of a complaint than it is a proposal. And you can't really build consensus around a complaint. Nor can you identity any action that needs to be taken. A better approach would be to come up with a concrete proposal, and then bring that to the list. i.e. What I am asking you to produce is a draft of our by-laws. That would be something useful, and positive, that we could all discuss and vote on. Looking for consensus is harder than simply asking to a a vote where you can't really object and that is not really waiting an answer. This is the second time in this thread you have said this. I won't repeat this again, but you are mistaken. The whole premise of lazy consensus is that it is an *invitation* for you to object. So please, stop saying this. It isn't true. 72 hours to
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 9 May 2013 03:59, Randall Leeds randall.le...@gmail.com wrote: However, to restate my position, DISCUSS had a suggestion to me that something warranted discussion. Your recent threads on workflow all were great. We should circle back and conclude them. When something warrants good discussion, it's worthwhile to get as much input as we can, and thus it suggests a longer window would be appropriate to me. Totally agreed! I think if anybody had attempted to use lazy consensus on that thread, they would have been met with a swift objection. So, in many cases, it's a judgement call. But I think you can be sure that mistakes will be corrected for. Also, it's important for us all to remember that everything is reversible If something doesn't work, or some change gets committed that breaks CouchDB, we just revert it, or change things back to how they were. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus. Sounds like we need a well-understood set of these. If we can just enumerate them all I'd be happy to clean it up and make a definitions file. Noah, is this included in your idea of bylaws, or is this a separate document? Hmm. I guess it would be good to standardise them. Not sure you'd want to make them a requirement. But perhaps just include them as suggestions. LIke a set of best practices. Totally open to possibilities here! -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
If by go back to a more natural process you mean go back to the broken permission culture we had for the last three years where people were so intimidated by the project leads that they gave up bothering to contribute then no. A thousand times no. Not a thousand, but a million times. Many things have been delayed, or abandoned, due to inaction from developers, and I definitely include myself in that. If I take a week or two's vacation, I *expect* things to have changed in CouchDB without me, that's healthy. I trust that enough people are involved in any change that nothing too egregious can happen. I do not want to return to the stagnation of the too-recent past. I'm jazzed that someone said Sisyphean and amused that the same person made a principal/principle error. Language is fun. B. On 9 May 2013 17:00, Noah Slater nsla...@apache.org wrote: On 9 May 2013 03:59, Randall Leeds randall.le...@gmail.com wrote: However, to restate my position, DISCUSS had a suggestion to me that something warranted discussion. Your recent threads on workflow all were great. We should circle back and conclude them. When something warrants good discussion, it's worthwhile to get as much input as we can, and thus it suggests a longer window would be appropriate to me. Totally agreed! I think if anybody had attempted to use lazy consensus on that thread, they would have been met with a swift objection. So, in many cases, it's a judgement call. But I think you can be sure that mistakes will be corrected for. Also, it's important for us all to remember that everything is reversible If something doesn't work, or some change gets committed that breaks CouchDB, we just revert it, or change things back to how they were. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus. Sounds like we need a well-understood set of these. If we can just enumerate them all I'd be happy to clean it up and make a definitions file. Noah, is this included in your idea of bylaws, or is this a separate document? Hmm. I guess it would be good to standardise them. Not sure you'd want to make them a requirement. But perhaps just include them as suggestions. LIke a set of best practices. Totally open to possibilities here! -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I'm dyslexic. My spelling is a stochastic process. ;) On 9 May 2013 17:07, Robert Newson rnew...@apache.org wrote: If by go back to a more natural process you mean go back to the broken permission culture we had for the last three years where people were so intimidated by the project leads that they gave up bothering to contribute then no. A thousand times no. Not a thousand, but a million times. Many things have been delayed, or abandoned, due to inaction from developers, and I definitely include myself in that. If I take a week or two's vacation, I *expect* things to have changed in CouchDB without me, that's healthy. I trust that enough people are involved in any change that nothing too egregious can happen. I do not want to return to the stagnation of the too-recent past. I'm jazzed that someone said Sisyphean and amused that the same person made a principal/principle error. Language is fun. B. On 9 May 2013 17:00, Noah Slater nsla...@apache.org wrote: On 9 May 2013 03:59, Randall Leeds randall.le...@gmail.com wrote: However, to restate my position, DISCUSS had a suggestion to me that something warranted discussion. Your recent threads on workflow all were great. We should circle back and conclude them. When something warrants good discussion, it's worthwhile to get as much input as we can, and thus it suggests a longer window would be appropriate to me. Totally agreed! I think if anybody had attempted to use lazy consensus on that thread, they would have been met with a swift objection. So, in many cases, it's a judgement call. But I think you can be sure that mistakes will be corrected for. Also, it's important for us all to remember that everything is reversible If something doesn't work, or some change gets committed that breaks CouchDB, we just revert it, or change things back to how they were. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus. Sounds like we need a well-understood set of these. If we can just enumerate them all I'd be happy to clean it up and make a definitions file. Noah, is this included in your idea of bylaws, or is this a separate document? Hmm. I guess it would be good to standardise them. Not sure you'd want to make them a requirement. But perhaps just include them as suggestions. LIke a set of best practices. Totally open to possibilities here! -- NS -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I was tempted to answer point by point to this mail but I gave up. To summarise: you're strongly and offensively disagreeing with me. And I strongly disagree with a lot of them. Now still. You're saying that I consider lazy consensus invalid. I am not. Nowhere in my mail I considered them as invalid. But I disagree with the way they are used currently in the *couchdb* project. Especially this convenient 72 hrs. You're saying I didn't make any concrete proposal. I did before this thread derived. I did it in the introduction. *I proposed to adapt the time of lazy concensus and use them the less possible*. How is that not concrete? Now I can perfectly accept that people are against this idea, I am not trying to force anyone or to pass an idea in the silence of others. There is no irony in that since this is exactly what I was looking for. I was proposing/launching a discussion on that topic, that is deeply attached to the principles I have. I can accept the decision from others even if it's not in the sense I wanted. This is the purpose of a decision, people don't have to agree with you each time. Anyway I am chocked that someone can associated the idea of giving the choice with the idea of permission culture. This is totally unrelated to say less. Giving the choice is about beeing open to others and let them try to improve an idea/discussion/code. I didn't ask to transform discussions in battlefield. No, I asked to give more time to a discussion before taking any decision that need a discussion (if not there is no point to request a lazy concensus if it's just as a way to make sure you're not alone to take a decision, just do it). To finish, in my opinion this isn't the absense of such decision that was the problem during these last 2 years, but more or less the lack of good discussions and concrete plans. Also it didn't stop some to still work on the project even in // (you should ask yourself why it was done in // rather). I thik the issue is more complex than that. Now that we have some plans the project is more or less active. But this is out of topic. - benoit On Thu, May 9, 2013 at 5:48 PM, Noah Slater nsla...@apache.org wrote: On 9 May 2013 07:10, Benoit Chesneau bchesn...@gmail.com wrote: Lazy consensus aren't here to obtain a real consensus. You are incorrect. Lazy consensus _is_ consensus, and is an important part of our decision making process at Apache. To quote a very good page on how we use lazy consensus at Apache: Lazy Consensus means that when you are convinced that you know what the community would like to see happen you can simply assume that you already have consensus and get on with the work. You don't have to insist people discuss and/or approve your plan, and you certainly don't need to call a vote to get approval. You just assume you have the communities support unless someone says otherwise. The key thing about lazy consensus is that it's easier for people to agree, by doing nothing, than it is to object, which requires an alternative to be proposed. This has two effects, firstly people are less likely to object for the sake of it and secondly it cuts down on the amount of unnecessary mail traffic and discussion. Lazy consensus means we can avoid waiting for a community based decision before proceeding. However, it does require everyone who cares for the health of the project to watch what is happening, as it is happening. Objecting too far down the road will cause upset, but objecting (or asking for clarification of intent) early is likely to be greeted with relief that someone is watching and cares. - http://rave.apache.org/docs/governance/lazyConsensus.html And to quote from the Apache community development site: Lazy consensus is the first, and possibly the most important, consensus building tool we have. Essentially lazy consensus means that you don't need to get explicit approval to proceed, but you need to be prepared to listen if someone objects. - http://community.apache.org/committers/decisionMaking.html Your assertion that lazy consensus is somehow not valid consensus is invalid. Lazy consensus is a very important method we use for building real consensus. That along with the three-valued-vote are our primary tools for consensus building. There are, approximately, two ways to build consensus and make a decision on this project: 1) You assume that nobody is going to object, announce your intentions, and wait 72 hours. If nobody objects, you can assume lazy consensus, and you can proceed. 2) Where it is likely that people might object, or where it is likely that there needs to be some discussion of the matter, you start a discussion thread. If it appears like there is a majority consensus on the issue, you call a vote. The vote formalises the consensus. And if it passes, you can proceed. Both of these approaches are valid, and useful ways of building consensus and making decisions. And they are both
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
+1 I think lazy consensus is valuable, but I think it's antithetical to [DISCUSS]. If something should be discussed, it should be open for some time. I think the sensible way to do things would be to have discussion open for a week or two and then a lazy consensus email summarizing the discussion and what consensus the OP believes we have. That could be just 72 hours, but at that point the discussion has already happened and the 72 hours is a formality to ensure that people have a chance to quickly disagree about what the discussion yielded. On Tue, May 7, 2013 at 12:07 PM, Benoit Chesneau bchesn...@gmail.com wrote: I would like to discuss about the lazy concensus here. Side notte: I already read http://www.apache.org/foundation/voting.html thanks. So these votes happend quite often this last 4 months either in @private or @dev ml, and I'm quietly becoming very annoyed by them. Especially when they expect a response in less than a week ( I would say month). Lazy consensus give this false idea that because no-one objected in time then it's OK to process. That could be true if the expected response was not in a short delay or asked before a we, or... Actually it can be asked before a we, or at any time, but we have to understand that sometime our time isn't the time of other: in some countries that can be the holidays, bank days or some of us can be busy for any reason, some of us also disconnect at certain times. Other have a lot of email to handle per day with mostly the same priority. So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. At least if noone still answer then the person that answered could take its own responsibility and consider it as a yes . I reckon that some lazy concensus need an urgent response (though i doubt a lazy concensus is enough in that case) so I propose If nonone object I would like to push the delay of such discussion to 2 weeks by default . Also i really would like that such concensus should be optionnal not a common thing to use to pass ideas. This isn't natural at all. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 7 May 2013 20:07, Benoit Chesneau bchesn...@gmail.com wrote: Lazy consensus give this false idea that because no-one objected in time then it's OK to process. This is not a false idea. This principal sites at the very core of how we do things at Apache. That could be true if the expected response was not in a short delay or asked before a we 72 hours to gauge lazy consensus is a standard across all 130 Apache TLPs. It strikes the balance between being able to move quickly, and being considerate of other people's time. So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. I think this is much too long a time to expect people to wait before they can assume lazy consensus We need to become *lighter* in our decision making process, not heavier. Having said that, you are free to try and build consensus around your idea. Please note that unless consensus can be established to change the notice period, the status quo will be maintained, which is 72 hours. If nonone object I would like to push the delay of such discussion to 2 weeks by default . I am -1 on this. I do not want to slow down the decision making process. We cannot stall our already embarrassingly slow velocity because some people in the community only check their Apache email once a fortnight. If you want to be involved more, check your email more. If you can't check your email more, then recognise that some decisions are going to be made in your absence. Also i really would like that such concensus should be optionnal not a common thing to use to pass ideas. This isn't natural at all. Lazy consensus is the *default* decision making process at Apache. We do it like this precisely because it is hard to co-ordinate a team when people are unreliable, busy, and distributed across the globe. As for the abuse of DISCUSS threads, I can only assume that is targeted at me, as I have been doing most of the project co-ordination the last few months. If you could provide specifics, that would be useful. I would be happy to use the subject tag PROPOSAL when lazy consensus is being used, to separate these threads out from general DISCUSS threads. Please note, however, that in my mental model of how Apache works, a DISCUSS thread *is* a discussion that will default to lazy consensus. That is how I have always used that tag. If you think it's confusing, let's propose a new tag. On 8 May 2013 05:19, Benoit Chesneau bchesn...@gmail.com wrote: Not really. People are not expected to be on their computer all the time. Some are disconnecting when they go in vacations for real. Some can't connect at all to a public network because of their customer or else for some time. The fact is that you can't expect that people distributed in the world and work synchronously with you most of the time. Perhaps you're operating under the assumption that our decision making process requires everyone to look at the proposal and give their opinion. It does not. I am not even sure how you would define everyone. All PMC members? All committers? Anyone subscribed to dev@? If somebody is traveling for three months, does the project freeze up? Part of how we operate here is that if you want to be involved in the decision making process you need to be engaged with the mailing list. That is a requirement. The project will not stop functioning because someone is too busy to check your email for two weeks. And it's important that we operate like this so that individual circumstances do not slow the project down. Dropping a mail on the mailing-;list on big topics an expecting an answer in 72h is not really fear. Until you expect that people works in sync on that topic. Can you clarify this point? Better yet, provide a specific example. It is hard to reason about this stuff in the abstract. If you're referring to Bob's recent post about BigCouch, I'd say the community has had a fair run up to this thread. (About 18 months...) And -1 can be properly ignored in lazy concenssus. No, a -1 *cannot* be ignored. That's the whole point. If somebody objects, lazy consensus fails, and it should go to a discussion, and then a vote (if necessary). Lazy consensus are not about looking for a consensus at all. Yes, it is about looking for consensus. Again, this is really foundational stuff to how we operate at Apache. Lazy consensus is called lazy because it assumes that if you don't speak up, you are giving consent. This is one form of consensus building that we use. A way to confirm an idea without any real discussion. Yes. Discussion is not a _necessary_ component of decision making. I do think that lazy consensus shouldn't be use for important topics that engage all the community. We need a set of project by-laws that encode what sort of decision making process can be used for what sort of change. This is on my todo list. But if someone wants to run with
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On 9 May 2013 01:02, Noah Slater nsla...@apache.org wrote: I would be happy to use the subject tag PROPOSAL when lazy consensus is being used, to separate these threads out from general DISCUSS threads. Please note, however, that in my mental model of how Apache works, a DISCUSS thread *is* a discussion that will default to lazy consensus. That is how I have always used that tag. If you think it's confusing, let's propose a new tag. I will note, actually, that the tag I put in the email thread is besides the point. That's just a matter of courtesy. The default model that we operate under is that if I announce my intentions to the dev@ list, then you have 72 hours to object. This works for two reasons: 1) People are elected to committer, primarily, because we *trust* them. That means we trust them to act in the best interests of the project. 2) If you care about this stuff, you need to be monitoring dev@ and you need to be voicing your objections. If you are not doing this, you cannot expect the project to slow down to suit your pace. There are some things that are too important to leave to lazy consensus. For those things, we should explicitly say okay, if you're trying to do X then you need a formal vote with majority approval. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus. So no, I don't think anybody has abused anything. Unless you mean to suggest that somebody is being tricky and is trying to slip something past. That would be a very serious allegation, so you should make that explicit if you believe it to be the case. Again, if you have some exceptions in mind (releases, new committers, new PMC members, new chairs are all good examples) please bring them to the list, and we can start our first draft of the by-laws. -- NS
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Wed, May 8, 2013 at 7:02 PM, Noah Slater nsla...@apache.org wrote: On 9 May 2013 01:02, Noah Slater nsla...@apache.org wrote: I would be happy to use the subject tag PROPOSAL when lazy consensus is being used, to separate these threads out from general DISCUSS threads. Please note, however, that in my mental model of how Apache works, a DISCUSS thread *is* a discussion that will default to lazy consensus. That is how I have always used that tag. If you think it's confusing, let's propose a new tag. I will note, actually, that the tag I put in the email thread is besides the point. That's just a matter of courtesy. The default model that we operate under is that if I announce my intentions to the dev@ list, then you have 72 hours to object. This works for two reasons: 1) People are elected to committer, primarily, because we *trust* them. That means we trust them to act in the best interests of the project. 2) If you care about this stuff, you need to be monitoring dev@ and you need to be voicing your objections. If you are not doing this, you cannot expect the project to slow down to suit your pace. I'm following and agree. I want things to move quickly and implicitly trust the judgment of our committers. I think PROPOSAL might be a good tag to use when you want to give the courtesy of a formal opportunity to veto. However, to restate my position, DISCUSS had a suggestion to me that something warranted discussion. Your recent threads on workflow all were great. We should circle back and conclude them. When something warrants good discussion, it's worthwhile to get as much input as we can, and thus it suggests a longer window would be appropriate to me. There are some things that are too important to leave to lazy consensus. For those things, we should explicitly say okay, if you're trying to do X then you need a formal vote with majority approval. It sounds to me like you've been caught off-guard because a few decisions have been made and you didn't have time to contribute. I would suggest two things. 1) Set up email filters so that DISCUSS, VOTE, NOTICE threads get priority in your inbox. 2) Come up with a list of things you think we should not leave to lazy consensus. Sounds like we need a well-understood set of these. If we can just enumerate them all I'd be happy to clean it up and make a definitions file. Noah, is this included in your idea of bylaws, or is this a separate document?
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I'm not sure I fully agree. All the lazy consensus's of late have had a 72 hour window on them which is the same duration we use for couchdb releases. However, we can discuss what the minimum lazy consensus period can be based on what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. B. On 7 May 2013 20:07, Benoit Chesneau bchesn...@gmail.com wrote: I would like to discuss about the lazy concensus here. Side notte: I already read http://www.apache.org/foundation/voting.html thanks. So these votes happend quite often this last 4 months either in @private or @dev ml, and I'm quietly becoming very annoyed by them. Especially when they expect a response in less than a week ( I would say month). Lazy consensus give this false idea that because no-one objected in time then it's OK to process. That could be true if the expected response was not in a short delay or asked before a we, or... Actually it can be asked before a we, or at any time, but we have to understand that sometime our time isn't the time of other: in some countries that can be the holidays, bank days or some of us can be busy for any reason, some of us also disconnect at certain times. Other have a lot of email to handle per day with mostly the same priority. So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. At least if noone still answer then the person that answered could take its own responsibility and consider it as a yes . I reckon that some lazy concensus need an urgent response (though i doubt a lazy concensus is enough in that case) so I propose If nonone object I would like to push the delay of such discussion to 2 weeks by default . Also i really would like that such concensus should be optionnal not a common thing to use to pass ideas. This isn't natural at all. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
I'd prefer to keep a 72 hour window for lazy consensus. Adam On May 7, 2013, at 3:23 PM, Robert Newson rnew...@apache.org wrote: I'm not sure I fully agree. All the lazy consensus's of late have had a 72 hour window on them which is the same duration we use for couchdb releases. However, we can discuss what the minimum lazy consensus period can be based on what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. B. On 7 May 2013 20:07, Benoit Chesneau bchesn...@gmail.com wrote: I would like to discuss about the lazy concensus here. Side notte: I already read http://www.apache.org/foundation/voting.html thanks. So these votes happend quite often this last 4 months either in @private or @dev ml, and I'm quietly becoming very annoyed by them. Especially when they expect a response in less than a week ( I would say month). Lazy consensus give this false idea that because no-one objected in time then it's OK to process. That could be true if the expected response was not in a short delay or asked before a we, or... Actually it can be asked before a we, or at any time, but we have to understand that sometime our time isn't the time of other: in some countries that can be the holidays, bank days or some of us can be busy for any reason, some of us also disconnect at certain times. Other have a lot of email to handle per day with mostly the same priority. So I think that something tagged [DISCUSS] should at least let 2 weeks or better 1 month to expect a response and make any assumption. At least if noone still answer then the person that answered could take its own responsibility and consider it as a yes . I reckon that some lazy concensus need an urgent response (though i doubt a lazy concensus is enough in that case) so I propose If nonone object I would like to push the delay of such discussion to 2 weeks by default . Also i really would like that such concensus should be optionnal not a common thing to use to pass ideas. This isn't natural at all. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Tue, May 7, 2013 at 9:23 PM, Robert Newson rnew...@apache.org wrote: I'm not sure I fully agree. All the lazy consensus's of late have had a 72 hour window on them which is the same duration we use for couchdb releases. However, we can discuss what the minimum lazy consensus period can be based on what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. +1 to all of that. Cheers, Dirkjan
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Tue, May 7, 2013 at 9:23 PM, Robert Newson rnew...@apache.org wrote: I'm not sure I fully agree. All the lazy consensus's of late have had a 72 hour window on them which is the same duration we use for couchdb releases. This si another topic. Also votes on release need a majority of approval, and are done on something that *should* have been tested before the vote. But this is another topic. However, we can discuss what the minimum lazy consensus period can be based on what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? Not really. People are not expected to be on their computer all the time. Some are disconnecting when they go in vacations for real. Some can't connect at all to a public network because of their customer or else for some time. The fact is that you can't expect that people distributed in the world and work synchronously with you most of the time. Dropping a mail on the mailing-;list on big topics an expecting an answer in 72h is not really fear. Until you expect that people works in sync on that topic. The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Lazy consensus is simply an announcement of 'silence gives assent.' When someone wants to determine the sense of the community this way, http://www.apache.org/foundation/voting.htm This is what I mean. And -1 can be properly ignored in lazy concenssus. Lazy consensus are not about looking for a consensus at all. A way to confirm an idea without any real discussion. A way to make sure you're not the only one to think that way. I do think that lazy consensus shouldn't be use for important topics that engage all the community. And I do think that asking for a short time in recent topics was used as a convenience. They didn't require so much urgency. They could have been handled in the week. Lot of projects outside couchdb do this way. Even in companies. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. Some were borderline imo. To take an example I don't think that the merge of bigcouch should be done on lazy consensus, it should be a full vote. Because ii is more than a technical changes. It can also be considered as a switch in the philosophy of the project so giving more time to people to think about it would be interesting. Giving the possibility to veto it or to express their opinion too. It may not change the result at all and probably won't , but that not a reason. - benoit
Re: [DISCUSS] dont't abuse of lazy concensus on mail tagged [DISCUSS]
On Wed, May 8, 2013 at 6:19 AM, Benoit Chesneau bchesn...@gmail.com wrote: On Tue, May 7, 2013 at 9:23 PM, Robert Newson rnew...@apache.org wrote: I'm not sure I fully agree. All the lazy consensus's of late have had a 72 hour window on them which is the same duration we use for couchdb releases. This si another topic. Also votes on release need a majority of approval, and are done on something that *should* have been tested before the vote. But this is another topic. However, we can discuss what the minimum lazy consensus period can be based on what the minimum time that community members feel they can respond. I don't mean this as horribly as it will sound, but, to a degree, if someone can't take the time, in 3 days, to reply with '-1' to a thread, perhaps that's a problem too? Not really. People are not expected to be on their computer all the time. Some are disconnecting when they go in vacations for real. Some can't connect at all to a public network because of their customer or else for some time. The fact is that you can't expect that people distributed in the world and work synchronously with you most of the time. Dropping a mail on the mailing-;list on big topics an expecting an answer in 72h is not really fear. Until you expect that people works in sync on that topic. The whole point of lazy consensus is to move forward quickly. We don't always need to wait for a large number of +1's to get work done. Lazy consensus is simply an announcement of 'silence gives assent.' When someone wants to determine the sense of the community this way, http://www.apache.org/foundation/voting.htm This is what I mean. And -1 can be properly ignored in lazy concenssus. Lazy consensus are not about looking for a consensus at all. A way to confirm an idea without any real discussion. A way to make sure you're not the only one to think that way. I do think that lazy consensus shouldn't be use for important topics that engage all the community. And I do think that asking for a short time in recent topics was used as a convenience. They didn't require so much urgency. They could have been handled in the week. Lot of projects outside couchdb do this way. Even in companies. Finally, I'll agree that lazy consensus can be used inappropriately, I just don't think I agree that it's happened yet. Some were borderline imo. To take an example I don't think that the merge of bigcouch should be done on lazy consensus, it should be a full vote. Because ii is more than a technical changes. It can also be considered as a switch in the philosophy of the project so giving more time to people to think about it would be interesting. Giving the possibility to veto it or to express their opinion too. It may not change the result at all and probably won't , but that not a reason. - benoit As a final note I would like to quote the apache page above again: Reasons for Votes People tend to avoid conflict and thrash around looking for something to substitute somebody in charge, a rule, a process, stagnation. None of these tend to be very good substitutes for doing the hard work of resolving the conflict. - benoit
