Community
Participate
Working Groups
Graduation reviews are always combined with release reviews. Presently, Graduation review documents are just Release review documents with a couple of extra pages. Do they need to be special? Can we just say that when project moves through version 1.0--with a little extra attention from the PMC and EMO--they've graduated? Does this simplify the process, make it harder, or make no difference? The one wrinkle that I can think of is projects that arrive mature, with version numbers that are already 1.0+ projects of this nature tend to move through incubation relatively quickly, and we tend to let them keep their current version numbering scheme (to avoid confusing their users or screwing up bundle versions). How much does the actual number really matter with regard to project maturity anyway? Thoughts?
Just a reminder that the requirement for a Graduation Review is also currently baked into the IP Policy[1] Section V. The various reviews also provide an opportunity for the Membership to formally raise any IP concerns with a project. This is a right that has never been used, but I do believe that there are some member companies which do believe that these sorts of membership rights are important to them. [1] http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf
I'm not talking about taking away the graduation review. It's more of an acknowledgement that graduation reviews are always paired with a release review. I don't believe that this contravenes anything in the IP Policy. I'm also not talking about taking any reviews away. But I do hope to streamline some of the mechanical parts. We have an opportunity here to make the process for raising concerns more clear. I'm not sure if I want to bake anything into the new project management infrastructure, but it might be a good idea to do something simple like add a note inviting members to communicate any concerns with the review with the project team and emo via email. I was hoping to remove myself from the review process, but I think we may need to have some means of approving a review.
(In reply to comment #2) > I was hoping to remove myself from the review process, but I think we may need > to have some means of approving a review. I believe that under the current Board-approved version of the EDP, EMO approval of Reviews is required. Anything we can do to lessen the burden on the projects is great, but some final approval is necessary.
(In reply to comment #3) > I believe that under the current Board-approved version of the EDP, EMO > approval of Reviews is required. Anything we can do to lessen the burden on the > projects is great, but some final approval is necessary. Correct. "The EMO(ED) approves or fails the Review based on the public comments, the scope of the Project, and the Purposes of the Eclipse Foundation as defined in the Bylaws."
Graduation reviews need to stay. Should we state that a Graduation Review is generally combined with a Release Reviews (typically a 1.0 release)?
(In reply to comment #5) > Graduation reviews need to stay. > > Should we state that a Graduation Review is generally combined with a > Release Reviews (typically a 1.0 release)? +1
I've added a single line to section 6.3.2: -- A graduation review is generally combined with a release review. --
