Agenda versus Applications: Discrepancy needing a solution

[Nick Rosbrook]

On Thu, Jan 23, 2025 at 5:27 PM Simon Quigley <simon at tsimonq2.net> wrote:
>
> Hi Adrien and Robie,
>
> On 1/23/25 03:07 PM, Adrien Nader wrote:
> > Hi,
> >
> > On Thu, Jan 23, 2025, Robie Basak wrote:
> >> I appreciate that it's important to make sure that we don't
> >> disenfranchise applicants by inappropriately booking slots ahead of
> >> time.
> >>
> >> But what's inappropriate? If we don't want people to book slots ahead of
> >> their application being ready, then I think we should be explicit about
> >> that, and what exactly "ready" means. If we're going to do any adjusting
> >> of specific applicants, I'd prefer to see that done under some principle
> >> that is first well documented and understood.
>
> Strong +1.
>
> >> But also, is there really a problem that needs solving here?
> >
> > As Simon mentioned in the other branch of this thread, we've also been
> > discussing it a bit over IRC.
> >
> > He was going through applications in advance (which is definitely
> > great!) and was surprised to see missing pages. I reckon that's not very
> > engaging.
> >
> > On the other hand, I had decided to select a slot because not having a
> > clear date doesn't help prepare things.
> >
> > I think it's clear that we were approaching this from two opposite
> > positions.
> > The application should be ready before the meeting but DMB members
> > should review applications before the meeting AFAIU. But these two
> > "before" could happen in any order. It's probably better to not have
> > something strict but I think indicative delays could be welcome by
> > applicants.
>
> I agree on being somewhat relaxed with this. If I had to define an ideal process from my perspective, it would look like this:
>   1. Application wiki page is started by the applicant, and basic details are filled in.
>   2. The applicant seeks feedback from their sponsors on the application, adjusts it based on their feedback, and ideally gains a few endorsements.
>   3. The applicant selects a meeting slot, links their wiki page, then emails devel-permissions notifying them of the addition.
>      a. Individual DMB members perform an initial review of the application at their convenience.
>   4. Somewhere between a week and a day before the meeting, the applicant re-reviews their own application and makes any final tweaks.
>      a. Individual DMB members thoroughly review the application at their convenience, perhaps think about a preliminary vote, and prepare their questions for the applicant.
>   5. The meeting happens, the link is pasted in the channel, and the application is reviewed as per usual standards.
>
> 2 and 3 are interchangeable, in my opinion. Here's what this process is looking to avoid, though:
>   - Applications with no endorsements or comments making it to the meeting, where it will almost certainly be rejected.
>   - An application is on the agenda but has no endorsements, and less than a week before, the applicant is scrambling for endorsements.
>   - An application added to the agenda with very little notice (or an entry added to the agenda but the link is added last-minute), which could result in a less thorough review from the DMB, and thus more questions or perhaps a rejection.
>
> I'd like to propose we adopt this "ideal process" officially as the DMB. Obviously, the specifics will depend on the application, but hopefully this will make things clear in terms of expectations.

I don't see how that's wildly different than the process outlined
here: https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess#Applying_for_team_membership

It seems to me that the question at hand is more about enforcing this
policy. But, with only a couple outliers (each meeting being more than
a month away), I don't see why anything more than a friendly ping is
needed at this time. So, to reiterate Robie's point: is there really a
problem that needs solving right now?

>
>  From a community perspective, my observation/hypothesis is that more people within Canonical are being encouraged to apply for upload rights.
>
> I like this, it's a good idea, but it's worth noting that we apply consistent standards across *all* applicants, Canonical or not. I'd encourage Canonical management to be conscious of this, if they aren't already.
>
> >> Theoretically all applicants should be well connected by the time they
> >> are ready to apply, so can they speak to each other and figure it out
> >> themselves, without us needing to impose rules?
>
> Theoretically, it would be absolutely great if this was the case. It isn't, though.
>
> I'll talk about some hypothetical applicant in this case; if you're a sleuth I'm sure you have an idea, but don't consider this feedback on that application, or a warrant to harass anyone.
>
> Someone applies for upload rights, let's say MOTU, and works at Canonical. Many of their peers or managers within that team leave *excellent*, *glowing* endorsements or comments. What's the problem?
>
> There's naturally going to be bias.
>
> In the specific case I'm thinking of, in my opinion, the applicant did not correctly understand the differences between Ubuntu and Debian, our de facto policies around sending patches up to Debian, and the massive improvements we've made on this front, somewhat recently.
>
> The team endorsing the application didn't think twice about this philosophical point (at least from what I can tell), because from their perspective, their team is separate from (but sometimes collaborates with) the Debian counterpart.
>
> Okay, so again, what's the problem?
>
> That's too specific of a focus, philosophically speaking, for a MOTU. They should understand the wider social scope of Ubuntu. I did send a quick PM to that team lead (also an Ubuntu Member) explaining all of this, and left it with them as an internal training exercise.
> (I quite enjoy working with this excellent team, and anything more would have been unnecessary, to be honest.)
>
> This all being said, I would also encourage Canonical employees to seek endorsements outside of their team and direct peers (except for PPUs or Contributing Devs), to get a fresh perspective on the application. It certainly doesn't hurt.

I'm sorry if I am missing something, but what does any of this have to
do with the question about scheduling?

-Nick