Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search

Development Process 2006 Revision Comments

Purpose of This Page

The Development Process 2006 Revision page was becoming a little difficult to read with conversations and old comments interspersed with the text, thus I moved some of the old comments here while leaving a summary on the main page.

At the same time, I suggest that comments that conversations be done on the newsgroup, again with a summary placed into the wiki.

Requirements 1

The comments below all refer to a previous version of the Requirements section where I had three kinds of criteria: Required, Recommend, and Suggested. I took their advice and changed to two more clearly separate names. --Bjorn Freeman-Benson
How do you get "M" out of Recommended? When I saw "M" I thought "Must". I Mecommend that you pick three words with unique first letters. --Ed Burnette
What's the difference between recommended and suggested? Recommended practices are ones that have been observed to be beneficial for a long time; suggested practices are ones we believe are helpful but haven't been practiced for a long time and so we're not as confident? Do we need two separate categories - recommended and suggested? Perhaps, Requirements and Guidelines are more meaningful categories instead of Required, Recommended and Suggested. -- Anurag Gupta

I agree with Ed and Anurag: the difference between "Recommended" and "Suggested" isn't obvious and using "M" for "Recommended" isn't descriptive. --Dani 09:17, 13 October 2006 (EDT)

How about Mandatory, Strongly Recommended / Suggested, Complementary, or else Must Do, Should Do, Could Do? --nickb 14:07, 18 October 2006 (EDT)

You all are right - I don't know what I was thinking. Let's go with Requirements and Guidelines. --Bjorn Freeman-Benson

Structure and Organization 2

The comments below suggest adding a hyperlink. I took their advice . --Bjorn Freeman-Benson
Add a hyperlink to Bylaws section VII. -- Anurag Gupta
Unfortunately, the Bylaws is a PDF file, so the best I can do (and have now done) is a link to the Bylaws. You'll have to get to section VII yourself. --Bjorn Freeman-Benson
Hey, Bjorn... Let me teach an old dog a new trick! --Rich Main
Thanks, Rich, I didn't know that worked. -- Bjorn Freeman-Benson

Development Process 3

Please add a hyperlink to the status reporting procedures. -- Anurag Gupta
I have added a link to the current procedures. They are subject to change and improvement. --Bjorn Freeman-Benson
We should limit this to objective information, basically what's stored in project-info files today. There *are* other things we should demand, like a project plan that's accessible from the home page and up to date and RSS feeds for build info -- but the idea of a written quarterly "memorandum to management" seems wrong.--Tim Wagner
I agree. How about removing the "quarterly" and then leaving the details to be defined in that separate document? I.e., "All projects are required to report their status on a regular basis using the EMO defined status reporting procedures.". --Bjorn Freeman-Benson
Clearly, it is critical for the community at large to have visibility into the health and progress of the projects. As much as possible, this should be automated (e.g., Project Dash). In addition, it is critical that project deliverable timelines be communicated consistently (see for example the information that is lacking in the current project timeline) and that the project plans are kept up to date. Generally speaking, any well run projects will have all of this by default and as such a separate status report would not be needed. Lack of this kind of information would indicate an unhealthy or non-transparent project. -- Rich Main

(add next comment here)

Copyright © Eclipse Foundation, Inc. All Rights Reserved.