On 9/18/13, Kay Schenk <[email protected]> wrote: > On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <[email protected]> wrote: > >> On 9/10/13, Rob Weir <[email protected]> wrote: >> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <[email protected]> >> wrote: >> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <[email protected]> >> wrote: >> >> >> >>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <[email protected]> >> >>> wrote: >> >>> >> >>> > I have recently been impact, on this lack of decision making tasks >> not >> >>> > being followed (ignoring 72 hr limit, etc) basically breaking the >> >>> process. >> >>> > So I have a few comments on this. >> >>> > >> >>> >> >>> I think you're referring to using "lazy concensus" . >> >>> >> >>> https://openoffice.apache.org/docs/governance/lazyConsensus.html >> >>> https://community.apache.org/committers/lazyConsensus.html >> >>> >> >>> One of the important aspects of Lazy Consensus is that it should be >> >>> stated >> >>> at the outset of a communication that this is what will be in effect >> for >> >>> whatever is proposed. In other words, proposing something and stating >> >>> that >> >>> you will be using Lazy Consensus to implement whatever it is you >> >>> might >> >>> want >> >>> to do is critical to this particular process. >> >>> >> >>> So far, I am finding 2 threads that seem to relate to all this: >> >>> >> >>> [1] http://markmail.org/message/hsdepqzlfvh33pdr >> >>> (proposals for wiki, forum , web site extensions, etc) >> >>> >> >>> and yes,I did vote +1 on the one design I saw in the issue and using >> it, >> >>> but mine was only ONE vote in a series of other comments. >> >>> >> >>> and this one, more recent >> >>> >> >>> [2] http://markmail.org/message/wlvv7gsnsmcurwfv >> >>> >> >>> in which there is claim that something was proposed. Based on the >> first >> >>> thread, all I see are suggestions for designs and discussion, but no >> >>> specific proposal. >> >>> >> >>> So, no proposal, no broken "lazy consensus" process. >> >>> >> >>> >> >>> > One important part is focusing on the meritocracy aspect of FLOSS. >> >>> > Is >> >>> > important not only to have a bug but an 'evidence'. Everyone has >> >>> > the >> >>> right >> >>> > to a voice and have their opinion on implementations. However I >> >>> > think >> >>> that >> >>> > the impact of that voice should be accompany with actual evidence, >> and >> >>> > would go into even having to propose an alternative. Deny things >> >>> > for >> >>> > the >> >>> > sole case of opinion shouldn't be enforced, >> >>> >> >>> >> >>> We have a process here at the ASF. Denying something, and I take this >> to >> >>> mean denying implementing something, based on opinion is what >> discussion >> >>> and building consensus is all about. >> >>> >> >> >> >> Exactly why we should consider a more efficient way of discussing it. >> >> (I >> >> thought you are proposing changes to the DM process) for the reasons >> >> explained. >> >> >> >> >> >>> >> >>> >> >>> > otherwise this will leave us >> >>> > to have many unverifiable opinions at a very low cost (think of >> >>> > spam >> >>> > for >> >>> > bitmessage) slowing the project down. >> >>> > >> >>> > There should also be a 'good enough' flag deadline after a certain >> >>> > period >> >>> > of time to get out of locked-in discussions. This is usually used >> >>> > on >> >>> power >> >>> > negotiations (HBR article on the topic: >> >>> > http://hbswk.hbs.edu/archive/4354.html). >> >>> > >> >>> >> >>> We have Lazy Consensus and other "decision making" processes.The >> >>> ideas >> >>> in >> >>> the article you have above are not the way we make decisions at >> >>> Apache >> >>> OpenOffice. >> >>> Lazy Consensus comes close, but, again, this must be explicitly >> >>> stated >> >>> -- >> >>> >> >> This sounds a bit of a technicality 'you didnt use blue ink to fill >> >> out >> >> your form' kind of situation. >> >> >> >> >> >> >> >>> or else other participants don't have any idea if you're just >> discussing >> >>> something or actually intend to do something. >> >>> >> >> >> >> Not sure I understand you here. Why would anyone discuss anything for >> >> just >> >> the fun of discussing it? >> >> >> > >> > Something we do see: Someone talk about an idea, but it is not >> > something that they are wiling/able to do. They just think it is a >> > good idea. But unless someone volunteers it is just talk. >> > >> > I'm not saying yours was an example like this, but it is good to be >> > explicit. >> > >> > A semi-humorous example of one approach is here: >> > >> > http://markmail.org/message/rn2uentbgqipx2a5 >> > >> > The exact format is not critical, but that is one way a committer can >> > make it crystal clear. >> >> I understand conventions, I would like to see more conventions myself, >> I dont understand however when proposal is not a proposal because it >> didnt say [PROPOSAL]. We have a similar conversation on using dev@ for >> support etc. >> > > In my opinion, to a great extent, it depends on the message content. We > don't' always adhere to the [PROPOSAL]/[LAZY PROPOSAL] tag, though that > would certainly make things more clear. > > When I see a statement posted on this list like: > > "Page X has a false statement on it, and unless anyone objects over the > next day or so, I will fix it." > > regardless of what the subject matter is, I have a pretty good idea that > this is a lazy consensus statement, and the sender will likely wait a few > days and make the fix. > > When I see a statement like: > > "It seems like page x has a false statement on it." > > and nothing else, I don't interpret that as a lazy consensus proposal, but > rather an info item only.
I wonder how you define 'info item' and what you expect to do with it. If for example there is a typo and a page says AApache OpenOffice on the title, and an email comes saying: "It seems like page x has a typo on the title saying AApache OpenOffice, I create the bug #2111 with the patch" What exactly should be the next step, if any? > > I think Rob's suggestions in this thread to augment what is already on the > Decision Making page would give folks a better understanding of when to > use a [PROPOSAL] or [LAZY CONSENSUS]. > > I am not trying to change the process, but to add clarity to it. > > [LAZY CONSENSUS] proposal: > Unless there are objections to Rob's suggestions, I will add them to the > Decision Making page sometime over the upcoming weekend. > > > >> >> > >> > -Rob >> > >> > >> >> >> >> >> >>> >> >>> >> >>> >> >>> > >> >>> > On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <[email protected]> >> >>> > wrote: >> >>> > >> >>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <[email protected]> >> wrote: >> >>> > > >> >>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk >> >>> > > > <[email protected] >> > >> >>> > wrote: >> >>> > > > > The information we currently have on Decision Making can be >> >>> > > > > found >> >>> in >> >>> > > our >> >>> > > > > Orientation section: >> >>> > > > > >> >>> > > > > http://openoffice.apache.org/orientation/decision-making.html >> >>> > > > > >> >>> > > > > On that page, there are explanations for types of decision >> >>> > > > > making >> >>> > used >> >>> > > in >> >>> > > > > this project specifically and within the Apache Software >> >>> Foundation. >> >>> > In >> >>> > > > my >> >>> > > > > opinion, this is very good "how to" guide, but somewhat >> >>> > > > > limited >> >>> > > > > as >> >>> a >> >>> > > > "when >> >>> > > > > to" guide. >> >>> > > > > >> >>> > > > >> >>> > > > I drafted the orientation pages based on my understanding. I >> >>> > > > didn't >> >>> > > > get many comments at the time, so I'm sure there is room for >> >>> > > > improvement. >> >>> > > > >> >>> > > > > Most of the source code changes done currently are preceded >> >>> > > > > by >> a >> >>> > > > > BZ >> >>> > > > issue. >> >>> > > > > This is wonderfully simple and anyone on the commits list can >> >>> follow >> >>> > > what >> >>> > > > > and why something has been done. In other cases, for much >> >>> > > > > larger >> >>> > > > changes, >> >>> > > > > discussions have been initiated. So, we would NOT see an >> >>> > > > > action >> >>> such >> >>> > as >> >>> > > > > deleting an entire module undertaken without discussion. >> >>> > > > > Decision >> >>> > > making >> >>> > > > > for these types of change follow a a well-known and followed >> >>> process. >> >>> > > > > >> >>> > > > > Aside from code changes, there are changes to other areas of >> the >> >>> > > project >> >>> > > > -- >> >>> > > > > web sites, wiki, forums -- whose changes are not typically >> noted >> >>> > > > > in >> >>> > BZ. >> >>> > > > > Sometimes there are proposals and discussions, sometimes not. >> >>> These >> >>> > > are >> >>> > > > > the kinds of changes that may need additional clarification >> with >> >>> > regard >> >>> > > > to >> >>> > > > > decision making. >> >>> > > > > >> >>> > > > > In summary, what kinds of change for non-source code need a >> >>> > > > > [PROPOSAL]/discussion before change? >> >>> > > > > >> >>> > > > >> >>> > > > For source changes and non-source changes the idea is >> >>> > > > essentially >> >>> > > > the >> >>> > > > same. It is a judgement call more than a hard rule. That's >> >>> > > > why >> >>> > > > we >> >>> > > > should try to vote in committers who have demonstrated good >> >>> > > > judgement >> >>> > > > as well as technical skills. >> >>> > > > >> >>> > > > We operate in Commit-Then-Review mode most of the time, except >> >>> > > > when >> >>> > > > close to a Release Candidate. We try to avoid unnecessary >> >>> discussion. >> >>> > > > A timid committer who needs to review every minor change with >> >>> > > > is >> >>> > > > an >> >>> > > > annoyance to most of the 453 subscribers of the dev list. So >> >>> > > > we >> >>> > > > want >> >>> > > > to encourage JFDI where appropriate. But it is still a >> >>> > > > judgement >> >>> > > > call. >> >>> > > > >> >>> > > > But in general, I think (my personal view) a committer should >> >>> > > > put >> >>> > > > out >> >>> > > > a proposal in situations such as: >> >>> > > > >> >>> > > > 1) They are unsure of the technical merits of what they want to >> >>> > > > do. >> >>> > > > They want an extra pair of eyes to review the proposal point >> >>> > > > out >> >>> > > > weaknesses, alternatives, etc. >> >>> > > > >> >>> > > > 2) It is a job for more than one person or requires >> >>> > > > coordination >> >>> > > > across several subgroups within the project. By putting out a >> >>> > > > formal >> >>> > > > proposal you can find additional volunteers and move forward in >> >>> > > > a >> >>> > > > coordinated way. >> >>> > > > >> >>> > > > 3) A change to one of our websites that impacts terms and >> >>> conditions, >> >>> > > > license, copyright, branding, etc. So not a technical change, >> but >> >>> > > > a >> >>> > > > substantive change to content in these areas. These require >> >>> > > > PMC >> >>> > > > review. >> >>> > > > >> >>> > > > 4) A technical change that breaks backwards compatibility of >> >>> > > > the >> >>> > product. >> >>> > > > >> >>> > > > 5) Changes that break things. Sometimes this is unavoidable. >> But >> >>> > > > it >> >>> > > > should be proposed and coordinated like #2 above. >> >>> > > > >> >>> > > > 6) Changes that cannot easily be reversed. Code changes and >> >>> > > > most >> >>> > > > website changes are in SVN and can be reverted. But some >> changes, >> >>> > > > like administrative bulk actions in BZ, cannot be easily >> >>> > > > undone. >> >>> > > > >> >>> > > > 7) Public statements in behalf of the project, e.g., some blog >> >>> > > > posts >> >>> > > > and announcements, press releases, etc. >> >>> > > > >> >>> > > > Those are examples, but the list is by no means complete. And >> for >> >>> > > > almost any of these there may be cases where CTR or even JFDI >> >>> > > > is >> >>> > > > appropriate. I'd take them more as "things to think about" >> >>> > > > when >> >>> > > > developing good judgement. >> >>> > > > >> >>> > > > Regards, >> >>> > > > >> >>> > > > -Rob >> >>> > > > >> >>> > > >> >>> > > These are great guidelines! We should definitely integrate them >> into >> >>> the >> >>> > > Decision Making page somehow. Number 7 might need more >> elaboration. >> >>> > > >> >>> > > "Developing good judgement", like so many things in life, is >> learned >> >>> > > by >> >>> > > trial and error. It would be great if we could at least better >> >>> > > define >> >>> > what >> >>> > > we think "good judgement" is. >> >>> > > >> >>> > > >> >>> > > >> >>> > > > >> >>> > > > > >> >>> > > > > >> >>> > > > > >> >>> > > > >> >>> > > >> >>> > >> >>> >> ------------------------------------------------------------------------------------------------- >> >>> > > > > MzK >> >>> > > > > >> >>> > > > > "Truth is stranger than fiction, but it is because Fiction is >> >>> obliged >> >>> > > > > to stick to possibilities. Truth isn't." >> >>> > > > > -- "Following the Equator", Mark >> >>> > > > > Twain >> >>> > > > >> >>> > > > >> --------------------------------------------------------------------- >> >>> > > > To unsubscribe, e-mail: [email protected] >> >>> > > > For additional commands, e-mail: [email protected] >> >>> > > > >> >>> > > > >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > >> >>> > > >> >>> > >> >>> >> ------------------------------------------------------------------------------------------------- >> >>> > > MzK >> >>> > > >> >>> > > "Truth is stranger than fiction, but it is because Fiction is >> >>> > > obliged >> >>> > > to stick to possibilities. Truth isn't." >> >>> > > -- "Following the Equator", Mark >> >>> > > Twain >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Alexandro Colorado >> >>> > Apache OpenOffice Contributor >> >>> > http://www.openoffice.org >> >>> > >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> >> ------------------------------------------------------------------------------------------------- >> >>> MzK >> >>> >> >>> "Truth is stranger than fiction, but it is because Fiction is obliged >> >>> to stick to possibilities. Truth isn't." >> >>> -- "Following the Equator", Mark Twain >> >>> >> >> >> >> >> >> >> >> -- >> >> Alexandro Colorado >> >> Apache OpenOffice Contributor >> >> http://www.openoffice.org >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> > >> >> >> -- >> Alexandro Colorado >> Apache OpenOffice Contributor >> http://www.openoffice.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > ------------------------------------------------------------------------------------------------- > MzK > > "Truth is stranger than fiction, but it is because Fiction is obliged > to stick to possibilities. Truth isn't." > -- "Following the Equator", Mark Twain > -- Alexandro Colorado Apache OpenOffice Contributor http://www.openoffice.org --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
