You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Kay Schenk <ka...@gmail.com> on 2013/09/08 22:23:15 UTC
Does our "Decision Making" information need additional instructions?
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.
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?
-------------------------------------------------------------------------------------------------
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
Re: Does our "Decision Making" information need additional instructions?
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Sep 19, 2013 at 9:08 PM, Kay Schenk <ka...@gmail.com> wrote:
>
> On Sep 18, 2013 3:10 PM, "Alexandro Colorado" <jz...@oooes.org> wrote:
> >
> > On 9/18/13, Kay Schenk <ka...@gmail.com> wrote:
> > > On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <jz...@oooes.org>
> wrote:
> > >
> > >> On 9/10/13, Rob Weir <ro...@apache.org> wrote:
> > >> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org>
> > >> wrote:
> > >> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <
> jza@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.schenk@gmail.com>
> > >> >>> > wrote:
> > >> >>> >
> > >> >>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org>
> > >> wrote:
> > >> >>> > >
> > >> >>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk
> > >> >>> > > > <kay.schenk@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-unsubscribe@openoffice.apache.org
> > >> >>> > > > For additional commands, e-mail:
> dev-help@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-unsubscribe@openoffice.apache.org
> > >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Alexandro Colorado
> > >> Apache OpenOffice Contributor
> > >> http://www.openoffice.org
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Kay Schenk <ka...@gmail.com>.
On Sep 18, 2013 3:10 PM, "Alexandro Colorado" <jz...@oooes.org> wrote:
>
> On 9/18/13, Kay Schenk <ka...@gmail.com> wrote:
> > On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <jz...@oooes.org>
wrote:
> >
> >> On 9/10/13, Rob Weir <ro...@apache.org> wrote:
> >> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org>
> >> wrote:
> >> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com>
> >> wrote:
> >> >>
> >> >>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jza@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.
> >
> >
> >
> >>
> >> >
> >> > -Rob
> >> >
> >> >
> >> >>
> >> >>
> >> >>>
> >> >>>
> >> >>>
> >> >>> >
> >> >>> > On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <ka...@gmail.com>
> >> >>> > wrote:
> >> >>> >
> >> >>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org>
> >> wrote:
> >> >>> > >
> >> >>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk
> >> >>> > > > <kay.schenk@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-unsubscribe@openoffice.apache.org
> >> >>> > > > For additional commands, e-mail:
dev-help@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-unsubscribe@openoffice.apache.org
> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Alexandro Colorado
> >> Apache OpenOffice Contributor
> >> http://www.openoffice.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: Does our "Decision Making" information need additional instructions?
Posted by Alexandro Colorado <jz...@oooes.org>.
On 9/18/13, Kay Schenk <ka...@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <jz...@oooes.org> wrote:
>
>> On 9/10/13, Rob Weir <ro...@apache.org> wrote:
>> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org>
>> wrote:
>> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com>
>> wrote:
>> >>
>> >>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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?
>
> 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.
>
>
>
>>
>> >
>> > -Rob
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> >>>
>> >>> >
>> >>> > On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <ka...@gmail.com>
>> >>> > wrote:
>> >>> >
>> >>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org>
>> wrote:
>> >>> > >
>> >>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk
>> >>> > > > <kay.schenk@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-unsubscribe@openoffice.apache.org
>> >>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
>> > For additional commands, e-mail: dev-help@openoffice.apache.org
>> >
>> >
>>
>>
>> --
>> Alexandro Colorado
>> Apache OpenOffice Contributor
>> http://www.openoffice.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Does our "Decision Making" information need additional instructions?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <jz...@oooes.org> wrote:
> On 9/10/13, Rob Weir <ro...@apache.org> wrote:
> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org>
> wrote:
> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com>
> wrote:
> >>
> >>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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 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.
>
> >
> > -Rob
> >
> >
> >>
> >>
> >>>
> >>>
> >>>
> >>> >
> >>> > On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <ka...@gmail.com>
> >>> > wrote:
> >>> >
> >>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org>
> wrote:
> >>> > >
> >>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <kay.schenk@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-unsubscribe@openoffice.apache.org
> >>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
>
> --
> Alexandro Colorado
> Apache OpenOffice Contributor
> http://www.openoffice.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Alexandro Colorado <jz...@oooes.org>.
On 9/10/13, Rob Weir <ro...@apache.org> wrote:
> On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org> wrote:
>> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com> wrote:
>>
>>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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 <ka...@gmail.com>
>>> > wrote:
>>> >
>>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
>>> > >
>>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
>>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Alexandro Colorado
Apache OpenOffice Contributor
http://www.openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Does our "Decision Making" information need additional instructions?
Posted by Rob Weir <ro...@apache.org>.
On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jz...@oooes.org> wrote:
> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com> wrote:
>
>> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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 <ka...@gmail.com> wrote:
>> >
>> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
>> > >
>> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
>> > > > For additional commands, e-mail: dev-help@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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Does our "Decision Making" information need additional instructions?
Posted by Alexandro Colorado <jz...@oooes.org>.
On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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 <ka...@gmail.com> wrote:
> >
> > > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
> > >
> > > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
> > > > For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Kay Schenk <ka...@gmail.com>.
On Tue, Sep 10, 2013 at 11:29 AM, Alexandro Colorado <jz...@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 <ka...@gmail.com> wrote:
>
> > On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
> >
> > > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
> > > For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Alexandro Colorado <jz...@oooes.org>.
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.
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, 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).
On Mon, Sep 9, 2013 at 4:00 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
>
> > On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Kay Schenk <ka...@gmail.com>.
On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <ro...@apache.org> wrote:
> On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@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
Re: Does our "Decision Making" information need additional instructions?
Posted by Rob Weir <ro...@apache.org>.
On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <ka...@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
>
>
> -------------------------------------------------------------------------------------------------
> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org