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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Thu, 13 Jan 2005 16:37:33 +0100 Martin Michlmayr <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Sun, 16 Jan 2005 13:05:06 +0100 Brian Nelson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Marc ---------------------------------------------------------------------------- From: Martin Michlmayr <[EMAIL PROTECTED]> To: Brian Nelson <[EMAIL PROTECTED]> Date: Sun, 16 Jan 2005 20:14:33 +0000 * Brian Nelson <[EMAIL PROTECTED]> [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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
