[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q for Andreas Schuldei: "Small teams"??

Scripsit andreas@schuldei.org (Andreas Schuldei)
> On Tue, Mar 08, 2005 at 12:13:27PM +0000, Henning Makholm wrote:

> Let me give an example: Right now we have n maintainers having mp3
> players in the archive. They decide to form a group to improve the
> mp3-player situation in Debian. Since they can read mail and some do
> IRC and IM, they decide to use all those available media to
> communicate. They create an Alioth mailing list and a
> #debian-mp3-player channel on irc.debian.org.
> As a result, these mp3 player maintainers perceive Debian as a better
> and more friendly place. They are less likely to leave out of the
> blue. You get the picture, don't you? For more features of small teams
> check my platform.

But if the mp3 mailtainers wanted to do that, couldn't they already do
so? How do they need the blessing of the DPL? If you're not planning
to _require_ anybody to collectivize, how will your being DPL make a
difference in your example?

>> Will anybody ever, in any context, get told: "You will have to route
>> that request through your team leader"?

> I bet that at some point someone will say that to someone. It is not a
> design goal, though.

Perhaps I was being too rhetorically obscure here; apologies. What I
really want to know is what the role of team leaders in the
organization will be? Since you specifically mention that teams should
have leaders, one would infer that there is _some_ design goal in
having them.

>> How large a fraction of their available Debian time will you expect
>> volunteers to spend on "discussing TV-series, politics or football,
>> finding friends or falling in love" instead of on creating a free
>> operating system?

> If I gave you a number of hours per week now, what would you do?

Vote for somebody else, presumably.

> The goal is to feel at home and comfortable, not make forced
> small talk. This will take time, just as any normal group that comes
> together. The more intense you want it to be the more time you need to
> invest.

I get the impression that you want Debian to work like a sort of
extended family, being to us what having a life is to non-geeks.  I'm
not sure I like this. The sneaky marketing about "find friends and
fall in love" or "fun skinny dipping" may well appeal to one's lower
instincts, but I don't think it is a good idea to leave the concept
that Debian is an activity that _takes place in the public space_.
We're creating an operating system that we want businesses and
governments to use. We're deliberately opening ourselves to public
scrutiny, to the point of conducting our most heated and sensitive
internal discussions in public. Whenever I upload a package, I'm not
only contributing work to the Project; I'm publicly staking my
reputation on the software being suitable for use by the royal court
and civil service on the Coconut Islands, even if I couldn't point
them out on a map with a precision better than 10 Mm.

I'm all for people collaborating on their Debian work, pehaps making
friends, perhaps not. If it makes the process more fun and/or
productive, then more power to all of us. However, to have an official
policy promoting the idea that we're just a bunch of online friends
who happen to compile an operating system between ourselves - I'm not
so keen on that. It would make us look closed and sectarian. It would
also tend to detract people from contributing who cannot live up to
the ideals of tightly-knit socializing.

>> Will people who cannot meet your requirements for teams (say, because
>> they prefer to avoid IRC which is a stupendous time sink) be able to
>> contribute to the project in your model?

> Any medium is possible. If it is more interactive it would be
> better. Try Voice over IP or phone if you want.

That would, from my point of view, be even worse. Like many Debian
developers, I am not a native speaker of English, and having to speak
a foreign language over a voice-only medium makes me distinctly

Henning Makholm            "Make it loud, make it complicated, make it long,
                   and make it up if you have to, but it'll work all right."

Reply to: