On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <j...@oooes.org> wrote: > On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <kay.sch...@gmail.com> wrote: > >> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <j...@oooes.org> >> 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. -Rob > > >> >> >> >> > >> > On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <kay.sch...@gmail.com> wrote: >> > >> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <robw...@apache.org> wrote: >> > > >> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <kay.sch...@gmail.com> >> > 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: dev-unsubscr...@openoffice.apache.org >> > > > For additional commands, e-mail: dev-h...@openoffice.apache.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 >> > >> >> >> >> -- >> >> ------------------------------------------------------------------------------------------------- >> 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: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
