The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian structure

On Sat, 8 Mar 1997, Fabrizio Polacco wrote:

> Dale Scheetz wrote:
> > 
> > Dividing up into smaller groups certainly helps management keep
> > control, but it tends to kill the creativity of cross polination
> > and certainly blocks communication between groups.
> > Isolating segments of the system from each other (at the developer
> > level) only adds to the potential for "poor interactions" between
> > packages of different groups.
> 
> 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.
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. 
This attempt hasn't been productive in the past, and I don't expect it to
be very helpful in the future.
What would help? Well, as with any "real" solution, this one requires
every individual in the group to monitor his/her behavior. The major
problems I have with the list is that "threads" continue with the same
title long after the conversation has drifted into another topic all
together. If folks would just make sure that the subject line reflects the
actual content of the posting, then keeping track of those threads that
concern you becomes a much simpler task.

> 
> Your example could have been different if half (one third, one fourth)
> of the people were in BOTH groups!
> 
> > There has to be a better way of managing anarchy than divide and
> > conquer.
> 
> Divide and conquer is a way to manage complexity, not anarchy (which
> couldn't be managed by definition).
> 
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. 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. 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".

> 
> > 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.

Luck,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

------------ If you don't see what you want, just ask --------------