On Sun, Sep 8, 2013 at 3:48 PM, Rob Weir <robw...@apache.org> wrote:
> On Sun, Sep 8, 2013 at 4:23 PM, Kay Schenk <kay.sch...@gmail.com> wrote:
> > The information we currently have on Decision Making can be found in our
> > Orientation section:
> >
> > http://openoffice.apache.org/orientation/decision-making.html
> >
> > On that page, there are explanations for types of decision making used in
> > this project specifically and within the Apache Software Foundation. In
> my
> > opinion, this is very good "how to" guide, but somewhat limited as a
> "when
> > to" guide.
> >
>
> I drafted the orientation pages based on my understanding. I didn't
> get many comments at the time, so I'm sure there is room for
> improvement.
>
> > Most of the source code changes done currently are preceded by a BZ
> issue.
> > This is wonderfully simple and anyone on the commits list can follow what
> > and why something has been done. In other cases, for much larger
> changes,
> > discussions have been initiated. So, we would NOT see an action such as
> > deleting an entire module undertaken without discussion. Decision making
> > for these types of change follow a a well-known and followed process.
> >
> > Aside from code changes, there are changes to other areas of the project
> --
> > web sites, wiki, forums -- whose changes are not typically noted in BZ.
> > Sometimes there are proposals and discussions, sometimes not. These are
> > the kinds of changes that may need additional clarification with regard
> to
> > decision making.
> >
> > In summary, what kinds of change for non-source code need a
> > [PROPOSAL]/discussion before change?
> >
>
> For source changes and non-source changes the idea is essentially the
> same. It is a judgement call more than a hard rule. That's why we
> should try to vote in committers who have demonstrated good judgement
> as well as technical skills.
>
> We operate in Commit-Then-Review mode most of the time, except when
> close to a Release Candidate. We try to avoid unnecessary discussion.
> A timid committer who needs to review every minor change with is an
> annoyance to most of the 453 subscribers of the dev list. So we want
> to encourage JFDI where appropriate. But it is still a judgement
> call.
>
> But in general, I think (my personal view) a committer should put out
> a proposal in situations such as:
>
> 1) They are unsure of the technical merits of what they want to do.
> They want an extra pair of eyes to review the proposal point out
> weaknesses, alternatives, etc.
>
> 2) It is a job for more than one person or requires coordination
> across several subgroups within the project. By putting out a formal
> proposal you can find additional volunteers and move forward in a
> coordinated way.
>
> 3) A change to one of our websites that impacts terms and conditions,
> license, copyright, branding, etc. So not a technical change, but a
> substantive change to content in these areas. These require PMC
> review.
>
> 4) A technical change that breaks backwards compatibility of the product.
>
> 5) Changes that break things. Sometimes this is unavoidable. But it
> should be proposed and coordinated like #2 above.
>
> 6) Changes that cannot easily be reversed. Code changes and most
> website changes are in SVN and can be reverted. But some changes,
> like administrative bulk actions in BZ, cannot be easily undone.
>
> 7) Public statements in behalf of the project, e.g., some blog posts
> and announcements, press releases, etc.
>
> Those are examples, but the list is by no means complete. And for
> almost any of these there may be cases where CTR or even JFDI is
> appropriate. I'd take them more as "things to think about" when
> developing good judgement.
>
> Regards,
>
> -Rob
>
These are great guidelines! We should definitely integrate them into the
Decision Making page somehow. Number 7 might need more elaboration.
"Developing good judgement", like so many things in life, is learned by
trial and error. It would be great if we could at least better define what
we think "good judgement" is.
>
> >
> >
> >
> -------------------------------------------------------------------------------------------------
> > MzK
> >
> > "Truth is stranger than fiction, but it is because Fiction is obliged
> > to stick to possibilities. Truth isn't."
> > -- "Following the Equator", Mark Twain
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
