Re: Description of tasks (was: -= PROPOSAL =- Release sarge with amd64)
On Wed, Jul 14, 2004 at 11:29:06AM +0200, martin f krafft wrote:
> We just discussed this stuff on #d-d yesterday and one thing that
> popped to my mind is that it's not easy to replace an officer (or
> someone with a role) just like that. Disappointing someone makes no
> sense without a replacement. The problem I see is twofold: on the
> one hand, a lot of people bitch and whine, but very few are actually
> willing to step up and take responsibility. And even if someone
> would like to apply for a role position, s/he is going to have
> a real hard time to judge the extent of the commitment required
> because the jobs are sparsely (if at all) documented.
And: current officers tend to not let other people in to do their work.
If those make a secret out of their job, it's really unlikely that others
can take over their jobs - and thus making it easy to argue: "hey, there's
simply noone else that can make my job!"
Let me use an old example (just as an example, not as a base for a new
discussion):
Administrating a buildd is surely somewhat that sounds complex and difficult
to many people. Setting up a buildd and all the stuff is not something that
average Joe User can do.
But that doesn't mean that other people can't learn how to do this.
When I started with my m68k buildd, even some porters didn't really know how
to setup a buildd. We had to ask Roman Hodek for details. But we (i.e. m68k
porters) have learned and shared that knowledge, which led to a broad number
of m68k buildd admins, giving a redundancy not only in buildd machines but
as well in buildd admins.
Some other ports decided to go a different way and to act with single buildd
admins. There are known problems with this.
Conclusion:
Either you can share your knowledge and broaden your workload to many
shoulders or you can act on your own and make a secret out of your business
and a single point of failure out of yourself.
> As an example, we were (hypothetically) discussing Manoj's exit from
> the project, and I would become secretary. Let's furthermore assume
> that I would be willing to be secretary and am responsible enough
> and give my best, then my decision to apply for secretary is still
> unfounded because I never read a "job description" and thus do not
> know how much time/effort/skill is required. Plus, once I would have
> replaced Manoj (let's assume against his will), I'd have to learn
> all the facets of the job, probably without his assistance. And that
> would take a while and I'd potentially harm the project until I get
> up to speed.
And you could harm the project when you're loaded with real life work, so
you can't do your Debian work as much as you should do.
> My point is that I think there should be documents describing the
> role positions and their exact extents. Moreover, the keepers of
> role positions should be persuaded to extend these job descriptions
> with all kinds of resources they have accumulated during their
> terms. Such a document must be able to convey the extent of the job
> and allow someone with enthusiasm and time to get up to speed in
> short time.
And not only job/task descriptions! There has to be manuals describing
regular problems and how to solve them!
Or do you (as a system administrator) go on holiday without leaving
instructions how to deal with problems that might occur?
> Only with such document will Debian have a true democracy. Up till
> then, it's closer to a meritocracy (I had to look that up) because
> those with roles have built up inertia and can only be replaced with
> great difficulties. And in case of an accident, the position may be
> very difficult to take over, potentially causing serious harm.
Yeah, an accident can happen to everyone. What is the emergency plan, when
something like that would happen to some important role persons in Debian?
--
Ciao... //
Ingo \X/
Reply to: