Development Process Issue Summary

This document has a status of draft, ready for review.

Problem Summary

We need a consensus on a development process that will support our particular needs.

• we have a relatively small team that will grow
• we're an open source project and want to incorporate help from far-flung volunteers
• we want a solid, well designed architecture
• we want to create a fantastic user experience
• we're at an early stage of the development cycle
• we want to release early and often: regular development releases

We've felt some tension between folks who want a highly iterative process with low formality (avoiding writing lots of specs before you jump in and start coding), and folks who want more design and review up front, before committing decisions to code. We don't need a one-size-fits-all approach to every problem, but it would be good to get consensus on a flexible, lightweight process that allows for enough review to ensure a good design.

Our process may evolve over the lifecycle of the project, the immediate problem is a process that will work for the next few early releases: 0.2, 0.3, etc.

Goals

• Lightweight, low formality: should not require lots of learning and ceremony to use. Process is only useful if it helps us be more efficient and effective.

• Open: accessible to volunteers outside OSAF staff.

• Iterative: especially for ui code, we want a process that lets us iterate rapidly based on feedback.

• Clear and consistent: A developer should be able to get up to speed quickly on any particular area. Any interested party should be able to understand the current state of a parcel/release/module/topic, the source of 'truth' should be clear and consistent.

MichaelToy likes this aspect of the Zope process: (1) proposals have well defined states they can be in (2) you can tell the state of the proposal by where the document is placed, (3) there are well defined criteria for when a proposal moves from one state to the next.

Issue Summary

Elements the development process needs to cover:

• Requirements
  • Use cases
  • Feature lists
• Design
  • Architecture
  • API design
  • Schema design
  • UI design (UIDesignProcessIssueSummary)
• Schedule
  • Task estimates
  • Milestones
• Review
  • Design review
  • Code review
  • Security review
  • Data review
• CVS check in policy (BuildIssueSummary)
  • Support development on 3 platforms
• Testing, QA (QualityAssuranceIssueSummary)
  • Unit tests
  • User tests
• Documentation (DocumentationIssueSummary)
  • Non-code artifacts of the development process -- specs, api documentation, etc.

MichaelToy is the owner of the development process.

Risks

• Chaos prevents volunteers, staff from contributing effectively. Hard to grow the team. Our process looks a bit chaotic to anyone outside the OSAF staff (and perhaps to the OSAF staff as well!) It would be great if we could communicate more clearly.

• No clear review process results in no review, or no forward progress. We could do a better job of having an efficient proposal and review process. Perhaps the review process happens after some "elaboration" code, perhaps it happens after a quick writeup before code is written, perhaps it varies depending on the problem.

• Slow progress made on thorny issues, constant rehash of issues. Too much time in the land of the architecture astronauts. A good process would let us discuss problems, issues, alternatives, but also force us to make a decision, document it and move on.

• UI design is an integral part of the process, and not limited to a particular "step" or stage in the development process. Although we're addressing it in a separate document, it needs to be coordinated with the overall development process.

• No schedule, no way to get a good schedule to make hiring, budget decisions. How far out do we do bottom up scheduling? Release by release, a few releases ahead, or all the way out to Canoga and/or Westwood? If we need a good schedule for Canoga and Westwood, does that imply we need to spend more up front design time to make that happen? Can we get by with top-down estimates, or estimates based on similar projects, for longer range planning?

• This document describes the development process from the engineering perspective, we also need to work out the larger scope: product and release process. Is ChaoLam also an owner of this issue?

Known Answers

• We're using bugzilla as our defect and task tracking tool. Bugzilla will let us track priorities, time estimates, etc.
• We want regular release milestones, ideally 60-90 days. We're planning the 0.2 and 0.3 releases.
• We have a ProductRoadmapNov2004.
• We are beginning to write things down in the DevProcessProposal.

Dependencies

• UI design: UIDesignProcessIssueSummary
• QA: QualityAssuranceIssueSummary
• Documentation: DocumentationIssueSummary
• A good process helps support non-staff developers: DeveloperSupportIssueSummary
• Our next milestone: DotTwoReleaseIssueSummary

Resources

• Zope's process, an attempt to be open and lightweight: http://dev.zope.org/Fishbowl/Introduction.html
• John's comments on process to the dev list (these same comments are also posted on the wiki)
• Greg Noel's comments to the dev list about Wiki organization for parcels

-- KatieCappsParlante - 07 May 2003

---

---

Discussion

• We should include bug fixing, maintenance, how to accept external patches (and other contributions) and change-of-ownership issues to complete the development lifecycle.
• We should also attach titles or roles to each step of the development process to ensure clear authority/responsibility. It's OK for individual tasks to vary from this 'template' but the variance should be duly noted and rationalized.

-- ChaoLam - 15 May 2003

---

Here's another candidate for the "risks" section:

• We might set up an adequate process, but then fail to use it. Or we might use it in some cases, but not use it in other cases. Even with a very lightweight process, it will take some discipline to get in the habit of using it consistently.

And in the "Issue Summary" section, it might be good to add an element for "ownership". This is kind-of a follow on to what Chao just said above about ensuring clear responsibility...

• Different people are responsible for different parts of getting Chandler built. From outside of OSAF, it's hard to tell who's responsible for what, or who to contact about what. It'd be great to more clearly document who's doing what, and who's responsible for what. That ownership information could be presented in different ways. One way to do it would be to just have a wiki page (or a set of wiki pages) with some big lists of parts, and a person's name beside each part. A "part" might be an API, or a parcel, or set of documents, or a section of the public wiki, or a relationship with a vendor.

-- BrianDouglasSkinner - 15 May 2003

---