I'd suggest less is more, fewer main teams means fewer points of coordination and less overhead.

I'd arrange things more like an org chart for purposes of accountability and let each of the teams manage its own internal structure so long as they meet their accountability standards. Of course PIG can provide guidelines.

Some of the choices I've made in my suggestion below are made to simplify the overall structure and/or because there are already well understood best practices regarding the groups charter that might not require the full process of being a team. For example, I18N is a very important priority for the Plone Community and in turn the marketing obligations of the Foundation. Because the techniques of doing i18n work are understood its an accountability of the various teams to ensure that work is properly done with regards to their charter.

                          Foundation
                       [ Marketing/PR ]
                              |
             | ----------------------------- |
          Release                    Process Improvement
        [ Quality ]                     [ Oversight ]
             |
             |
         Development ------------------ User Interface
    [ Product Development ]           [ User Experience ]

Accountability Checklists

These are again, merely suggestions. Each list of Accountabilities must include answers to the questions and sign off that the team agree that the feature meets the defined criteria. In the vein that "less is more" I say lets not define things in much greater detail than what is here until we have a way to measure the results of change to the system. Lets take the case of , "the feature must be well tested and all tests must pass". Checking this now means that the feature is tested to some vague level that satisfies the expectations of the team leads and they feel covers their asses with regards to whom they are accountable. This doesn't have the same specificity as "there must be a test for each method in the product", or "testing must show coverage of at least 85%". That level of detail comes with time, to pretend that we know the best criteria (and it will change over time) would just be make believe. If the process isn't working then each participant will operate with the understanding that their team working with the PIG group is responsible for evolving it, constantly.

Feature Lifecycle

This is a basic outline of how features flow through the proposed process.

1. Needs Analysis
2. Basic Questions Answered
3. Begin Tracking and Analysis
4. Feature Development
5. Criteria Evaluation
6. Release Candidacy
7. Release Inclusion
8. Goto Step 1.

Where these phases are unclear should hopefully be explained in looking at the example questions and checklists below.

Sample checklists — Development

Basic Questions

Are the reasons for the change documented?

Are the reasons for the change valid?

What systems are effected by the change?

Does the change introduce unwarranted risk?

Does the feature require migration to use it?

Is there a migration plan in place?

Do tests show how the feature would be accessed and used?

Document Driven Testing would be ideal at this phase for showing intended impact.

Criteria Evaluation

Do the tests all pass?

During evaluation this will have to pass using the current Release Set

During release candidacy this will have to pass on the Target Release Set

Is there developer Documentation in place?

Has the feature been internationalized?

Is there a working Migration in place?

Release Candidacy

Have the end user Documents been updated?

Does Marketing have an interest in this feature?

The branch is tagged at the end of this phase by the team and this tag is passed to the Release Manager

Sample checklists — User Interface

Basic Questions

Are the reasons for the change documented?

Are the reasons for the change valid?

Does the change alter the users understanding of the system?

What systems are effected by the change?

Does the change introduce unwarranted risk?

Criteria Evaluation

Are there Functional Tests in place and passing?

During evaluation this will have to pass using the current Release Set

During release candidacy this will have to pass on the Target Release Set

Has the End-User documentation been updated to reflect the change?

Has the feature been internationalized?

Release Candidacy

Does Marketing have an interest in this feature?

The branch is tagged at the end of this phase by the team and this tag is passed to the Release Manager.

Sample checklists — Release Management

Basic Questions

Has the responsible Team signed off on all their accountabilities?

Does the feature pass with the Target Release Set?

Does Marketing support the inclusion of this feature?

(usually a given, though sometimes there may be a reason to focus a subsequent release around a feature that is already ready).

Sample checklists — Marketing

Basic Questions

Is there a story around the release?

Have PR channels been informed about the upcoming feature set and the story behind it?

Has the public facing website been prepared to reflect the new release?

Are there key products that are not a part of the core offering that should be featured as part of the release story?

Feature Lifecycle (Step 3)

Step 3 of the feature life cycle was pretty vague. "Begin Tracking and Analysis". What's meant here is that after the Basic Questions have been answered about the feature its time to begin tracking the feature. In many systems this would mean we have enough of a plan in place to put it on a calendar but this is not the intention of the this step. We want to make sure that a feature which has answered the basic questions to the satisfaction of the team has the benefit of a bit of project management and structure available to it. At this point we have indicated which teams we think are affected by a change and its time to notify them that there is a feature in the works that requires their attention. This means that before the bulk of work is done by the development or UI teams the Release Manager and the Marketing Agent are notified so they can begin to plan around it.

There is a lot here and I am sure my plan is not ideal but I hope its a valid starting point and will generate some discussion. I could go on and on about this stuff but I'd rather hear people impressions on this.