Proactively awarding developer status?

[Dan Streetman]

Personally, I don't think this is something we should do.

First, I don't think we should consider any applications privately,
and even moreso if the application comes from a 3rd party and the
individual being evaluated isn't aware.

Second, I don't think it's appropriate to offer roles with ACL to
people without some first-person application process. The application
process isn't really that hard, and people getting ACL rights should
want those ACL rights, meaning they should apply themselves.

Third, while I agree that restricting 'proactive' granting of
membership for contributing developers is probably fine, since it
carries no ACL rights, that level of membership is essentially only
useful to the applicant - it doesn't benefit the larger community,
only the person it's being given to. So it seems not very useful to
proactively give contributing developer status to someone who never
asked for it - if they cared about having it, they would have applied
for it.

If there's a problem of people failing to get around to applying for
developer status because the process is too onerous and/or
time-consuming, maybe we should consider fixing our process so it's
easier for applicants. Some changes I would suggest are:

1. Default to discussion and voting on the mailing list.
Lack of quorum has been a serious problem for the DMB in the past, and
I can tell you with absolute certainty from personal experience,
having your application bumped for months and months because the DMB
couldn't show up absolutely drains enthusiasm. I don't really see why
we insist that applicants show up for a realtime meeting when we could
handle the entire process by email. We could even have an initial
email vote on whether to handle each application by email or request
the applicant schedule an in-person application. I suspect that many
applications will be perfectly fine to review and vote on over email.
At minimum, I think we should allow applicants to request application
by email.

2. Reduce the application template.
Our template is too big and has too many fields that it doesn't need.
We should drop the "I am applying because" section entirely - it
should be obvious to everyone why people are applying. Many of the
sections like "Things I could do better", "Plans for the future",
"What I like least in Ubuntu", etc are interesting, but not really
relevant to the application process. I feel like they serve mostly to
increase the amount of work that applicants have and thus simply cause
potential candidates to defer their application to "later".

3. Remove or reduce the burden on applicants to find sponsors to endorse them.
I don't mean that their work shouldn't be sponsored already - it
should - but sponsors can be busy and having to pester 3 sponsors to
endorse an application is just another reason for applicants to delay.
I don't have any suggestion to completely remove the difficulty in
getting multiple endorsements, but we could at least change our
wording from "A typical application will have three to five
endorsements" to something like "An application should have at least
one endorsement, though three or more are preferred." As an example,
one of our applicants from just last month had only 2 endorsements,
but we voted unanimously to approve the application.

4. Automate as much of the application as possible.
There should be no reason for us to make applicants gather a list of
all their contributions; we should just put
https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi directly in the
template and have the applicant properly fill in themself as
sponsoree. They only should have to manually list any contributions
that aren't listed in their sponsored uploads, for whatever reason.

For me, the bottom line is really "is this person technically capable
and knowledgeable on specific Ubuntu processes". I get that from their
endorsements (and comments) and from their actual work in sponsored
packages. The rest is really just fluff for me, and if getting rid of
the fluff would help streamline the process and encourage more people
to apply, I'm all for it.


On Fri, Oct 30, 2020 at 9:47 AM Robie Basak <robie.basak at ubuntu.com> wrote:
>
> I'd like to propose/discuss adding an alternative path to getting
> developer status that doesn't involve an explicit application through
> third party nominations. I don't know if this is a good idea or not. I'd
> appreciate feedback from anyone, not just DMB members.
>
> Over the years I've been asked for advice by many people on whether they
> should apply, whether they're ready, whether their application page is
> sufficient, and so on. And I've also dealt with applications where the
> applicant has missed writing up what we're looking for in an application
> but when we do get the information we find that they do actually meet
> our expectations.
>
> Note that all of the above is "red tape". Ultimately we do need
> information to form an opinion. Traditionally that information has been
> gathered through our application process. But different people react
> differently to this red tape. Some applicants are inevitably put off by
> the process itself and do not apply when we would like them to, even
> when we would consider them to be good candidates.
>
> My proposal is this. Start by accepting *third party applications* for
> contributing developer status. We'd expect the same information as in a
> regular contribution developer application, but from a third party and
> privately[1]. We'd consider the application privately, and if we accept
> it, then we'd reach out to the second party and offer contributing
> developer status with it already having been approved. If the second
> party wants it, then it'll be done.
>
> Possible downsides:
>
> 1) It moves the consideration of applications out of public view. This
> might foster bias, or the appearance of bias, especially from the
> perspective of applicants finding themselves refused. In mitigation,
> applicants will always have the choice of a regular public application.
> One risk is that most awards become private; we could mitigate that by
> actively resisting any such tendancy, for example by limiting third
> party awards by number or ratio[2]. Another mitigation might be to
> publish third party applications if they are approved and accepted.
>
> 2) Some potential applicants might sit around disappointed forever
> waiting to be nominated by someone else instead of applying themselves,
> in the knowledge that a third party nomination route exists. Apart from
> general encouragement I'm not sure anything could be done about this;
> it's a case of the trade-off between this and losing applicants because
> they delay applying already.
>
> 3) Accidental publication of a private third party application.
>
> I would also specifically encourage DMB members to make nominations.
>
> To limit concerns I suggest doing this initially only for contributing
> developer applications. These are much easier to consider without a wide
> range of endorsements; contributions are generally publicly visible for
> anyone to point out, and possible concerns such as "does this person
> work well with others?" are generally much less important. If successful
> we could consider expanding it to applications to grant upload access,
> but that would be a future discussion and doesn't need to be considered
> now.
>
> What do you think?
>
> Robie
>
> [1] Privately because it wouldn't necessarily be done with the knowledge
> of the second party, and we wouldn't want to draw attention to people if
> it turns out they are unsuccessful.
>
> [2] This would be "a good problem to have". If it did happen, we could
> for example limit the rate that third party awards are made by ranking
> them and choosing only the top ones. The regular application process
> would be unaffected.
> --
> Devel-permissions mailing list
> Devel-permissions at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/devel-permissions