2009-08-06

Telephone: +1 812 856 7060
Internet: 156.56.240.9

Sakai001

Goals for the 2.7 release (insofar as release management and QA are concerned)
First round of triage:
- which portions of work need to go to the product council
- which portions of work belong under "high user impact"
Whether we have a branch manager, and if not what will be done to recruit one
A discussion for how the release team should organize itself and recruit new members. (Proposal will need to be worked up to go out on-list)
Review and Refine procedural details for next month of work

Anthony Whyte
Seth Theriault
Pete Peterson
Adam Hocek
David Haines
Steve Smail
Megan May
Charles Hedrick
Pieter Hartsook

Overview and goals

2.7 out by EOY.
During this time proposed changes to release management process will be tested, vetted and evaluated&nbspduring this process.

Comments on what would most improve the RM process

Knowing what's in the release ahead of time
More recruitment of participation by early adopters
Documentation of changes and release notes during the process
Need to target a full release product, esp. quality documentation, and not only bug-squashing
Need to report out the discussions and consensus points more reliably

Reviewing Proposed Sakai 2.7 changes

Need to come to an understanding of what we're facing, how it can be documented and tested.
Will need targeted communication with team leads or individuals to elicit response
Should be easy place for developers to see what the status of their work is, e.g. what more needs to be done, and by when
Template for communicating the changes and what needs to be shared with the community (Scorecard and others). Too many templates right now, need a clear standard.
Get more volunteers to review these issues other than just Foundation staff
The chart lays things out as JIRA line-items, when some of them should be clumped because they may impact one another.
Not what should be in or out, but rather does the release team have the information it needs? Do they have test plans, documentation, etc.
Action item: volunteers pick up "high user impact" items, and go through and document what questions need to have answers, and we'll use this small set of concrete cases to establish what our development reporting template should be.
- Megan - Forums
- Clay - Assignments
- David Haines - Synoptic Messages/Forums tool
- Anthony - when back from vacation will work with Pete on cleaning up Jira issues

Release Team Creation

Release team organization is being organized right now, and we're in an awkward state while Anthony is on vacation and we don't yet have branch managers.
UCT's interest in 2.7 not guaranteed, so we can't assume David H, but he expressed interest. Probably want more than one branch manager for this effort.
What is the process for putting together the release team? Anthony - go out individually to active community members in this area and try to recruit them.
Need to set up clear expectations and guidelines ahead of time so that if and when things come to a head in the release process it's not just a debate on a phone call; not just a competition between local interests.
It hasn't been like that recently - the discussions have matured since the early days.
We do need to clearly identify people and roles, and eliminate the mystery.
Some of the details of pulling this team together is going to need to wait until Anthony gets back, but we won't wait to have it formalized before we start working on what we know needs to happen.

Volunteers go through a few concrete projects and identify questions that need answers (see above)
We'll attempt to synthesize these on a Confluence page (Clay will create one), and develop a clear template that all development leads can use. Should have this by next week's meeting.
Anthony will work with Pete on some JIRA cleanup