AM best practices
As I mentioned in another posting, Marc Brockschmidt and Brian Nelson
recently joined the Front Desk. We just had a discussion about how to
give feedback to applicants as the Front Desk when an AM report is
submitted. But then the discussion drifted and we talked about how
AMs should give feedback to their applicants. I think it's beneficial
to move the discussion to this list. Maybe we can talk a bit about AM
"best practices".
The discussion we had so far is included below:
From: Marc 'HE' Brockschmidt <he@debian.org>
To: new-maintainer@debian.org
Date: Thu, 13 Jan 2005 16:37:33 +0100
Martin Michlmayr <tbm@cyrius.com> writes:
[...]
> I spotted this too. I'd personally just give the answer (i.e. a
> clarification). (*)
I hate to just explain something to my applicants. Either i write a few
words about it, not covering everything that i deem important or I write
a long text which most people will not really read. Asking further
questions is a hassle, but it forces the applicant to read, understand
and reproduce documentation.
[(*)Note that I was talking about Front Desk clarifications which are
different to those made by AMs; in general, AMs should have dealt with the
biggest problems already and so FD usually only needs to make minor
clarifications or additions. Anyway, the discussion moved from FD
feedback to how to act as AM -- tbm]
Marc
----------------------------------------------------------------------------
From: Brian Nelson <pyro@debian.org>
To: new-maintainer@debian.org
Date: Sun, 16 Jan 2005 00:49:37 -0800
On Thu, Jan 13, 2005 at 04:37:33PM +0100, Marc 'HE' Brockschmidt wrote:
> I hate to just explain something to my applicants.
Interesting. I'm pretty much the opposite--usually I'm quite willing to
explain something to an NM without much prodding. For really basic
stuff, I'll force the NM to give an answer. However, if an answer is
correct but a little incomplete, I'll generally provide the rest of the
answer for them.
> Either i write a few words about it, not covering everything that i
> deem important or I write a long text which most people will not
> really read. Asking further questions is a hassle, but it forces the
> applicant to read, understand and reproduce documentation.
Indeed. However, it provides no proof the NM can *apply* that which he
just learned, and that is the most important part to me. I figure
anyone can search the documentation long enough to find any of the
answers--some even quote it directly without even changing a word, which
is obviously of little value.
So, instead of basing my evaluation of an applicant on the quality of
the answers, I consider the P&P and T&S questions more of a learning
session than a test that must be passed. Then, for the 2nd part of T&S,
I'll check as best I can the NM is applying everything he or she should
have learned from the tests in the packages or whatever.
This approach makes it difficult for me to approve NMs that provide
little evidence for me (e.g. they maintain a single obscure package and
have only ever made one upload). Those are really borderline candidates
anyway, IMO. On the other hand, it allows me to easily approve NMs who
may have struggled with some of the questions, but eventually proved
eager to learn and readily able to apply that knowledge. These are,
IMO, potentially some of the most valuable developers to have.
On a related note, I always try to track down every developer an NM has
worked with to provide a statement like that provided by the advocate.
I find this can be very useful since it's pretty common (unfortunately)
for an advocate to not know a candidate very well and give very
superficial information. Also, it's a nice way to show an NM works well
with other developers. I find it makes my decision to accept an NM much
easier if several other developers have vouched for the NM's quality of
work, personality, etc. Hopefully, it would also make the DAM's
decision easier as well.
>From the reports I've seen submitted in the short amount of time I've
been receiving FD mails, it looks like other AMs don't do this. Perhaps
it would be a good idea to push AMs for this sort of thing?
----------------------------------------------------------------------------
From: Marc 'HE' Brockschmidt <he@debian.org>
To: new-maintainer@debian.org
Date: Sun, 16 Jan 2005 13:05:06 +0100
Brian Nelson <pyro@debian.org> writes:
> On Thu, Jan 13, 2005 at 04:37:33PM +0100, Marc 'HE' Brockschmidt wrote:
>> Either i write a few words about it, not covering everything that i
>> deem important or I write a long text which most people will not
>> really read. Asking further questions is a hassle, but it forces the
>> applicant to read, understand and reproduce documentation.
> Indeed. However, it provides no proof the NM can *apply* that which he
> just learned, and that is the most important part to me.
There's a better chance that he actually has learned something, IMO.
> I figure anyone can search the documentation long enough to find any
> of the answers--some even quote it directly without even changing a
> word, which is obviously of little value.
... and i don't accept it, normally. If it's a complicated issue, i ask
further questions that cannot be answered by the documentation, so they
simply need to understand it to answer the question.
[...Asking DDs about an applicant...]
>>From the reports I've seen submitted in the short amount of time I've
> been receiving FD mails, it looks like other AMs don't do this. Perhaps
> it would be a good idea to push AMs for this sort of thing?
I do this in most cases, but don't add this to my AM report. But you're
right, it would make the process easier for the FD and DAM. Perhaps we
should update tbm's guidelines for AM reports and post it to
debian-newmaint@l.d.o.
Marc
----------------------------------------------------------------------------
From: Martin Michlmayr <tbm@cyrius.com>
To: Brian Nelson <pyro@debian.org>
Date: Sun, 16 Jan 2005 20:14:33 +0000
* Brian Nelson <pyro@debian.org> [2005-01-16 00:49]:
> > I hate to just explain something to my applicants.
>
> Interesting. I'm pretty much the opposite--usually I'm quite willing to
> explain something to an NM without much prodding. For really basic
> stuff, I'll force the NM to give an answer. However, if an answer is
> correct but a little incomplete, I'll generally provide the rest of the
> answer for them.
I'm not sure whether what you two do is actually so far apart. From
what I remember, HE doesn't just say "no, go back and read the docs"
(although I might remember incorrectly). I think the AM should not
just give the whole answer if the NM doesn't know, but I also think
the AM should give some hints what is wrong or where to look. Just a
"read the docs" isn't helpful imho, but some AMs do that.
And in some cases, when the answer is almost correct, I think it's
okay to just add minor clarifications. To take an example, the
questions about tags and how they impact the release status. If they
mention sarge-ignore but nothing else, then I'd tell them that there
are other tags and they should find out and get back. But if they
list a couple of tags but forget some minor ones, I'd just say "that's
right, but you missed foo which can also have an impact because ...".
Anyway, I think this discussion does raise a few interesting questions
and I think we should forward it to -newmaint. If you don't mind
being cited, I'll put the mails together to something we can cite and
then publish it. Then we can have an open discussion about best AM
practices.
--
Martin Michlmayr
http://www.cyrius.com/
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: