Re: Debian as a social group and how to develop it better
I know I have a twisted mind.
On Wed, 27 Nov 2002 00:57:59 +0100,
Andreas Schuldei <andreas@schuldei.org> wrote:
> I have been reading books about group development and would like
> to share the thoughts about appling this to debian.
I don't know the books you are talking about, but I think they are
for a worldlier group where you have to come face to face with
babbling idiots every day. Fortunately, most of the Debian members
are isolated physically from others. You are free to ignore any or
all of them if you don't like them. This is out advantage.
You read debian-devel, you know the overhead of communication,
why do you bother about a society? Debian is based on a
one-maintainer-per-one-package system. Usually you don't have to
contact other developers when you work on your package.
How Debian should be is discussed on debian-devel many times.
All the threads can be boiled down to "hack and slash".
For example: "when will woody be released?" "when it's ready,
fix RC bugs."
> Debian seemed to have elected mostly technical persons as their
> DPL, with the result that their success to innovate and
> reach their goals was limited.
We are volunteers. Debian doesn't need to invent an extra goal
and force its members to work on it.
> In other areas delegates of the
> DPL try to let no one interfere with their area of competence,
> while they, as leaders themself, would be wise to find others
> interested in their center of competence and in turn educate,
> train and empower them. (here the keyring management comes to my
> mind)
I don'y know Debian has an infrastructure for multiple _active_ DAMs.
All the problems about simultaneous write accesses to a database
will occur. I wonder why AMs are not (or can't be) also DAMs, but
it is another issue.
In my opinion, training future DAMs is a part of the graceful retirement.
(Don't quote the Developer's Reference. I read it.) It seems that
the point of the training is "read the source code, you have it".
> During the NM process the understanding of the social contract
> and the GNU part of Debian is checked for. it is hard, but not
> impossible to check for the actual enthusiasm of people. What
> debian has not managed well in my point of view is keep
> enthusiasm alive or newly create it. You can see that in the
> large number of people who became Debain developers and dropped
> out over time. some Debian longtimers are beginning to show signs
> of burn-out. the technical commitee is one example. If someone
> quits and says: "i have not enough time for debian anymore" he
> actually is stating that the priority which he gives debian is no
> longer high enough and that he is not excited about it anymore.
Just out of curiosity, is there anyone who wants to join
the technical commitee?
> Debian has great tools, a great infrastucture, the policy, which
> structures the packages, the constitution, which determines the
> democratic processes, and the cabal, which determines what
> happens. (c:
Since Debian is a technical organization, you need some knowledge to
determine what happens. The cabal members are those who know the source
code of the core software of Debian (dpkg, apt, libc, dak, debbugs,
the voting machine, and so on). You can join the cabal by reading it.
It is like reading the Necronomicon --- it gives you an arcane power,
but it is a hard experience, and you are risking your sanity.
> Recent discussions about gentoo seem to indicate
> that younger distros with less restictions are more attractive to
> some people then debian is.
All I heard are about optimization.
> to me it appears to be really
> two-fold: the democratic process in debian is having a hard time
> to reach valid, usefull decisions due to flamewars and the shere
> mass of developers which need to participate. The information
> flow within the project has a high noise rate and for people
> from the outside it takes a long time to understand how things
> work and who is who. It is time consuming and tiring to follow
> discussion on debian-devel. Structures like DWN, communication on
> IRC and other, more specialized mailing lists like help here but
> more are needed. On the other hand is the technical structure
> with the builddeamons, the security build queue, policy etc a
> indication of technical excellence from which others could learn
> a lot. (c:
Working code is a lethal weapon. Fire it on debian-devel.
Your code may fail to get into the next release, but at least
you can win the flamewar.
> In debian i the general tone of conduct in the mailinglists is
> very mixed. It is far better then in certain other porjects,
> where a very much "down upon others" attitude generate a very
> defensive and fearfull atmosphere. Still there are people (B.R.,
> C.S.) whoes CapsLock key seems to be stuck and who seem to have
> unlimited creativity to find new personal insults for everone and
> their dog.
Never mind, they are developing a fortune file.
--
Oohara Yuuma <oohara@libra.interq.or.jp>
Debian developer
PGP key (key ID F464A695) http://www.interq.or.jp/libra/oohara/pub-key.txt
Key fingerprint = 6142 8D07 9C5B 159B C170 1F4A 40D6 F42E F464 A695
smile to answer
--- Treasure, "Radiant Silvergun", attitude #3 for SBS-130
Reply to: