Re: Reforming the NM process
Marc 'HE' Brockschmidt <he@ftwca.de>
> MJ Ray <mjr@phonecoop.coop> writes:
> > Suggestion: Ask advocates to take on the formative/educational
> > part of the current AM role and prepare a summary in a given
> > format about the applicant. The summary could then be used as
> > the basis for simpler summative testing by an AM, with swift
> > referral back to advocate and applicant with direction, if the
> > AM or FD is not satisfied. The aims are:
> [...]
>
> Sorry, but that sounds like moving the NM checks to the
> advocates. Looking at the general quality of Debian packages, I'd prefer
> to not follow that idea.
No, I am not suggesting advocates do the final checks. I
suggest we ask advocates to show the basic evidence that the
applicant is ready to apply, in a form which helps the AM to do
good checks. This seems a logical continuation of the advice
offered in http://www.debian.org/devel/join/nm-advocate :
"Before advocating a prospective developer, you should check
that they satisfy all things listed on the NM checklist."
If you are finding it a problem that advocates aren't doing this,
make it a MUST, not a should. In the Key Skills assessments
I mentioned before, each student's folder had a cover sheet
which listed the skills and highlights what work shows each
skill. If we want advocates to show they have checked applicant
skills, why not ask them to make a similar list?
I'm amazed by that reply, as I wrote "advocate=tutor,
AM=assessor" in my message. How could I have made it clearer
that the AM is still doing the NM checks, not the advocate?
All the advocate is doing is giving a bit more help to the AM
by preparing the applicant properly.
[return to top of message, reply continues]
> >> 1.2.4 Task-based checks [...]
> > Other qualifications use task-based assessment and yet are still
> > comparable and reviewable. What model did you use for your
> > task-based assessment?
>
> I've asked Russ to do some some standard QA tasks (bug triage, preparing
> a non-maintainer upload) and for the T&S part, Steve Langasek found a
> "little" library transition that needed help. Searching for fitting
> tasks that need to be done isn't that easy, I fear.
So, what model did you use for your task-based assessment?
Were you making it up as you went along?
> >> 1.2.5 More than one AM per applicant [...]
I think we agree this doesn't seem worth the effort.
> >> 1.2.6 Web-based checks [...]
> >> It was proposed to change the NM process to be based on simple HTML
> >> pages with some forms, checking for some things. This makes it quite
> >> easy to "cheat".
> > It's already quite easy to cheat the templates, isn't it?
>
> Actually, no. Copy&Paste is not enough to answer the questions in the
> templates.
I disagree. I wasn't claiming Copy&Paste is enough, but it's
not much more than that.
> > Applicants with fast/free internet connections, local mirrors
> > and so on can do the bookwork needed for the template questions
> > without much pain.
>
> Right, which should ensure that they've read and understood what the
> Debian policy mandates. [...]
How? It's not hard to re-express policy without understanding it.
Sometimes, an AM will spot some Eliza style, but not always.
> >> [...] The current questions also allow to educate NMs in
> >> areas they don't know much about.
> > Should NM itself be a mentoring system, though?
>
> No.
So is the current system's allowance of AMs to educate weak NMs
a feature or a bug? Should AMs return them to their advocate(s)?
> > Does it have the resources to carry that function out properly? Is
> > performing that function delaying admission of ready-to-help DDs?
>
> Yes, because many applicants don't know enough when they apply. We don't
> have clear rules that allow us to reject those early, so they're dragged
> through the process, getting taught what's needed whenever the AM has
> enough time for that.
> That's OK if only a few things are unclear, but when applicants need to
> learn a lot, it becomes a problem.
This is a main thing to fix. How can we fix this, if not by
asking advocates to improve?
> >> 2.1 Multiple advocates [...]
> >
> > Advocates seem pretty useless in the current system. The
> > history in Wallach Allan and Harries suggests it is partly a
> > simple filter and time-delay, while this suggestion seeks to
> > "encourage prospective advocates no to advocate too fast".
>
> Actually, it is a filter, but does not perform this task correctly at
> the moment, because some people advocate too early. The filtering should
> take place, definitely, but the current approach doesn't ensure this.
I return to the suggestion: ask advocates to list the applicant's
experience under relevant headings with links to the evidence.
This should make it more obvious to them whether the applicant
is ready, before they advocate the application.
At present, http://www.debian.org/devel/join/nm-advocate seems
hard to find before you have agreed to advocate someone. Then
you either ignore some "should"s or go back to the applicant
and review/change the agreement.
> > This does not seem a scalable solution for any of the problems
> > outlined so far, makes the time-delay for applicants worse
>
> No. As said in my summary, if an applicant has had close contact with
> only one DD, it's highly probable that it's too early to advocate him.
I had contact with multiple DDs who I think would probably have
advocated me "too early" (especially as I think the advice
to advocates was even vaguer, but sorry if any DD I knew
beforehand feels insulted by the suggestion).
I don't believe DD contact and NM-readiness are correlated
strongly enough for this, so Multiple Advocates will deter new
applications from areas in which debian is weak (geographic or
application areas - yes, there are still some!). Can you show
non-anecdotal data to support the Multiple Advocates idea?
Thanks,
--
MJR/slef
Laux nur mia opinio: vidu http://people.debian.org/~mjr/
Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct
Reply to: