Re: Debian structure

[Fabrizio Polacco <fpolacco@icenet.fi>]

Dale Scheetz wrote:
> 
> On Sat, 8 Mar 1997, Fabrizio Polacco wrote:
> 
> > Don't isolate. Split the development into {groups, teams, lists}
> > then let (ask, push) developers to join more groups (as in their
> > possibilities). This will bring a lot of interchange between groups.
> 
> But this doesn't solve the problem of list volume (I was reminded
> that this was the original problem this discussion was trying to
> solve). We did this with debina-devel already and it really didn't
> solve the problem.

If, speaking of "list volume problem", is meant the absolute number of
messages going to subscribers, then you're right. Cross-postings even
make it worse [1].

But if is meant the difficulty to have a personal priority in reading
messages, depending on subjective concerns, then this difficulty could
be reduced by the "split" solution. Keeping bugs discussion out of
debian-devel halved debian-devel volume (I have 1997 numbers behind):
I download my mail twice a day (circa 300 per day) and I let procmail
sort it out, so I can choose a priority sequence in reading, and leave
some for the weekend without any fear to lose important messages.
The total amount of mail that I read is the same, what changes is the
order in which I read it.

This could be achieved also using tags as already suggested, but the
"split" solution only affects "upstream" organization, and can be
effective even for those using non-threaded MUAs. A smart choose of the
names of the mailing lists, joined with some publicized recipe for
procmail and/or mailagent could even let you re-create the original
all-in-one situation.

A correct use of the Subject is good, but how? We, for example, are no
more discussing Ioannis's proposal, and the Subject doesn't say we are
speaking of mailing lists, so ... is this Subject wrong? I don't know.

> Breaking up devel into devel, changes, and bugs only means that
> I must remain subscribed to all three in order to keep up with what
> is happening. If you successfully divide the lists up and get me on
> one list with others on another that I don't subscribe to, I have
> lost my contact with those folks ideas and comments.

Yes, you have to be subscribed to all lists.
This is why I said that the splitted lists should inherit all
subscribers: the possibility to unsubscribe is a benefit of the
splitting, while the necessity to subscribe would be the reason of the
failure as it was for lists like debian-admintools or debian-i18n. Their
threads are still on debian-devel and even on debian-private! [2]


> I have come to view this group as a "creative anarchy", which at
> the same time, makes it the most interesting group I am involved
> with, as well as being the most challenging and frustrating venue
> currently available.

I don't want to start a discussion about the creativity of anarchy, or
the existance of a non-creative anarchy: political discussions should be
avoided here (maybe on debian-talk?).
The point is if such an "interesting group" is an amalgama of
individualities that must be managed to push in the same direction or a
cooperative group of people that uses consensus as the driving force to
direct his collective effort.

> What myself, and others, have been trying to point out is that
> methods that work to manage complexity in corporate organizations
> don't have much hope of working in this enviornment.

Absolutely agreed. Never thought differently. I even asked to avoid the
use of a terminolgy that could recall the corporate organizations.


> We are going to be forced to be very creative in our solutions.
> Actually, I think that what will ultimately be necessary is;
> responsible behavior be each individual developer, coupled with some,
> reasonable, form of education practices that will help keep us all
> on "the same page".

This is banally true everywhere, even in a military field.


> > > What's in a name? A rose by any other....
> >
> > Agreed; so what's the problem in avoiding a metaphor that let
> > people feel bad?
> >
> No matter what euphamism you use to describe it, if it's a bad idea
> with one name, it's a bad idea no matter what the name is changed to.
> 

I must have missed something ... I thought that with that citation you
were saying that if a solution works there's no reason to change its
name. [but I'm not good in English literature :-( ]


Cheers,
Fabrizio
-- 
[1] I suggest to enforce the policy not to accept cross-postings between
debian lists, or maybe to accept only for the first message of a thread
and not for the replies, and have the software that handles the mailing
lists do that.

[2] The fact that some threads are kept on debian-private even if they
belong to debian-devel is a signal that there is the need for some
"closed" lists, not to keep secret the arguments, but to avoid flaming
and sterile discussions with the users, as happened in the past to the
dselect threads.

+----------------------------------------------------------------------+
| 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]           |
+----------------------------------------------------------------------+