On 9/10/13, Rob Weir <robw...@apache.org> wrote: > 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.
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. > > -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 > > -- 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
