Re: Ignoring the truth or Hiding problems?
Wouter Verhelst <wouter@debian.org> writes:
> Op zo, 19-12-2004 te 18:48 +0100, schreef Goswin von Brederlow:
>> Tollef Fog Heen <tfheen@err.no> writes:
>> > Your other ideas about time-limiting positions is wrong. I am not
>> > able to name a single person in Debian I'd rather have as DAM than
>> > James. He might have much to do and be slow in his duties, but what's
>> > more important is the trust he has. The other people who might have
>> > the same level of trust usually don't want to become DAM.
>>
>> 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).
>
> Actually, we have two DAMs currently: Joey Schulze and James Troup.
> Currently, James is the only one actually processing NM requests
> (because he's got the most experience in doing so), but should he ever
> (touch wood) run under a car or something, then there /are/ people ready
> to take over.
As Joey said himself he won't act as DAM unless James gets run over by
a truck (or looses his laptop with his key on it or such).
Joey is someone that has the permissions to take over and fix things
up, e.g. to allow a new DAM to take control again. I higly doubt Joey
would be a good DAM without letting his other very good work suffer in
the process. Even Joey needs to sleep - sometimes. As to wether he is
ready to take over and able to do it well only Joey and (touch wood)
James run under a car can tell.
>> 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.
>
> ... and a way to ensure that those people with the most experience in
> some job do not get to do it, so that the job isn't done properly.
> Thanks, but no thanks.
Yes, forcing someone to step down every once in a while means someone
inferior could get the job. It also means someone better could get
it. It means more people get the experience and have the chance of
getting/being good at it.
>> Also the time could be limited the following way:
>>
>> - A role position must be elected whenever a volunteer (not the
>> current holder) steps up for election but no sooner than X years after
>> the last.
>
> That's not how Debian works.
Once there wan't a NM-Team, now there is. Things change every once in
a while. This was just a suggestion to be discussed and evaluated not
a statement of facts.
>> PS: Given the inflamatory nature of mentioning DAM in such a thread
>> maybe a different role should be used as example in the future.
>
> This is hardly possible, given the fact that these "we need to improve
> our processes" threads usually are in fact "I don't like James" threads.
The same applies to e.g. Joey. If he would become (active) DAM I would
have the same concerns that his other jobs take too much time (or
suffer due to lack of time). Or if our project Leader decides to be
DAM as well.
Personaly I don't think the DAM position can change because there
doesn't seem to be a suitable replacement for James due to the nature
of the DAM position. That is another reason why I think using DAM is a
bad example.
Yes it is true, I would like James to give up some of his jobs or for
those jobs to (again) become team controled. But the frequency this
comes up again and again and mostly with James as example might just
have something to do with the number of jobs he has.
> What really happens in these threads is that there is a temporary
> problem which is being complained about by some people. Since this is
> about a crucial part of our project, a massive flame war results. A
> month later, some solution is worked out (which is being implemented but
> not sent to -devel or -devel-announce, because doing that is really just
> generating extra noise), and everyone forgets about it -- except for
> those who just don't like James.
Telling at least those involved in the problem could be beneficial.
And not sending a "we fixed it" mail because it creates extra noise is
very counterproductive when one of the recuring problems is that no
feedback is given. The amount of noise of those threads far outways
any "we fixed it" mails.
And all that is easily swallowed by a hot-babe. :)
> The last time this happened (when James was the subject of the flame)
> was around FOSDEM, about 9 months ago. Doesn't that tell you anything?
How about it telling me "nothing changed for the better"?
Or something that was suggested in that same thread 9 month ago:
"maybe the problem is actually James"?
The reason for those flames can and has been interpreted in many way,
obviously always favourbale to the own side and I realy don't want to
go down that road since it is completly unrpoductive.
MfG
Goswin
Reply to: