Talk:Plan of Record-2008/Draft 3

To date, we have made "omnibus" releases rather than incremental releases.

Can you provide concrete examples of how this transition will happen? I am not sure I understand what you are talking about. --Walter 08:34, 14 May 2008 (EDT)

Oversee the release manager via regular public feedback on current progress, immediate needs, and risks.

What is the new vehicle for this? It hasn't seemed to work in the past. --Walter 08:36, 14 May 2008 (EDT)

However, each release impacts our ability to make future releases in many ways. For example, it becomes harder to maintain and disseminate knowledge of the relationship between bugs, work items, and releases. Consequently, important criteria for this essay are:

Does it help scale our project?

Does it encourage our users to accept responsibility for creating the software they need and for teaching others what they have learned?

Lost me again in a series of tautologies and nonsequitors. Of course each release impacts the next one, but—maybe I missed it—where is the discussion of a process that will impact these dependencies? Also, the responsibility seems to lie at the feet of the release master, not the "users", who don't seem to be mentioned at all in the plan. Or are "users" a code word for developer? In any case, what part of the process encourages taking responsibility for creating the software they need and teaching others? In fact, one unusual hallmark of this project has been that developers are taking responsibility for software other people need, but to date there have been few fora for them to interact directly with users of their software. --Walter 08:44, 14 May 2008 (EDT)

The release manager is the authority on what is shipping and what is slipping. Public writing allows more comprehensive oversight than does twiddling bug priorities in Trac.

On that note, who is the bugmaster for various components of the software system? Is there one? Should there be? If Trac is being used as the queue of prioritized problems to work on, someone should make sure it does that job well. Mchua

the consequences of breaking the contract.

How does this work in a volunteer-heavy organization where we don't give many (if any) volunteers "priveleges" that could be suspended as "consequences" of breaking contracts? I would actually call the absence of contracts (both informal and formal) with the OLPC volunteer community one major shortcoming of OLPC's volunteer outreach/support methodology - neither side knows what they can expect from the other. Mchua