Proactively awarding developer status?

[Robie Basak]

Hi Dan,

Thank you for the discussion. I have some comments on some of your
specific points.

On Mon, Nov 09, 2020 at 11:52:44AM -0500, Dan Streetman wrote:
> 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.

I disagree that contributing developer status is only useful for the
applicant. I think that having contributions publicly recognised fosters
further contributions and encourages both the awardee as well as others
in the community, and that's of wider general benefit to the project.

[...]

> 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.

I think there are two key benefits to continuning realtime meetings.

1. For the DMB, it actually causes DMB members to show up and vote. If
you look at some email-handled applications, for example, you'll notice
that members have historically still needed chasing to vote. By having
realtime meetings there's a clear understanding of who is and isn't
showing up. Recently attendance has been much better. In any case, I had
made a separate proposal to deal with DMB absenteeism that I think might
be able to make headway now if we need it.

2. I value the ability to ask applicants in realtime about their
knowledge of some areas. This way it usually becomes clear if they're
not ready because of process misunderstanding in a way that I don't
think can happen by email. For this reason, I prefer to see all
applications be handled in realtime, unless there's a good reason this
isn't practical.

> 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

It isn't obvious to applicants. I added that section (with sample text
that applicants don't even need to modify) because we were getting too
many applicants who were applying ahead of having any sponsored uploads
for the area they were applying for. This section has the effect of
forcing applicants to consider if they meet our usual expectations, and
I think this has been working well. It results in fewer wasted
applications - for example someone applying because they intend to work
on a particular area but have no track record of sponsored uploads in
that area.

> 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.

I appreciate the effort in streamlining the process and I'm in favour of
this. However I think that's orthogonal to my proposal, since however
streamlined we make the process, we cannot eliminate the red tape
barrier completely.

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/devel-permissions/attachments/20201109/04296921/attachment.sig>