Thorsten Leemhuis wrote:
<nod>. You touched on this with your note about the Feature Process as well. One possibility is that FESCo should be delegating smooth running processes more. In the features case, the Feature Policy is working pretty well for making features better but there's no reason to couple it so tightly to FESCo. There's a procedure for getting a new feature into Fedora now so FESCo could delegate the review of Features to a subgroup.I think it just happened without purpose; in fact I suppose it's likely that a lot of things might be similar if I would still be in FESCo(²), because FESCo has a whole lot more to do these days. Maybe to much, especially if you want to keep up with FESCo work as spare-time contributer.
However, see below for a larger, more general discussion. [snip]
I can't honestly say whether this was better in the Extras days (looking back on things is always subject to idealization) but it's definitely a worthwhile goal for the future. So part of the question would be how do we reach that goal? I know that many of the FESCo members are on IRC reading conversations of contributors all day everyday. Likewise with fedora-devel. So problems that get mentioned there would nearly always be seen. Is there a failure to push from IRC chatter to official FESCo business? (I recall jwb, tibbs, and nirik, all bringing problems noticed through other channels to FESCo so I personally don't think this is the case.) Is the problem getting issues to percolate from reports in bugzilla out to a more public venue? (Perhaps this is something bug triage would like to take on? Noticing a problem in Guidelines/unresponsive maintainers/etc and querying whether the issue should be mentioned on the mailinglist?)And that is in fact the biggest problem *I* have with FESCo these days. FESCo afaics is mostly event driven these days (triggered by releases or people that poke FESCO to approve or do something); the contact to/interest in the contributers (and their option) was lost/got a lot worse. In the Extras days it IMHO was different -- FESCo then of course had to do some things that were triggered by events as well, but a lot of time was spend in a "how to improve Extras to make it better for users and contributers to keep both groups happy (and make them even happier!)"-mode. For that we were in closer contact with the contributers (their number of course was smaller and thus it was also easier).
Although that is all still event driven. Perhaps the need is for more ideas to be started in FESCo? Policies, features, new projects started by FESCo to make growth occur? The only issue with that is that FESCo has limited manpower. FESCo itself can't implement all the projects it could come up with. Being event driven means that someone cares enough about the issue to work on it outside of FESCo. But it does change the role of FESCo from "movers and shakers" to "arbitrators and judges".
So here's a question -- should FESCo embrace the arbitrators and judges role and we, the project, need to start implementing new outlets for people who want to actually do things? (ie: Feature Process allows developers to get buyin for implementing global distro changes and provides a mechanism for developer work to be communicated to other people in the project who are affected by those changes.)
orshould FESCo concentrate on being the drivers of new changes? Which means, being more involved with creating new policies, new subprojects, etc. This, in turn, means that FESCo would be a much more active body, with less time for arbitration and judgement of current projects. So it should be delegating those responsibilities out while it works on building new communities around new subprojects.
-Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
