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 > > > ------------------------------------------------------------------------------------------------- > 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
