FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 04-26-2008, 05:43 PM
Toshio Kuratomi
 
Default FESCO

Thorsten Leemhuis wrote:

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.

<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.


However, see below for a larger, more general discussion.

[snip]


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).

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?)


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.)


or

should 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

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 
Old 04-29-2008, 06:14 AM
Thorsten Leemhuis
 
Default FESCO

Sorry for the late reply.

On 26.04.2008 19:43, Toshio Kuratomi wrote:

Thorsten Leemhuis wrote:

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.
<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.


+1


[...]

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).
I can't honestly say whether this was better in the Extras days (looking
back on things is always subject to idealization)


Hehe, much agreed to the "looking back..." part :-))

But for Extras I really think it was a whole lot better then and got
that feeling backed a bit in the private discussion among some German
contributers and I doubt that all of those had the "looking
back..."-syndrome.

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.


If you want my 2 cent: the big problem afaics is that most FESCo members
are quite busy with real-life and to many other work for Fedora. That
not meant as a attack or complain -- as I mentioned earlier, it's a
whole lot of more work these days and often things just happen somehow
(like in this case).

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.)


The problem for me are all those little details that seem to be wrong
and that one runs into walls/bureaucracy way to often.

Do you remember the old RHL and Fedora Core days before the merge?
Sometimes Fedora.us or Fedora Extras noticed problems in RHL or Fedora
and we tried to work together with RH-people to change that. Often that
worked quite well, but often it was a hard and frustrating fight that
the community contributers sometimes lost. RH or RH-people back then
were often blamed.

From my point of view we act similar now. IOW: dealing with all the
committees sometimes feels to me like dealing with RH or RH-people in
the old days. Just that community contributers like you and I were or
are part of the whole organization, so we can't blame RH alone anymore.

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?)


Hmmm.

/me thinks about that for a moment

Yes, I suspect for some people part of the problem really might be "to
percolate from reports in bugzilla out to a more public venue". That
became a bigger problem as the number of contributers grew a lot.

But for me it's a more a "I have a open ear for your problems; just come
and tell me about it" vs. "I'm looking after you all the time and think
I noticed you have some problems; should we try to solve them together".

FESCo of course has a open ear and will help if problems get reported.
If that wouldn't be the case we would have a big problem.

But I think FESCo should act on it's own, look out for problems and
solve them while in parallel improve things for everyone. For that FESCo
in the Extras days for example maintained the following page to make
sure all ideas are listed somewhere and get get worked if there are some
spare cycles:
http://fedoraproject.org/wiki/Development/Schedule/IdeasContainer
That page is completely outdated and unmaintained these days.

Although that is all still event driven. Perhaps the need is for more
ideas to be started in FESCo?


Like collecting ideas on a page like those mentioned above and picking
some of the things up to get them solved if there are free cycles or if
the problem becomes pressing


Policies, features, new projects started by FESCo to make growth occur?


+1 -- albeit not started and more managed/guided; see below.

The only issue with that is that FESCo
has limited manpower. FESCo itself can't implement all the projects it
could come up with.


Of course. Nobody asked for that. FESCO in fact shouldn't do everything
alone as exactly letting people do things is what's needed; then those
people can grow into the community and some of them might sooner or
later be our next leaders or FESCo/Board members. That how it worked in
the past and that's how many of the community contributers got into FESCo.

But In fact that was was I tried after I left FESCo -- do things for
Fedora without being in FESCo. But it failed when for me. The longs
story short: some FESCo members didn't much participate in the public
discussions I started before handing in a proposal for voting to FESCo;
but when it came to FESCO voting those FESCo members suddenly complained
about some details; so I got back to the drawing board, started another
public discussion and handled in a improved proposal; then different
complains from other members showed up in the next FESCo meeting -- once
again they had not been raised beforehand in the public discussions on
the list; sometimes i even ran into such a loop a four times iirc. That
happened with more than one proposal and was very frustrating and of
course took weeks.

So I said: No thanks, in that case I leave all the work to FESCo.

Being event driven means that someone cares enough
about the issue to work on it outside of FESCo.


There are enough people that care and will work on things if you let
them without frustrating them (see above).

But it does change the
role of FESCo from "movers and shakers" to "arbitrators and judges".

[snip a more detailed description]


It's a mix and that's what is needed, thus there is no chose between "a"
or "b" here. But IMHO the mix was a bit different in the Extras days and
a lot more "arbitrators and judges" then it is now.

In fact I wondering know how much/in which areas we really need
"arbitrators and judges" at all. A lot of good things happen if you just
let people do something without writing down to many rules. And we IMHO
have way to many these days.


Cu
knurd

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
 

Thread Tools




All times are GMT. The time now is 03:47 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org