I'm nominating myself for a seat on the Ubuntu Technical Board in 2021, after someone else nominated me previously when I stood in 2016.

Who am I?

I've been working for Canonical on the Server Team since 2011. Prior to that I was familiar with packaging for Debian and Ubuntu, but only for private projects. My first sponsored upload to Ubuntu was in 2011. I became an uploader in 2013, and a Core Dev in 2014. I became a Debian Developer in 2018. In Ubuntu, I currently serve on the Developer Membership Board and on the SRU team.

Platform

Here's what I'd like Ubuntu to do better.

1. Improved communication. Ubuntu's strength lies in its governance structure, which promotes progress by allowing for decisiveness from designated leadership when this is required. I feel that we could do a better job of communicating these decisions when they are made, including our rationale.

2. Better fostering of new contributors. To make progress, we are pragmatic and make exceptions from process for exceptional circumstances. The more we do this without explaining what we are doing or why we are doing it, the more I think we alienate ourselves from potential contributors for whom our processes become increasingly unfathomable. Fixing this comes down to my first goal: better communication.

Neither of these goals lead to obvious actions needed from the TB, perhaps with the exception of an opportunity to regularly summarise TB activity rather than expecting others to rely on minutes and meeting logs. But above are some of my personal goals that underlie everything I do in Ubuntu. You can expect the same for me if you elect me to the TB.

More details

Sometimes we have to make difficult decisions in order to make progress. Inevitably, some people will be unhappy with our decisions. But it's my belief that we could do a better job explaining our decisions in terms of our specific goals, the trade-offs we're making, and options that remain available. While I don't think it's possible to make everyone happy, I do believe that if we communicate better, we can be understood better.

Better communication and documentation also means consistency and improved development velocity for established developers. This helps us avoid mismatched expectations. Your work may have to be reviewed by the SRU team, or the release team, or archive admins, or any other similar team with review responsibility. The clearer these teams' processes are, the better you can understand their expectations, and the less likely you are to find yourself blocked in review iterations. The same goes when exceptions are proposed. Exception requests are easiest to make when framed in the context of existing policy requirements. With everything spelled out, it's easier for a decision to be made without further delay.

Here are some of the things I've already done in support of these goals:

On the SRU team, I've made various edits to the documentation to "regularise" our process in the face of various exceptional situations. I'm very much in favour of specific process documentation for any regular SRU any team wishes to upload. This way, the SRU team can agree on an documented exception process once, and uploaders can be confident that following that documentation will not result in review blockers on those points that have already been agreed. When I sense that communication is becoming muddled, I reach out to the people involved to discuss the issues more directly with a goal of reaching a conclusion and documenting the result so that we can unblock progress.

On the Developer Membership Board, I documented exactly what I personally expect from a core developer applicant. I hope that this has been providing clarity to applicants. If they meet my criteria, they can expect a +1 from me. I make a point to provide detailed reasoning in the rare case that I am -1 on an application, so that the applicant can be clear on exactly what we'd like them to change. I avoid abstaining, except in the case where I recuse myself due to an apparent conflict of interest (for example, if an applicant is a colleague of mine, I abstain except if my vote is required for quorum and everyone else is unanimous).

I invented git-ubuntu. Now that it is stable, I am working to expand its scope and usefulness to all Ubuntu developers and also to third party "drive-by" Ubuntu contributors. One of my goals with git-ubuntu is to bring consistency for contributors, instead of having to explain the various combinations of "where I do clone the VCS tree", "how do I add a patch" and so on.