On Thu, Sep 19, 2013 at 9:08 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > On Sep 18, 2013 3:10 PM, "Alexandro Colorado" <j...@oooes.org> wrote: > > > > On 9/18/13, Kay Schenk <kay.sch...@gmail.com> wrote: > > > On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <j...@oooes.org> > wrote: > > > > > >> 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. > > >> > > > > > > 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? > > A notification about a bug with a patch is an "info item", possibly > needing action, in my mind. In this case, since an e-mail was sent telling > us of a patch, a committer could apply it after checking it out and making > a determination that it was the right thing to do -- in this case, a > spelling correction which, of course, is needed -- and not harmful. > > This "next step" is normal in our process of dealing with bug reports. > > > > > > > > > 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. > Changes are now in staging: http://openoffice.staging.apache.org/orientation/decision-making.html > > > > > > > > > > >> > > >> > > > >> > -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 > > >> > > >> > > > > > > > > > -- > > > > ------------------------------------------------------------------------------------------------- > > > 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 > > > -- ------------------------------------------------------------------------------------------------- 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
