| <h1 align="center">Requirements and Design for Simultaneous Release Tracking Tool</h1><h2 align="center">Draft - initial working version.</h2> |
| <p></p> |
| <p>This system is to help track and document projects progress towards the yearly simultaneous release. Primarily, it is a web application, that allows the Eclipse Projects to easily checkoff requirements, and paste in relevant URLs, descriptive text, related bug numbers, and other similar things. In can aide the projects committers so they can be sure they are completing the required steps and requirements, but also helps Project Leads, the Planning Council, and potential adopters to see the "big picture" of projects they are monitoring. </p> |
| <h2>Administration</h2> |
| <h3>Setup</h3> |
| <p>At a minimum, the system needs the ability for an administrator |
| (e.g. webmaster, or Planning Council Chair) to enter in the projects |
| that are participating, probably using the Foundation Portal short name. At some level, access to the projects metadata is necessary, sometimes for minor things like full name, sometimes for complicated things, like what the project's parent is, or what children is has. </p> |
| <p>Eventually this could be more and more automated, starting with a project checking the field in the Portal, but full automation is not required for the first release. </p> |
| <p>The setup occurs basically once per year, perhaps over the period of a few months (e.g. August to December). </p> |
| <p>The setup also requires the initial input or statement of the requirements, and what "data" to collect on them. </p> |
| <h3>Modification</h3> |
| <p>Through out the year, it will be required to occasionally do some administrative maintenance. For example, remove a project that had to end, correct spellings, and other minor edits. In theory, even child to parent relationships can change during the year ... but, is not frequent. </p> |
| <p></p> |
| <h2>Use by Projects</h2> |
| <p>As the year progresses, projects check off requirements, and fill |
| in data required by the requirement. This data, when it is required, is |
| typically a URL to some other document or explanation. Occasionally it is a text (prose) description, and occasionally a list of bug numbers, or similar. </p> |
| <p>As an example, of such a form, see the <a |
| href="EclipseSimultaneousReleaseFormPrototype.html">Eclipse Simultaneous Release Form Prototype.</a> [Still need to design exact form, how much text to repeat from requirements document, etc.].</p> |
| <h2>Data storage and backup.</h2> |
| <p>Naturally, as Projects enter their data over the months, that data (even though incomplete) must be stored and saved, partially so it is there the next time they go to add some more data. And also, of course, to survive disk failure, or similar. There won't be much data, but something like database storage, or XML Files would suffice. </p> |
| <h2>Use by Project Leads and Planning Council</h2> |
| <p>Certainly the PLs and PC will want to look a the data in a form very similar to how it is entered (say, a "read only") version of the form. </p> |
| <p>But, as or more important, several "summary" type reports will be desired. These have yet to be designed, but typically involve some degree of "roll up" (for example, see a summary report for only the Top Level Project, based on its sub-projects. Another possible example, there might be one report with some summary of the "API state" of the simultaneous release ... who's clean, who has most requests for API, etc. </p> |
| <h2>Security and Permissions</h2> |
| <p>The main type of "security" that is required, is just to make sure the right people are making changes ... that someone does not change the data of someone else's project by accident, or maliciously. To start with, it might suffice to simply make sure those making changes are logged in as committers. In a second phase, it might be safer, though more work, to maintain a list of who is permitted to change which projects. As a matter of "security", it would be a good idea of provide some amount of "logging" so there is a record of who changed what.</p> |
| <h2>Collecting other data</h2> |
| <p>While not a hard requirement for the first version, eventually we want this web app to also handle parts of the exception process. Currently, the mechanism for someone to request an exception will be for PC Member to post a note to mailing list, and get three votes, etc. It would provide a good, long term, consise record if the PC Member could enter the exception request, right there near the data, and the PC "vote" right there as well. That way, the work, and the data, is all in the same place. </p> |
