Comment 2 for bug 174375

Curtis, the role of "drivers" as currently implemented is the same as
your description of release managers: deciding which issues and features
matter for a particular series / release / milestone.

The general model is that "anybody can propose an issue as RC but only
drivers can confirm the issue as being RC". Ubuntu, being a very large
project, needs a more sophisticated model. But I haven't yet seen a
comprehensive review of how we can structure things so that Ubuntu is
not special cased, but has merely configured the general system in the
way that suits them.

Some of the items in your list of "RM" capabilities look more like
project admin capabilities to me. Ubuntu should just have the RM team
have admin rights if that's what they want.

What's needed now is a more detailed review of the workflows associated
with release management, and the design of a permissions system which is
natural "out of the box" for a typical small project, but which can be
configured to handle a large and sophisticated project, too.

By "natural out of the box" I mean that the person who registers a
project initially can "just do anything", but that over time, as the
project becomes larger and richer, they can delegate responsibilities
and permissions effectively.

For example:

 - should the set of people who can propose bugs / specs to a series be
restricted?
 - should there be controls on which people can set which bug / spec states

In the case of a small project (the default out-of-the-box experience
for a new project) the answer is no, but for a large project like Ubuntu
the answer is yes. Don't special case Ubuntu, use this opportunity to
build a clean, general approach which works in the small case and can be
made to work for Ubuntu too.

Mark