BUP Component

Meeting Notes (02/01/06)

Participants

Bruce Macisaac, IBM
Ricardo Balduino, IBM
Kirti Vaidya, Covansys
Brian G. Lyons, Number Six Software, Inc.
Per Kroll, IBM
Steve Adolph, WSA Consulting, Inc. / UBC
Kurt Sand, Telelogic
Jason Xabier Mansell, European Software Institute
Jim Ruehlin, IBM

Naming

There continues to be open discussion on the name. During the call, the three most popular suggestions were:
- Basic Unified Process
- Open Unified Process
- <proper noun> - some name that does not have an obvious acronym or baggage such as the word “innovation” in some other language.

See the previous conference call’s meeting minutes (http://www.eclipse.org/epf/bup_component/20060117_meeting_notes.php) for some points of discussion on the name. In this session, an additional point was made that we will need a name for the “minimally sufficient” process and perhaps a name for the family of processes that are within this project, but not “minimal” (e.g. the current BUP, plus extensions for model driven development, or for some more sophisticated project management perspectives, or for some specific domain). One notion was that the minimal process could be the Basic Unified Process and the family of processes extending off of it could be Open Unified Processes.

It was agreed that the various plans for outreach including seminars, articles, and coverage of the process in books require a name that we plan to keep. Our strategy for consensus is to have the committers vote on the name. We are going to be open for votes for the next week. [ Please read the section below on roles and the “Next Steps” section at the end of this document regarding this. ]

EPF Participation - Getting a Handle on Roles

We have a whole list of "participants" in the EPF project and the BUP component. We need for participants to be classified as Contributors or Committers. Here is a description of the distinction:

Contributor - Anyone can be a contributor. That person could just provide input or supply the description of a task or two. Contributors will not have read/write access to the content repository. A Contributor may participate in as small a level of effort as they desire.
Committer - A Committer is an individual who is to have write access to the Eclipse CVS repositories (http://www.eclipse.org/legal/newcommitter.php). A committer must sign that they read the guidelines; the committer’s employer must agree to the terms of the Eclipse public license. For this component we are looking for committers that can either commit to a notable chunk of content and/or can commit to significant, predictable participation in the leadership and authoring of content.

In the call, it was the general understanding that all initial committers referenced by the original project proposal (http://www.eclipse.org/proposals/beacon/) could become official committers once the paperwork has gone through the process. Others might have to somehow be "invited".
It is very important that we understand who the players are as we move into making decisions and allocating responsibilities. While we do not expect everyone to have the paperwork completed and processed right away, we would like an unofficial "commitment to be committer" by our next call on Wednesday, February 9, 2006.

Communications Channels

We discussed our communication channels.
We identified five different Eclipse communication vehicles:
- Content in CVS
- Forum to discuss things (Newsgroup)
- Bugzilla for defects and change requests
- Web site
- epf-dev email list

There is significant sensitivity to open, transparent communications in the Eclipse projects. Project-significant communications should not be sent to a closed list of recipients. As anyone can sign up for the email list (here http://dev.eclipse.org/mailman/listinfo/epf-dev), that will be an appropriate forum for discussing assignments and batting around ideas. As this email list is for the whole EPF project, BUP-specific messages should have a [EPF::BUP] prefix in the subject.
The Web site will continue to be the place for announcements, meeting minutes, and other such content.
As the project carries on we will begin to exercise the other communications channels as appropriate.

Analysis of Current BUP Content

We discussed the content donated by IBM. The findings were:
- We have the right disciplines. There was one concern as to whether or not the Change Management discipline needed some extra content to cover build management. This issue was deferred to be part of the work on the internals of that discipline.
- We have the right phases.
- We do not have appropriate coverage of the core principles. Some transcendent information on those principles will help, but will not be sufficient to infuse the existing process with things like a focus on collaboration.
- The existence of model driven design in the (otherwise minimal) BUP was questioned.

Partitioning the Process for Special Interest Groups

We decided to initially break the process work into chunks based on disciplines, plus overarching content, plus any additional plug-ins. We will have the following Special Interest Groups:
- Architecture
- Change Management
- Development
- Project Management
- Requirements
- Test
- Overarching Issues (delivery process, principles, base concepts, etc.)
- Model Driven Development

There was discussion of a possible plug-in for more sophisticated project management concepts, but that was not confirmed.
The actual logistics of these SIGs is up in the air. It might just be a way for someone to classify what parts of the process they should be focusing on.

Development Plan

There was an initial development plan laid out at the January 10-12 initial project meeting (http://www.eclipse.org/epf/general/f2f_Atl_minutes.php). We discussed it to make sure we all understood the relevant tasks for the BUP component. The notes below are the revised understanding from Brian Lyons.

M1: 1/15 - 3/1
Legal process to be completed by initial committers
We should have a first cut identification of all the pieces of BUP with an understanding of where each piece is on the road to completion.
We should have a clear understanding of who will be responsible for which parts of the process.
We will have our governance model

M2: 3/1 - 4/15
Freeze structural information for BUP (e.g. all guidelines, work products, etc. defined)
All pieces of BUP - whether completed, empty, or in-between – are in EPF form.

M3: 4/15 - 6/1
Draft content completed across process. There may be holes. Certain elements will require additional review.

M4: 6/1 - 7/15
Content freeze

M5: 7/15 - 9/1
End game
Produce launch collateral

Next Steps

- Everyone should feel free to suggest a name for the minimal, complete, extensible process. These suggestions should be made before Tuesday, February 8 so that the appropriate people have a chance to consider the suggestions and vote.
- Everyone intending to be a Committer must notify the group and initiate the process through the Eclipse Foundation. Each Committer must specify what contributions (in participation or existing content) are being offered and FTEs assigned to the project.
- Everyone intending to be a Committer should vote on a name shortly before the next call on Wednesday February 9, 2006 at 8am PST.
- Everyone intending to be a Committer or a Contributor should
- Per Kroll will submit draft governance guidelines to the group.
- We will send out the logistics to participate in the next call.
- We need to push on all participants for community outreach