Revising Eclipse Development Process: Release Reviews

I made a mention to Mike a couple of weeks back that I wanted to make a few changes to the Eclipse Development Process (EDP). He seemed to think that evolving our process was a grand idea and reminded me that changes to the development process require approval from the Eclipse Board. I knew that already, but it was still nice of him to remind me (he’s one of those give-you-gentle-reminders-and-let-you-get-it-done sorts of bosses). But I digress.

I was originally thinking of only a few small changes. But I’ve gathered up a bit of steam and have decided that maybe it’s worth trying to make some more fundamental changes. I’ve been in this role for about nine months; after nine months of immersion in our process, I have some ideas where I think we can do a better job. But before I start making wholesale changes, I though it might be prudent to try and bring some of my ideas before the community to gather feedback. Keep in mind that–ultimately–any changes we make to the development process do have to be approved by the board, are bounded by our bylaws, etc.

There are several key principles that I believe underly the EDP (in no particular order, because they’re all important):

• Transparency
• Openness
• IP cleanliness
• Quality

I believe that most of what we find in the EDP is intended to support one of these key principles. Correct me if I’m wrong.

There’s one more thing that I’ve added to this list:

• “Do the right thing” ahead of process.

Recently, I’ve been thinking a heck of a lot about reviews. Release reviews in particular. I’ve had many conversations with committers about release reviews and why we do them. Years ago, we required that project members “meet” the community on a scheduled call to present their case for release. Attendance on those calls was never particularly strong, and so the call melted away and we’ve effectively changed over to a “review period” of a week that infrequently involves some kind of call. The project still has to provide review “docuware” and the working theory is that interested parties from the community read this carefully prepared documentation and then theoretically pose questions that are theoretically answered. I don’t mean to sound overly theoretical, but my experience is that most of these documents are read by Anne and me, and few others outside of the project. Correct me if I’m wrong.

I’ve written in the past about how valuable I think these documents are. This hasn’t changed. I still think that it’s valuable to a project to capture what they’ve done leading up to the review. But I wonder if the energy that goes into this document could be better directed at something with a little more shelf-life. Like, perhaps, a “new and noteworthy” document for the release.

So here’s what I’m thinking. Keep in mind that we’re still very early in this process and that this is little more than an idea at this point.

At the beginning of a development cycle, projects are required to provide a project plan in the standard format. The project plan document has a handy spot for listing release dates. Through the plan, the release dates are easily accessible by interested parties (users, contributors, adopters, and the broader community). We can even parse out these dates and include them on the “What’s New” page and RSS feed.

So each project can use their plan (in the standard format as required by Board mandate) as the mechanism to notify the community of the release. This gives the community the project’s entire development cycle to get involved, ask questions, challenge assumptions, and what-not.

When a project is ready to complete their release (as documented in their project plan), they get IP Log approval, put the finishing touches on their “new and noteworthy” documentation, and open a bug that states that they’re ready to release. Either the project’s PMC or the EMO (or both) adds their +1 to the bug and Bob’s-your-uncle. The approval is required to ensure that the aforementioned principles (and documentation requirements) have been observed. By this point, however, approval should be little more than a rubber stamp since the PMC and EMO will have been aware of the pending release for some time.

Frankly, if the community hasn’t gotten involved by this point, I’m not sure how adding an additional week of review time will improve matters…

I like this approach because the two documents that are needed (the project plan and “new and noteworthy”) (a) are things a project should be doing anyway, (b) are, at least in the case of the project plan, actual requirements set down by the Eclipse Board, (c) convey the really important information that is contained in the review documentation, and (d) are immediately useful. Correct me if I’m wrong.

Again, this is just an idea right now. It’s something I’d like to explore. In my mind, this should be easier for projects and more valuable for the community. I believe that it is a natural evolution of the process.

Thoughts?