Matthew Palmer <mpalmer@debian.org> writes:
> My idea is to break the main sections of the report (P&P, T&S) down further
> into "core competencies". For the procedures section, for instance, I've
> gone through my template questions and roughly classified them by what I
> think they're trying to test the applicant on. I've come up with:
>
> * Care and Feeding of the BTS
ACK, it's easy to do it: Ask the applicant to do a but of bug triage on
a package he likes and ask for a CC in all mails. You can create simple
logs of the process by providing an mbox of all these mails. It also
shows how applicants work with bug submitters, users and other
developers.
> * Maintainer uploads
This is already included in the usual T&S.
> * NMUs
Also covered by T&S nowadays.
> * General Packaging practices (config files; custom permissions)
That's difficult to test and it's probably easier to keep this part as
questions.
> * QA
Easy to test: Let the applicant prepare a QA upload for an orphaned
package and sponsor it :) You could also use this part to talk about
wnpp, removal requests and other QA-related stuff (not as "what would
you do if ..." question, but by pointing the applicant to a problematic
bug/package).
> * Security of the project (GPG, security fixes)
>
> * A misc section (translations, mailing lists, developers' phone numbers)
Once again, this is something not easily checked by tasks, so it's
probably better to keep some of the current questions.
I'm leaning towards a mix of tasks and questions at the moment: A big
part of the current templates could be replaced by checking how the
applicant solves a real problem, but some parts (Security issues,
GPG/Web of trust, leaving the project, knowledge about the existence of
sub-policies, ...) are IMO better covered by questions.
Marc
--
Fachbegriffe der Informatik - Einfach erklärt
54: Jetzt mit neuem, umfangreichem Softwarepaket.
Treiber liegt bei. (Kristian Köhntopp)
Attachment:
pgpCzFF1NTz0e.pgp
Description: PGP signature