Bug 213788 - The creation review process as it is written doesn't correspond to how it's actually practiced
Summary: The creation review process as it is written doesn't correspond to how it's a...
Status: RESOLVED FIXED
Alias: None
Product: Community
Classification: Eclipse Foundation
Component: Process (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P2 major (vote)
Target Milestone: ---   Edit
Assignee: Bjorn Freeman-Benson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 213493 220871
Blocks:
  Show dependency tree
 
Reported: 2007-12-23 08:04 EST by Ed Merks CLA
Modified: 2008-03-07 01:24 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Merks CLA 2007-12-23 08:04:38 EST
This document spells out the creation review process

  http://www.eclipse.org/projects/dev_process/creation-review.php

The discussions in https://bugs.eclipse.org/bugs/show_bug.cgi?id=213493 make it clear that the process as it is practiced has been changed relative to how it is written without those changes being reflected in the written document.  That's clearly very confusing to the community.

I believe it was pointed out to the membership at a members meeting that generally very few people attend any of the review meetings, both the creation reviews and the release reviews. It doesn't appear that the review meetings themselves are canceled as a result though.  I'm not sure it was made clear to the membership exactly how their views on review apathy would be reflected in substantive changes in documented process and their practice.  I'm also not sure if the board itself needs to approve such changes or even be informed of them.  As such, I'm asking what is the process for changing something like the creation review process? Does it happen at the direction of the membership present at a particular face-to-face membership meeting?  Do the actual changes to the document need to be approved by a vote of the board or the membership? And once approved, how is the community informed of the changes, and how are they tracked so as to leave an audit trail?

Whatever the answer to the above, in the interest of transparency, I'd like to see a reference to meeting minutes where substantive process changes have been approved and to see that associated with an actual delta to the process document, including easily accessible information on the website to act as an audit trail so that anyone in the community can know the process has changed since the last time they read it.  You'll recall discussions earlier this year where folks expressed concerns about surprising process changes.

Of course I know the EMO is a strong believer in following the documented processes or changing them to reflect the actual processes as they are practiced  so I think that's needed here.
Comment 1 Bjorn Freeman-Benson CLA 2008-03-07 01:24:31 EST
I claim that the proposed new version of the Eclipse Development Process (just posted, see http://eclipse-projects.blogspot.com/2008/03/edp-2008-1-hierarchical-projects.html) fixes this problem. I am going to mark this bug as RESOLVED/FIXED even though:
(1) the proposed new version has not yet been adopted by the Board, and
(2) I have not yet revised the guidelines (such as the url in the description of this bug) - I will revise the guidelines after the Board adopts the core EDP because the guidelines are based on the core EDP.

Please direct comments about the proposed revised EDP to bug 220871 so that we have a single place for the conversation.