Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] target audience for release review documents

Hi Igor. Good question. This question gets asked every once-in-a-while. It's a good opportunity to reflect on this particular piece of the EDP.

The "How to" document [1] describes what we want to see in the review document.

The intended audience for review documents is the PMC, EMO, project committers, and the adopter community. I've discussed each of these audiences in several blog posts [2,3,4]; over time, I've come to believe that the user community doesn't particularly care (or even know) about these documents.

The release review document is one bookend of a release. The project plan is the other bookend. Over time, the pairs of these documents provide a solid history for the project that is useful when determining things like maturity of the project, or tracking significant changes.

One might argue that bugzilla is the place for planning. I would argue that it's a good place for planning, but a terrible means for disseminating plans and assessing success, learning lessons, etc. The project plan and release review document are an excellent means of summarizing (and capturing in time) the plan and results.

Ultimately, it's a part of the open and transparent development process, providing a concise means of informing the adopter, contributor, and committer communities about the project and how they can get involved.

Historically, review documents were required as part of a review presentation. Projects used to have to join a review call to present and defend their release in front of the community. We stopped doing these calls a long time ago. I still believe that there is value in presenting and defending your release (as discussed in the links below).

Pragmatically, these documents help the PMC and EMO ensure that the project is operating according to the Eclipse Development Process. I tend to look for evidence of community development, for example, and use the review as an opportunity to help the project understand the value of growing the diversity in the project.

I believe that we're making this easier to provide with the new Project Management Infrastructure [5]. Please feel free to tinker with it and let me know what you think.

HTH,

Wayne

[1] http://wiki.eclipse.org/Development_Resources/HOWTO/Release_Reviews
[2] http://waynebeaton.wordpress.com/2011/05/15/heavyweight-processes/
[3] http://waynebeaton.wordpress.com/2009/05/22/get-the-band-back-together/
[4] http://waynebeaton.wordpress.com/2009/12/22/revising-eclipse-development-process-release-reviews/
[5] http://projects.eclipse.org

On 06/18/2012 04:25 PM, Igor Fedorenko wrote:
I am sorry if this is a question with an obvious answer but who is
supposed reader audience for the release review documents and what
"they" expect to find in the docs?

--
Regards,
Igor
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects

Back to the top