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)

I'm speaking about the observable fact that in the Trial-3, Ship.2, and Update.1 releases, we concentrated all the integration at the end. I do not think it serves us well to continue that trend and hence I am proposing that we attempt to change it, first by agreeing to do so, second by appointing someone responsible (for doing so via public media subject to direct criticism), and third by trying out the immediate principles on a smaller bug-fix release to deal with keyboard issues. --Michael Stone 14:59, 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)

No change of vehicle is necessary, only one of the usage principle. The difference I see is the increasingly intentional use of public archived agreement and argument for release oversight. --Michael Stone 14:59, 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:" (MS)

Does it help scale our project? (MS)

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

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? --Walter 08:36, 14 May 2008 (EDT)

You're right that the relationship between release process and sustainability is not adequately argued. I'll try to improve it. --Michael Stone 14:59, 14 May 2008 (EDT)

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?

You're correct that I have employed 'user' ambiguously, at times in the sense of 'user of the release process' and at times in the sense of 'user of released software'. The question is important in both senses:

• because many developers have complained that they have trouble figuring out how to get their changes released, I have tried to design and explain a release process which will build up a public corpus of examples of how to get your work released, and
• if the release process significantly hinders 'users of released software', then this hindrance needs to be justified

--Michael Stone 14:59, 14 May 2008 (EDT)

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.

I'm interested in implications of your final remark but I don't immediately see how to relates to your other criticisms or to my writing.' --Michael Stone 14:59, 14 May 2008 (EDT)

--Walter 08:44, 14 May 2008 (EDT)

P.S. - Thanks for the fine criticism. --Michael Stone 14:59, 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

No one is presently responsible for deciding which Trac changes are important or for making sure that important changes to Trac get noticed. Both issues are very hard to do well so I hope that several people will work on them. I think that a good way to get started might be to start writing 'Trac summaries' like the 'list summaries' of some other projects (e.g. Perl6). --Michael Stone 17:23, 14 May 2008 (EDT)

the consequences of breaking the contract.

How does this work in a volunteer-heavy organization where we don't give many (if any) volunteers "privileges" 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

I anticipate that the usual consequence will be "software X doesn't ship". I included the 'contract breakage' item because I'm convinced that it's good to state failure modes up front. --Michael Stone 17:23, 14 May 2008 (EDT)