Re: Ignoring the truth or Hiding problems?
Tollef Fog Heen <email@example.com> writes:
> * Goswin von Brederlow
> | Do you consider buildd admin a role position? As a rule of thumb I
> | would say role positions are those with role addresses,
> | e.g. firstname.lastname@example.org.
> Why is email@example.com different from firstname.lastname@example.org?
> It's a role address -- it's whoever runs the powerpc buildd, whether
> it be a team, a single person or a really good AI.
As for teams see below. As for archs with only one buildd admin that
should be changed to teams of at least 2 as well as having at least 2
systems if possible. There should always be a backup. This has been a
problem repeatedly in the past in both hardware and human resources.
If you still want to include them in "role positions" then go ahead. I
don't think they should. Whenever a team can be used, and m68k has
shown how good that works, building a team instead of an ellected (or
not elected) position is preferable.
Several positions in debian already made teams or are enlarging them
to cope with the increased workload. The best example for this is
probably the Release Management. There are Release Managers which are
full members of the team and Release Assistans. New members can be
assitants and get trained and gain insight into the job.
The best description of a role position I heart, don't know how said
it to me, is:
A role position is a position where a single person has the control
over a job.
The powerpc buildd has some control over the job of building powerpc
debs. But any DD can build debs so the control is very loose.
> | And what if he dies tomorrow? Debian will be left with no DAM, no past
> | DAM, noone that has the vaguest idea how to handle the
> | job. (overstating to make a point).
> That's bullshit.
> James' laptop was stolen earlier this year, with a backup copy of his
> gpg key on it (left there by oversight). Getting his account closed
> took a couple of hours, and I'm sure we could have gotten it done
> faster if we _really_ needed to. So we have at least one other person
> who knows how to manage accounts (technically) in Debian. For the
> process part of DAM, we have the Front Desk who is intimately familiar
> with how the DAM works and the requirements needed for passing.
That does not mean there is someone with hands-on experience for every
role position that does not currently hold it.
Its like me saying there might be odd numbers and you saying no, 2 and
4 are even.
> | Limiting the time is as much a means to prevent people hogging the
> | position as ensuring new people are trained and old people are
> | available for help.
> You seem to think that getting new people into positions and getting
> old people out of a position is good by itself. I don't think so. I
> think continuity is good and letting people do what they think is fun
> is good.
I think neither of the two is overly good but a mixture of the two. I
also think small productive teams are better than overly large teams
or single persons. It is all a compromise and depends largely on the
job at hand. There is no one way for everything. Having a team as
leader or one person being the ctte would be horrible.
> | If, as you say, nobody want's to be DAM then there wouldn't be an
> | election by those rules.
> I did not say that. I said nobody whom I could possibly want to have
> as a DAM wouldn't want that position. I know a fair amount of people
> who (for some insane reason) wants to become DAM, but I'd like not to
> have them in that position. I'm not saying that this is true for a
> majority of DDs, I'm not saying it's true for _any_ other DD, but it
> is for me.
Some people don't wan't James to be DAM. Every person is entitled to
their own opinion. And while the majority might not want to kick James
out it might decide to try someone else for a while if there were an
> | I would not consider teams to be role positions but being a teams
> | leader I would.
> What about leaderless teams, like ftp-master or the amd64 porting
> team? (Still going by www.d.o/intro/organization)
You must have a different www.debian.org than me.
There is an amd64 porting team? And you consider them as having role
positions? Who is on it? A lot of people I know from the amd64 port
are NMs or not even DDs like me. They certainly can't hold role
I also don't think every position in www.d.o/intro/organization is a
role position nor do I think all role positions are on there. None of
the build related things are on there while other teams are. What
exactly a role position is differs between the people I talked to over
the years but all would include at least leader, secretary and dam.
Maybe role is a bad word. Would core position sound better?
I don't consider being in a team of equals as role positions. If the
team has no leader then it just has no role position it fills. DDs
should be allowed on many teams.
> | In a team there are other people that can take up the slack if a
> | person is overly busy with other jobs. Also people can join the team
> | and do the work instead of the timeless person and defacto replace him
> | at any time. In a team one person does not constitue a bottleneck.
> Having a team does not mean «everybody does everything», it might just
> as well mean _nothing_ can be done if not a majority is present, since
> people do different parts of the job.
It generaly means no one single person can block the team. If there is
such one person then I would call him/her the team leader and I would
call it a role position since the teams power is in the end in one
> | PS: Given the inflamatory nature of mentioning DAM in such a thread
> | maybe a different role should be used as example in the future.
> I think using DAM as an example might be good, since it's one of the
> least thankful, most whined about and loneliest posts we have in
> Debian. I doubt the DAM gets many fan mails about he doing a good
> job, even though some (many, lots, pick an appropriate word) people
> think so.
That might be so and I know for a fact he is doing a very thorough (he
looks very closely) job investigating NMs.
But for every good days work James does as DAM he has to not do
something else. Every time he does some wanna-build work he has to not
be DAM. Every time he is ftp-master he has to stop porting to i386.
Every time he ports something to sparc he can't maintain the debian
keyring. Every time he does something for debian-admin he can't sign
packages for arm. If there is one complaint and excuse that comes up
again and again then it is lack of time.
Maybe elections aren't such a good idea and if many (1/3 would be
enough already) DDs feal like you they will never happen.
Maybe just limiting the number of role positions a DD may hold at the
same time is more agreeable.