Difference between revisions of "Development Process 2006 Revision Comments"

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

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

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