Re: RFD: herding cats (long reply)

[Fabrizio Polacco <fpolacco@icenet.fi>]

Manoj Srivastava wrote:
> 
>         This is quite complicated. And probably would not solve the
>  problem of the discussion never coming to fruition.

It is a complicated way to handle a group of mailing list. It is also a
way to handle an organization using existing tools and simple rules.

I remember when Bruce announced that every developer was welcome to
build his own debian- mailing list(s).  I think that Bruce's idea was an
attempt to reduce traffic and futile discussions, correct me if I'm
wrong.
We had a few lists now and they are quite dead.
I have only 22 messages archived in debian-admintool, and discussions
continue on debian-devel and debian-private. The same applyes to
debian-i18n. Debian-publicity has more messages (103 on my archive) but
20% are crossposted to debian-devel.

The original idea was good, but we didn't follow it (maybe we fear to
lose audience?). So we need some simple to enforce this.


>  1) Who decides when a thread should become a mailing list?

Like is now: who wants can create one. If we are scared of the idea we
can enforce the need for a request from a small (2 or 3) group of
developers.

>  2) I don't quite like the idea of adding me to mailing lists on a
>     routine basis, and putting the burden of unsubscribing on to
>     *every* developer.

Yes, you are right, it is very harsh (and maybe breaks netiquette).
It would be more and more better if we had a way to sort out threads of
mail on the base of some keywords.
But there isn't one. People has even difficulty on following a thread
using normal mailers.
So you imagine if we add a keyword to the list name:
debian-devel+keyword
procmail can put all mesages on a single folder (like it is now) or you
can create a recipe to divide the messages into different folders. I
know it is possible to have procmail automatically create a new folder
when a new mailing list appears (even if I don't know how).
The unsubscribe possibility is a "feature", something that we actually
don't have: now you have to receive ALL the messages from the list.

see it in this way: 
a thread born on debian-devel (and you receive all those messages);
after 10 messages people create a list for that thread; all are
automatically subscribed and all continue to receive the subsequent
messages;
people who are not interested in the thread can now unsubscribe and they
will never be annoyed with that discussion.

If that list was created with an empty list of subcribers, only few
people would subscribe to it, and those that archive messages for later
reading will lose everything. This is the reason of crosspostings and
move back of thread to the main list.

>  3) I, for one, have to take special action to enable reciept of
>     mailing lists (any new ones would be junked by my mail software; I
>     could change that, but that has other problems).

I haven't thought about that: could a fixed prefix on the mailing list
names help to solve it?

>  4) I probably won't read read only lists; If I can't contribute, why
>     bother?

Yes; here unsubscribing come helpful.

>  5) Often, peoples contributions are not part of a pre-planned grand
>     scheme focussing their talents, some times, things strike a chord,
>     and you put in your piece, make contributing harder and you loose
>     the spontaneity

Good point. Maybe read-only lists could be left as last resort.

>  6) Why are we setting a limit on the number of lists one can belong
>     to? what problem does this solve? have you noticed any problems
>     with people not being focussed?

It was a possibility for tuning. Keep that limit high (10 or 20) and
lower it when you see big crowd on few lists and desert on the others
(you certainly don't want 100 people discussing every key in dselect
when none is discussing other problems)

>  7) Who does summaries in these lists anyway?

Each list must choose a coordinator. He should summarize, or the list
can choose another volunteer to do this, if it is the case.

>  8) Who decides competence? Seniority? So, if Linus joined us, being a
>     new member he would have to be excluded from the ``super duper
>     secret senior lists''?

This was an extreme case: I remember Lars said that pgp can't be left to
the first saying "I'll do it". Who is maintaining pgp now?

>  9) 100 million lemming *can* be wrong -- voting is perhaps not the
>     best paradigm in a technical discussion. (I definitely would not
>     want to give the unwashed masses FIAT power).

I didn't say that. I said to give FIAT power to the group of
coordinators, each one is choosed by one list. 
This is not an unwashed mass, and it is not an elite like the BoD.

> 10) This is too draconian a regime, and may well mitigate against
>     motivation to participate in the project.

I see the best of us are disappearing. Isn't our continous discussion
without result the reason for that?
Lars made good proposals for QA and even voluteered for that.
Then he left. What are we doing now in that direction?

I've seen progress in a discussion only after someone has been put in
charge for that job. Choosing a simple way to let the developers decide
who is to be put in charge is not more draconian than now.

> 
>         I hope we can solve the problem of ``leadership'' -- which we
>  don't need as much as we do moderators -- by something which has less
>  bureaucracy and restrictions.

We will not solve our problems changing leader. We should put more
decisions (and conseguent responsibilities) in the hands of the
developers, collectively speaking.

> No offence meant.

Surely not. I hope I wasn't too harsh in my reply (it's 2 a.m. :-(  )


fabrizio
-- 
+----------------------------------------------------------------------+
| fpolacco@icenet.fi  fpolacco@debian.org  -  Using Debian GNU/Linux ! |
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E |
> Dog meat? Don't worry, Gwendolen, I'm on my way! [Wallace]           |
+----------------------------------------------------------------------+