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. > 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 -- or else other participants don't have any idea if you're just discussing something or actually intend to do something. > > 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
