Proactively awarding developer status?

[Dan Streetman]

On Mon, Nov 9, 2020 at 1:19 PM Robie Basak <robie.basak at ubuntu.com> wrote:
>
> 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.

I didn't say that recognizing contributions isn't useful to the
community; it is.

However, recognizing a specific individual as a contributor is only
useful to the community if the individual being recognized cares about
being recognized, which is why I believe it's more useful to give the
recognition to individuals who have asked for it.

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

I must have misread your initial proposal then. If you want to
continue to require realtime interviews, then I don't see how having a
3rd party nomination improves the process; the 3rd party could create
the wiki page for the applicant, but they can't substitute for them
during the interview.

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

As I said maybe I misunderstood your proposal, since I thought you
were suggesting application reviews without any interview.

In any case, if you are proposing 3rd-party applications *only* for
contributing developer, then my earlier concern about the usefulness
still stands, but I don't have a strong feeling about it. If you want
to come up with a more formal proposal maybe it can be discussed in
more detail.


>
> Robie