how to govern and manage the new combined repository

[Bill Nottingham]

Thorsten Leemhuis (fedora at leemhuis.info) said: 
> That's probably a good idea, but that needs a bit of preparation, too.
> Thus (and because a board members ask me to) I sat down and will roughly
> outline my thoughts on the issue with this mail. I don't want to start
> yet another endless discussion with this mail/proposal (I know, I'm good
> with that, but I'm not proud of it) -- rather I'd like to see similar
> mails/proposals from other people where they describe how this whole
> thing should be governed.

OK, here's a proposal. Not sure it will match up to yours well... :)

Governance in the post Core/Extras world

Q: What are we trying to accomplish?

A: To enable people to do Cool Stuff with Fedora. To enable people
   to make Fedora better.

Q: How do we best accomplish this?

A: Empower people, and get out of their way.

So, what sort of structure should we have to enact this?

On top is the Fedora board - the directing organization, the big
picture thinkers, and the resolution point of last resort.

Under them are various subprojects - we have the infrastructure
project, the docs project, etc. So, what new structures do we
*need*?

1) Fedora Packaging Project (or committee, or what have you)

Charter:
- set packaging standards
- set packager standards
- enforce those standards
- encourage new contributors/contributions

Structure? I'm of the opinion that it doesn't really matter - find
people willing to do the work, *and do it*. But I could certainly
see how the current FESCo model can work here, especially since
FESCo handles most (if not all) of these areas.

2) Fedora Release Team

Charter:
- defines the schedule
- defines the feature list (?)
- enforces the freezes
- spins such releases that we see fit (pushes the button, pushes
  to site, etc.)

Structure? One lead, and a team of people. Frankly, election seems to
be the decidedly wrong way of staffing this.

Both of these 'report' to the board, if you're drawing a chart.

That's *all* that I think we need that doesn't exist now. Sure, there are
more groups, but those are all existing now, whether they be SIGs (KDE,
Games), random people (LiveCD), projects with leaders and a group of
contributors (Art, QA, Security). I think trying to mandate specific
structures or forms for these groups isn't the best plan for now - just
leave it simple, and up to *these groups* how they organize. 

Bill