openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: Does our "Decision Making" information need additional instructions?
Date Sun, 22 Sep 2013 20:27:14 GMT
On Thu, Sep 19, 2013 at 9:08 PM, Kay Schenk <kay.schenk@gmail.com> wrote:

>
> On Sep 18, 2013 3:10 PM, "Alexandro Colorado" <jza@oooes.org> wrote:
> >
> > On 9/18/13, Kay Schenk <kay.schenk@gmail.com> wrote:
> > > On Tue, Sep 10, 2013 at 3:18 PM, Alexandro Colorado <jza@oooes.org>
> wrote:
> > >
> > >> On 9/10/13, Rob Weir <robweir@apache.org> wrote:
> > >> > On Tue, Sep 10, 2013 at 5:11 PM, Alexandro Colorado <jza@oooes.org>
> > >> wrote:
> > >> >> On Tue, Sep 10, 2013 at 3:53 PM, Kay Schenk <kay.schenk@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 <robweir@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message