Re: [PATCH] Split of the normal mode

[Vesa Jääskeläinen]

Yoshinori K. Okuji wrote:
> On Sunday 29 March 2009 22:23:11 Vesa Jääskeläinen wrote:
>> Both of those projects has divided work force dedicated to maintain and
>> drive enhancements to defined goals.
>>
>> Now if we map this to our situation:
>>
>> - We are missing what we want to do (eg. roadmap, feature plan)
> 
> This is somehow intentional, because I believe that volunteers do only what 
> they want to do anyway. In fact, the TODO list in the wiki has several high 
> priority items, but they have been pending for a long, long time (e.g. 
> writing a manual).

That item has been in my mind too as people complain that there ain't
one, even the developer one would be useful. But even if there are items
in TODO list, people hesitate what to do about it. Some questions that
could arise: Who do they consult? is my contribution really wanted? Do I
waste my time by doing this? I could be interested in this task, but
there is a "task reservation name" there.

>> So perhaps it would be best to form some kind of organization that
>> defines the goals and then defines responsibilities and backups for
>> components and tries to drive targeting those goals. Those could be like
>> though like internal maintainers for specific components. It could be
>> like bi-monthly meeting to tackle issues on horizon.
> 
> So you like formalism. I myself like a loose development model. If you have 
> many active developers, formalism works better, because they start to 
> conflict and consume most of the time for endless discussions, otherwise. 
> But, people appear and disappear frequently in GRUB. Do you really think it 
> works with GRUB?

Here is another example:

Someone writes a large pile (or even a small change) of code that he/she
would like to get into GRUB. He/she just sends a patch to mailing list
(or to tracker) and feels happy that I have done something now. Even if
there are several developers that could understand the code, they do not
even look at that as it is not within their close interests, or they
might not have time. Or they feel that there is someone else with more
knowledge that should handle this. So no-one really makes any kind of
response as there is no "pressure". Thus time the person has spent doing
something is wasted. This again generates negative publicity...

Another related issue is copyright assignment to FSF that seems to
hinder also some people. But for that we can't really do much.

> Some examples...
> 
> I am involved with GRUB for 10 years, but I sometimes disappear completely 
> for 
> several months. Then, back again.
> 
> I think Pavel is also working on GRUB for nearly as long as me, but he works 
> from time to time. It looks nearly random to me.

Those scenarios also map to myself.

> Robert seems to be relatively constant these days, but he apparently does not 
> have time to comment on all patches.
> 
> So, till now, "Do whatever you want to do when you feel that you want to" has 
> been the most practical, and legwork has been finished by official 
> maintainers who have some formal responsibility (actually, official 
> maintainers have responsibility only for endorsing the GNU philosophy, but 
> they have done more than this).

Right. But if there is no other responsibility for anyone, you cannot
really ask people to follow any kind of design philosophy if there is
no-one watching the progress. If you give free permission to do what
ever you want, then you can pretty much expect that you get what ever
gets there.

I have from time to time though about projects that I have followed,
what has failed those or what could be the problem why there is no real
progress. In my opinion most of those have failed because there is no
real guidance on what to do next. People just do and assume that other
people will do something until they get enough frustrated and make the
necessary change themselves. If this happens, then it certainly does not
feel like fun.

Projects with active leadership/management seem to flourish much better
than on projects that where open sourcing means that here is the code,
do what ever you like with it.

So... to answer your question about formal development, yes, I feel that
it could help here. A bit relaxed model perhaps would be best but there
should always be tasks in horizon that needs to be done. Even some kind
of dependency graph for those could be a good idea to concentrate task
that needs to be done first. If tasks are somewhat defined then it is
easy just to pick one and do that, it also helps on keeping track of the
progress. It needs management but for that I would say that bi-monthly
irc/skype/or whatever meeting would be useful for. Also if there are
some design issues that might need multiple people to decide what to do
(or they might even need a vote or alternative authority override).