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