how to govern and manage the new combined repository

Bill Nottingham notting at redhat.com
Thu Jan 11 18:02:25 UTC 2007


Thorsten Leemhuis (fedora at leemhuis.info) said: 
> > Q: How do we best accomplish this?
> > A: Empower people, and get out of their way.
> 
> Well, your have a point, but I don't agree fully. One reasons for it: A
> clear infrastructure will actually help getting the community involved.
> Otherwise some contributors might say "I did not know where to ask to
> get involved, thus I move along to something else" (see the recent
> discussion about fedora-desktop on fedora-devel -- that shows the
> problem nicely ). That's what I'd like to avoid.

There should be mechanisms for people to contribute, pages on the
wiki, logs, etc. But I don't see what good mandating that you need a
committee, made up of X, Y, or Z does for you. Most of the projects
I know about now (art, the SIGs, QA, Infrastrucute) don't really
fall into this category. Essentially, communities should provide
their own governance.

AFAICT, the fedora-desktop thread was just a bunch of mutual namecalling.
Maybe I missed something in the noise.

Realistically, I want to hear - what are people trying to do that
they can't do now? What are they trying to *ask* about getting
involved?

> > Under them are various subprojects - we have the infrastructure
> > project, the docs project, etc. So, what new structures do we
> > *need*?
> 
> Hear I to disagree. I think it does not work well if we have to much
> projects on the same level if they have to interact a lot (and those two
> your porpose have to interact a lot).
> 
> An reasons for my opinion: the communication and "who does foo" between
> the Packaging Committee and FESCo sometimes sucked (the recent
> "conflicts" issue is a good example). Having something like a FTC
> (Fedora Technical Committee) at the top might help as it can say "Either
> you work out something until X or we do it, as we and/or group 'b' need
> a solution *really soon*".

This implies to me that the packaging committee shouldn't have been
separated from FESCo in the first place - that's why I put it
back together in my proposal. ;)

> > 2) Fedora Release Team
> > 
> > Charter:
> > - defines the schedule
> > - defines the feature list (?)
> > - enforces the freezes
> 
> I think that could lead to problems if this group handles the freezes if
> all the other repo work falls into the area of group "1"

I don't see how it would be that bad - realistically, if people
can't work together, we have problems.

Bill




More information about the advisory-board mailing list