problem statement or why we do this project
keep the goal statement as simple as possible and include criteria to make it clear when the project will be completed. one way to think of this statement is, what is the benefit of completing this project?
list items that are both in and out of scope for the project
estimated project time
list any sub-projects - depending on complexity you may want to create a project page for each sub-project
at a minimum, a sub-project should have a name and description. it may also include a link to the project page or inline text for a simple sub-project.
|Announcements||dev-platform and dev-planning lists||all|
|General discussion||dev-platform list||devs|
|Meetings|| meeting time
|Meeting summaries||this wiki||all|
Press & Blog Posts
optional - you may want to capture press, blog posts, etc. about the project
Minutes and Progress Reports
list required competencies for people and, once defined, the people working on project. note that not all of these competencies will be required for every project
|Engineering||primary devs working on project|
|Other Engineering||subject matter experts contributing to project|
|Incoming Bug Triage||this may be someone listed elsewhere, the key is to list people who handle triage|
high level milestones can be included in this page. more complex milestones and tracking information (typically bug lists) should be included on a milestone specific tracking page
feature, partner, resource, etc.
list risks in table below. assign a unique risk id to each risk. for ex., the project plan template may define risk ids prefixed with PPT like PPT001.
other references, very useful catch all category for existing links and text when cleaning up existing project pages