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? > > > > > > > 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
