On 2/2/08, Jan Bilek <clonolu@...> wrote:
> On Thu, 2008-01-31 at 10:24 -0800, Chris Gianelloni wrote:
> > OK, I'm starting a new thread here to try to discuss some things the
> > trustees can do to improve both visibility and also attempt to
> > ensure/promote progress within the Foundation. Please chime in with
> > your own ideas.
> > - Regular meetings - The trustees should have a regular monthly meeting
> > to discuss progress, preferably the first week of the month (for GMN).
> > - Regular GMN section - I think that both the Council and the trustees
> > should have a section each for summaries of their latest meetings. This
> > should relay information about what is happening to the developer pool
> > and the community, in general.
> > - Named positions - I also think that specifically putting certain
> > people into certain positions would possibly improve getting things
> > done. For each position, there should be an alternate, so that we don't
> > end up relying on a single person. This also breaks up the
> > responsibilities a bit so that the trustees and the community know what
> > responsibilities that each person should be working. Positions that I
> > see that could/should be filled: President, Secretary, Treasurer
> > Those are my initial ideas. Comments?
> I am not a developer, just user, but I hope I can dare to express my
> opinion - I read these nice ideas about improving communication
> between developers and users and I think it's also up to us - users...
> so I am trying.
> I have grown up in a centrally planned economy and it was all about
> regular meetings, summaries and named positions - those were used as
> tools to improve things and they almost never worked as expected.
> For example these regular meetings you propose - if there is an issue
> to talk about why wait until the regular meeting is held? Are there no
> efficient and easy to use channels to communicate immediately? If
> there is no issue to talk about - regular meeting would be just a
> waste of time.
Meetings are for decisions. Decision making is poor on a mailing list
and it is not a great idea to make decisions by oneself in a vacuum.
Meetings should have topics ahead of time and the people in the
meeting should have done their homework on those topics prior to the
meeting. Otherwise the meeting is pointless; as you have no doubt
noticed when a meeting is run poorly.
> These institutional things make everything less efficient - and BTW -
> they tend to get sooo boring and meaningless... The more non-formal,
> immediate and 'not institutionalized' communication - the better.
> In (obviously not just) my opinion the problem is that Gentoo has
> become too political, too rigid, too bureaucratic and institutional -
> and it seems to me that maybe you don't realize (maybe you have not
> attended as many regular meetings as I have;-)) that you want to fix
> things by making Gentoo even more bureaucratic, more institutional,
> less flexible.
Where? Be specific in pointing out where you think policy/regidness
is holding back development.
> I think the solution is to go the exact opposite way - to make
> structural changes and use technical tools (as Daniel Robbins wrote
> about it) that would allow Gentoo to become more decentralized,
> flexible, less formal, less political. Disassembling the cathedral a
> Competition of smaller projects led by developers who talk when they
> need to instead of cathedral led by official institutions going
> through official (and less and less efficient) ways. Smaller teams who
> communicate on daily basis so they don't need summaries and reports.
I think we have more of this than you know; it's just not visible. If
dozens of small teams are talking you only know about it when you are
on the dozens of teams. This has always been the case (I used to try
to be that guy who was on the majority of teams and tried to
co-ordinate with many of them; it's a tough job).
> Allowing and promoting funny competition between smaller teams instead
> of demotivating (because unsolvable) fights inside huge teams frozen
> in official ways of doing things. I have seen many developers leaving
> Gentoo because of fights - is it necessary? There should be some way
> to use the conflict for Gentoo's sake and developers' fun instead of
> never-ending discussions with only one solution - less patient side of
> a dispute leaves Gentoo.
> Discussions are good but sometimes when there is too much of a need to
> discuss things this tells us that there is something wrong and there
> is a need for structural change. I think Gentoo needs mechanism for
> teams to split up much more easily - I mean... lets let the work do
> the talking - if there is a disagreement in a team they should be able
> to split up easily and compete - the better technical solution wins
> and gets to the official tree - that's IMO more efficient and more fun
> way than discussions. I have some kind of micro-forks inside Gentoo on
> mind - I think that is what Gentoo should support as much as possible
> and Gentoo's infrastructure should be tailored to support it.
You can't fork every disagreement; at which point does a disagreement
become important enough for a fork? Why are individuals so stubborn
that they cannot compromise? Also, better technical solutions don't
always win, with Gentoo and in the world at large. Certainly we could
attempt to change this internally; but I wonder if everyone would
enjoy the costs.
Our 'infrastructure' if I take your meaning properly is limited in
scope. We can't have tons of rsync trees with gentoo-x86 checkouts
because we don't have the resources to do so. That is part of why
overlays.gentoo.org and gentooexperimental.org exist. If you are
proposing that Gentoo try to do these things I would suggest talking
to the Infrastructure folks about it.
> To find the mechanism that would allow to maintain functionality of
> Gentoo as whole, solve compatibility issues etc. without too much of a
> huge organization that needs more and more energy to keep itself
> going... writing summaries and attending meetings while there is less
> and less time left to do the actual work - that is the problem.
> Thanx for your time reading this.
Thanks for writing.
> Jan Bilek.
> firstname.lastname@example.org mailing list
email@example.com mailing list