Thanks Kent! I'll make these edits, but put them here as well.

Comments inline. (Sorry for messing up the formatting, but I had to
for inline comments.)

I guess the high-order bit is that we should define how milestone
readouts are sent and with what subject's.

--Colin


On Fri, Oct 31, 2014 at 3:39 PM, Kent Watsen <kwatsen@...> wrote:

Overall very good at defining "what", but less so at defining "how". For instance:

Planning

Projects must declare their intent to participate in the Simultaneous Release by M1.

How? Send email to "project-proposals" list with specific Subject line and, in the body of the email, a link to Lithium-compliant release plan? - in addition to also listing themselves under the "Participating Projects" section on this wiki page?

To participate, you must e-mail your candidate release plan to the
release list on M1. I'll make the edit.

Leadership & Communication

Each project must elect a Project Lead as described in the TSC charter

Section 7 of the TSC charter describes voting, but missing from this section is a demonstrable output, such as the project lead's name being added to the projects main page's "Project Facts" boxes, and maybe send an email to a list declaring the choice as well?

+1 I'll add a note saying to (i) update the project facts template for
the project, (ii) update the participating projects table of this
release, and (iii) e-mail the <project>-dev, release, and tsc lists.
(We really also need a place to describe the process in general,
separate from a release plan.)

Meeting Deadlines

If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?

Is this summary to be posted to the Wiki, sent to a list, sent to just dependent projects, or all of the above?

Good point. It should (at least) be part of the readout projects send
to the release list at every milestone. It should also maybe go on the
wiki.

Cross Project Milestone and Release Candidate Reporting

It is the responsibility of each projects Simultaneous Release Contact to report both positive and negative statuses

How? - by sending email to "release"? - any specific subject line needed?

Sending to release, but good point.

Nits:

Introduction

OLD: This is a Simultaneous Release Plan for OpenDaylight.
NEW: This is a Simultaneous Release Plan for the Lithium release of OpenDaylight.

Sure.

Leadership & Communication

OLD: Each project must elect a Project Lead as described in the TSC charter
NEW: Each project must elect a Project Lead as described in the TSC charter, section 7.

Sure.

Leadership & Communication

OLD: The Project Lead will be subscribed to the release mailing list and must respond to requests send to the a timely fashion
NEW: The Project Lead will be subscribed to the "release" mailing list and must respond to requests sent to it in a timely fashion

I'm curious what the logic is here? Is it to make it italics or bold?

Service Release Participation

OLD: All projects participating in the release are also required to participate in the stability releases after the formal release
NEW: All projects participating in the release are also required to participate in the stability releases after the formal release (please see Lithium_Service_Release_Expectations for details)

Sure.

Meeting Deadlines

OLD: If a project cannot make a deadline, the project lead must write a summary of what was missed? why? the course correction that will be taken? and it's impact on other projects?
NEW: If a project cannot make a deadline, the project lead must write a summary of what was missed and why, the course correction that will be taken, and it's impact on other projects.

Sure.

Bugs

OLD: Bugs should be filed in Bugzilla
NEW: Bugzilla is used to track all bugs in OpenDaylight. Bugs must be filed for the appropriate project.

Sure.