FCoA [Was: Re: FESCO]

Stephen John Smoogen smooge at gmail.com
Sun Apr 27 20:53:24 UTC 2008


2008/4/27 David Nielsen <gnomeuser at gmail.com>:
>
>
> 2008/4/27 Denis Leroy <denis at poolshark.org>:
>
> >
> > Patrice Dumas wrote:
> >
> > > On Sun, Apr 27, 2008 at 08:55:16AM +0200, Matej Cepl wrote:
> > >
> > > > So, should be there a Fedora Court of Arbitration? ;-) I mean
> seriously, in so huge and disintegrated body as Fedora community is now,
> conflicts are bound to happend, and we may need some semi-official means of
> settling them.
> > > >
> > >
> > > It is already the case. The rule is more or less, bring it to the lists
> > > and then to fesco. But this is costly so having propoer guidelines to
> > > follow like AWOL are better.
> > >
> >
> > Hmm why is it costly ? I've had a few conflicts resolved that way, and in
> a reasonably speedy fashion. I don't think I've ever seen a call for help on
> fedora-devel-list going unanswered...
> >
> > Going over this thread this morning, it read something like this :
> >
> > 13:21 [a]: I quit because of this problem I didn't tell anyone about!
> > 13:23 [b]: It's an outrage! What is FESCo doing ?!?
> > 13:25 [Fesco]: ¿ Qué ?
>
> I think many of the people who have left active contribution life, myself
> included, simply feel overwhelmed with the amount of beaucracy. Why

Bureaucracy occurs as more people join a group. It occurs because
people are not mindless creatures and can not always agree on what
each one wants. Human communication is very lossy at best even when
people speak the same language. Even when people have the best
intentions,  they will have their own interpretations of what is said
and will do things that look to be misaligned. You then add in
bureaucracy to keep that to a minimum (checklists, additional
meetings, re-approval to confirm that things are done as they were
first agreed etc etc.)  When you add in people who do something for
their own 'gain' or their view of whats best, you add in more
bureaucracy to make sure that such corruption is caught and removed.
Bureaucracy grows at best as a n*log(n) of the size of the group...
but in some cases can grow at n^n. At some point every government
structure begins to fall down because you can't grow the checks,
balances, and work-flows (e.g. bureaucracy) to be efficient for the
size of an organization.

There are few "cures" to bureaucracy:
1) Small groups that stay in constant communication with each other.
This usually requires physical communication as humans pick that up
better than reading/listening. Usually after you get over 8-12 people
this begins to fall apart. You can try to scale that by keeping groups
reporting to each other and letting them have open communication, but
then you start adding in various bureaucracy to make sure that group A
didn't misreport (by purpose or accident) which causes breakdowns and
corruption.
2) Big stick rule. Someone has the big stick and anyone who does not
do what the Big Stick wants is hit with it.  Groups can grow a lot
larger when they are being beaten/killed for falling out of line. Of
course at some point you can't hit enough people, so you have to give
out more sticks, and then you have to worry that someone else with a
stick is going to take your spot so you have to keep the 2ndary
beaters in line. At which point you have more bureaucracy.

Various forms of Anarchy or Libertine  is usually only a cure as long
as you don't have people gaming the system. However since humans are
inherently greedy animals... they will start gaming the system for
their benefit (even if they do not think they are) which then causes
people to start banding together to stop that which becomes
bureaucracy and/or big stick rule rather quickly.

> complain, we already feel like we are being forced around by boards and
> commitees who meet and decide the fate for us all and it doesn't really feel
> like they are working for us. It feels very much like we have no influence.
> More beaucracy is not the solution here, I think lessening the effort needed
> to get help and let your voice be heard is. Let us start a Fedora Mentor
> program for new contributors, to guide through the little kinks with a smile
> and so new people have a friendly face to turn to instead of endless wiki
> pages. Right now being a contributor feels a lot like being thrown out of
> the nest by your sponsor and expected to fly, getting reviews done has a
> discouraging nepotistic feel to it, you can have packages sitting around for
> months if you don't know anyone. We need some kind of network here to catch
> these little stumbling blocks that frustrate new developers.
>
> We need to ensure a way to remove the bottlenecks, help explain how to do a
> good review, how to get the information mentioned in those guidelines.
> Everytime we get a contributor who does not master this we simply add to the
> workload of people who do and we add to the backlog of packages that sit in
> the review queue. More contributor might in fact end up being a bad thing.
> Let us foster a culture where it is okay to ask questions and ask for help,
> and make it easy to do so. Encourage developers with many packages to draw
> in new developers, hold their hand as co-maintainers for one of their
> packages and eventually let them own it. This way we would also avoid the
> risk we currently have where if something happens to Hans or he decides to
> switch priorities in life, 200 packages are without an owner overnight.
>

All that is more bureacracy in a different format than is currently
done. Someone (person A) has to check to see that the people are
getting serviced well, that developers do not get overloaded etc.
Someone (person B) has to check that the checks are being done by A
and whoever else because they get overloaded and may not get to all of
them but that leaves people falling through the cracks.


-- 
Stephen J Smoogen. -- CSIRT/Linux System Administrator
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"




More information about the fedora-devel-list mailing list