Ubuntu Wiki

I originally wrote this document specifically for the case of core dev applications. To make it more general, you can read it more generally with the concession that for applications that request lesser upload privilege, I only require the subset of these expectations that I think will be relevant to the majority of your uploads.

These are my personal views on how I assess DMB applications. Remember that I am just one member of the DMB and this is my personal opinion. Others may have other views and apply different sets of expectations.

All of this is flexible. No application is exactly the same; everyone's position is different to some extent. Where a situation calls for different consideration for some reason, I am happy to consider it. If this applies to you, please make sure to explain in your application how you think you need different consideration.

"Need to unblock" principle: remember that the DMB normally approves applications either to reduce contributor friction in needing sponsorship or to save the work of sponsors. I expect a core dev applicant to have an existing track record of sponsored uploads to packages to which direct upload access is requested.

Cultural fit: my understanding of our development process and the Ubuntu Code of Conduct is that all actions by Ubuntu developers require consensus, but this consensus can be implicit or explicit. Most of the work we do has implicit consensus that we receive through our mutual understanding as we work together in our teams, and this is essential to make progress. This relies on individual developers understanding when other team members will have no objection, and on being active in seeking consensus when this is not the case. I don't specifically expect evidence of this, but I do take into account any information I have on this aspect.

Communication: you're proposing to join a team of developers working together on a common project. I therefore expect you to be in regular contact with developers, as appropriate to your focus, both in relation to your work and in helping others. This would be with all developers generally for a core dev application, but my bar lowers the more limited upload permissions the application requests. Since Ubuntu is developed in public, I expect these communications to be in an appropriate public channel, and I can therefore assess this directly. Generally this means that you should be active in the public mailing lists, Discourse, and Matrix rooms. If you are unknown or inactive in the appropriate public Ubuntu development channels, this will score negatively in my assessment of your application.

For Canonical employees: I look for an ability to negotiate the distinction between Ubuntu governance and Canonical priorities. Sometimes these can appear to collide and it needs a certain level of diplomacy to find a solution that work well for both sides. Again, I don't specifically expect evidence of this but more information gives me more confidence in making a decision.

Usually I'd expect DMB members who are still active in Ubuntu development to have interacted extensively with prospective core devs which can help inform my last three points.

I expect evidence of a thorough understanding and experience in Debian packaging, of course.

Then there's the technical Ubuntu-specific side: I expect a demonstrated understanding of Ubuntu-specific processes such as Ubuntu package merges, SRUs, the release cycle, milestones and exceptions, autopkgtest and proposed migration, handling transitions, the operation of the seeds and MIRs. I don't necessarily expect detailed direct experience in all of these, but I do expect to see direct and deep experience of at least some of them and a general understanding of most of them.

In addition I would expect a core dev applicant to either: (a) be an already experienced Ubuntu uploader through one of the other uploading teams such as a packageset or MOTU; or (b) present an exceptionally strong application to go direct to core dev. In the case of (a), the previous upload history will allow me to assess the application in detail. Failing that, a string of sponsorships and endorsements from a wide range of existing uploaders that includes some respected names would give me confidence in (b).

I expect endorsements from your existing sponsors. It's important to distinguish between work that required substantial input from a sponsor before it was ready, and work that was already good when first proposed and that sponsors had little to improve upon. In the former case, approving an application would not be appropriate; I only want to to approve applications where the latter cases have applied for a while. As it isn't possible to distinguish the two cases from sponsored uploads alone, I look at endorsements and review comments to make up for that. Review iteration often happens out of band, so the lack of review comments doesn't automatically imply the latter case. Since sponsors who don't think you're ready yet generally prefer to say nothing rather than publish a negative endorsement, the lack of endorsements from a substantial proportion of your sponsors is a red flag.