Becoming an Ubuntu Developer: a short guide

I’ve heard and/or read a number of complaints over the past while about how the process of becoming an Ubuntu Developer is difficult, so I thought I’d write up a short guide to one of the many paths to becoming a developer. I send this to the Ubuntu Developers list for maximum distribution, although I realise that many of you are already developers, so won’t find this as useful: please skip past it, or pass it on to those you know that are currently interested in becoming Ubuntu Developers (or extending the set of packages to which they have been granted upload rights).

Step 1: Membership
While it’s not required to be an Ubuntu Member before applying to be a developer, it is required that the criteria of Membership be met to be approved as a developer. In short, this means being actively involved with and contributing to Ubuntu for some time (usually about a development cycle, although it can be shorter for those with very strong contributions). Spend time interacting with other members of the community, and learn as much about how Ubuntu works and how it is created as possible. Those with a specific interest in development may find that the Masters of the Unseeded or the Bug Squad are good places to start, if there is no other team with whom they have a natural affinity. Those of more general involvement may obtain membership through any number of other sorts of contributions. More information on the requirements for Membership are available on the wiki at

Step 2: Start working in the area for which you want upload rights
We have an increasing number of packagesets, each targeting a specific area of development, and the negative space of all packagesets, where we tend to focus mostly on archive quality. Find an area that interests you, and get to know the developers actively working in that area. Start working on things that fit within your area of interest, building both expertise with the work you have selected and close relationships with others working in the same area. For example, if you wish to be a server developer, start working to fix bugs in packages in the server packageset, working closely with the Ubuntu Server team. Alternately, if you wish to be a core developer, start working to fix bugs in packages in the core packageset, working closely with other core developers. Your goal in this step is to become a peer to the other members of the relevant team. You may find it useful to review to see some of the descriptions of the various sorts of developers.

Step 3: Prepare an application
Follow to create your application. Clearly document your work in the areas of interest. Be especially sure to provide links to work done upstream (including in Debian) on packages in the target area, and any work where you were one of several contributing to a single uploaded revision, as the automated upload tracker in launchpad only reports those packages for which you have sole changelog credit. Documenting a few different types of work, or work in different parts of the release cycle (where different choices were required) can help show a broader understanding. The more specific you can be in every section of your application, the better: for example, a future plan to ensure Ubuntu provides the best possible turnkey PBX solution for the next LTS will often receive more credence than a short listing of "more of the same" for someone previously working on the VoIP stack, especially if it includes some details. If you are working on blueprints, listing your outstanding blueprint-related tasks here (with links) is a great way to provide detail. When seeking endorsements for your application, a good strategy is to ask anyone who suggests you should apply to endorse your application, and ask anyone sponsoring your work to endorse you (best to ask at the time they are sponsoring it). If someone says they haven’t seen enough of your work to endorse you, ask them for a task or two: helping folk with their work is nearly guaranteed to get you good endorsements.

Step 4: Apply
Check for upcoming meeting dates and times, and send a notification of your application to the mailing list at least a week before the meeting you wish to attend. Be prepared to answer a few questions: these are usually related to your prior work, other information on your application, or Ubuntu development policies and procedures. If your application is deferred for some reason, contact the DMB members who were not yet convinced, and ask them to help you develop a plan to meet their expectations: many current Ubuntu Developers were deferred at first pass, but it is a rare case that someone actively involved was unable to complete the expectations within a few months, and for some it is possible to address the outstanding issues in time for the following meeting.

Good luck. If you’re feeling stuck along the way, feel free to ask other developers with whom you work regularly for guidance or suggestions. Failing that, ask generally in #ubuntu-devel at freenode, or contact a member of the DMB.

Originally sent by Emmet Hikory to the ubuntu-devel mailing list on Thu Jan 27 05:01:01 UTC 2011

Bookmark the permalink.

One Response to “Becoming an Ubuntu Developer: a short guide”

  1. Martin Finnerup Says:

    Hi. 🙂
    I was wondering if there is any areas of Ubuntu’s development, where a Web Developer might come in handy? 🙂
    I currently know HTML, CSS, PHP, MySQL and some JavaScript. I am also in the process of learning C#. 🙂
    I really want to give something back to Ubuntu’s community and developers, and would therefore really like to help the development of Ubuntu. 🙂

Leave a Reply