• Each planning item should have a corresponding tracking issue in Issuezilla. The URL field should contain a link to a 1-pager document (e.g. on wiki.netbeans.org, or http://module.netbeans.org/)
 with high level description of the item and serves as an index page for all related documents (design, UI spec, dependencies, etc).  For simple 
 items all the information can be kept in Issuezilla.
  • The tracking issue should be tagged with PLAN in the Keyword field and appropriate version number in Version field. That's how we can know which issues are being planned.
  • Use the Target Milestone field to indicate when the planning item should be completed. Use PLAN and TBD as target milestone if you know you want to do it for this release but don't know by which milestone yet. See NB61Milestones
  • Use the Priority field to indicate level of commitments:
  • P1: must have, we will not ship without
  • P2: should have, we will ship with it unless we run into big troubles down the road
  • P3: nice to have, under consideration, but if it's costly then they will be dropped
  • Tag the planning item with Keyword UI, if the planned feature modifies NetBeans user interface.
  • Make sure the issue's Summary is correct and understandable even if the reader doesn't read the whole issue report. Oftentimes the
 discussion in the report develops into something larger or even something totally different than the reporter thought initially.
 Developers should update the summary field in those cases.
  • A cron job queries Issuezilla every 30 minutes or so to generate a complete list of PLAN issues.
  • Planning items are end user visible features, new APIs, important subtasks other teams depend on
  • Bugs are not planning items. They are subject to the usual bug criteria. But tricky bugs which require significant effort (redesign part of the
 system for example) should be tracked at planning level.
  • Teams are encouraged to file subtasks in Issuezilla and assign them to team members, i.e. use Issuezilla as a lightweight project management aid. Conventionally the "master" task should be marked with Keyword UMBRELLA.
 Those subtasks within each team don't have to be tagged with PLAN.

A plan essentially is an answer to six key questions: what?, why?, where?, when?, who?, and how?. In this scheme

  • what, why, where, how are answered in the 1-pager documents
  • who, when are answered in the tracking issue in Issuezilla

One of the common pitfalls of software development planning is a lot of effort is invested in producing the plan document, but then it's not kept up-to-date. This is why some people say "planning is priceless but a plan is useless". We hope by using a cheap mechanism like Issuezilla there is a higher chance that the plan will be up-to-date.

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo