One of the most complex things we need to deal with in the Ubuntu community is *scale*. We are a *big* community and as I have talked [about](https://archivedblog.jonobacon.com/2011/01/07/making-ubuntu-more-personal/) [before](https://archivedblog.jonobacon.com/2011/01/22/making-ubuntu-more-personal-identify-contributions-to-engage-more-personally/), I am really keen to ensure that as many people as possible get a very *personal* Ubuntu experience. We are keen to ensure that everyone who strives to become an Ubuntu Member, Core Developer or MOTU gets the very best support and guidance they can from the community to help them be successful.

For us to get to 200 million users it is essential that we can grow and scale up our developer community. A strong developer programme built on the foundation of contributors getting this personal experience is key to our success.

Not success.

Inside Canonical, people have traditionally looked to my team to provide this community growth. While this is an understandable assumption to make, it doesn’t scale. While the team has made great strides in growing our community, we will quickly become a funnel if we try to mentor a significant number of contributors. My goal for this cycle has been to try and put together a strategic solution to resolve this scaling issue. This work is very much internal Canonical team related strategy, but I figured it could be of interest to the community to see where my thinking is.

## Team Level Mentoring

In the Ubuntu Platform team we have a series of different sub-teams such as **Desktop, Server, Foundations, Kernel** and more. Outside of Ubuntu Platform we have teams such as **Ubuntu One** and the **Desktop Experience** team. My goal in building this strategy is to grow community where it makes sense for those different teams and to invest in skills acquisition and mentoring *inside* those skills; not simply my team becoming a proxy for that work.

To achieve this I have talked with many of the Engineering Managers and asked them to assign a member of their teams to be empowered to coordinate this work within their team. To match this person, I have assigned my team across these different teams. Here are some example pairings:

* **Desktop** – Daniel Holbach (*Community Team*) and Jason Warner (*Desktop Team*).
* **Server** – Ahmed Kamal (*Community Team*) and Dave Walker (*Server Team*).
* **Kernel** – David Planella (*Community Team*) and John Johansson (*Kernel Team*).
* **Desktop Experience** – Jorge Castro (*Community Team*) and Neil Jagdish Patel (*Desktop Experience Team*).
* **Ubuntu One** – Jorge Castro (*Community Team*) and Stuart ‘Aq’ Langridge (*Ubuntu One Team*).

With each of these teams I have discuss areas of focus for community growth in the 11.10 cycle that are of particular interest to those specific teams. These have been agreed upon as:

* **Desktop** – Encouraging new packagers and helping mentoring existing prospective developers.
* **Server** – Encouraging new packagers and helping mentoring existing prospective developers.
* **Kernel** – Growing the Kernel QA, Testing, and Triage community.
* **Desktop Experience** – Growing the Unity developer community with a particular focus on getting some developers to the point where they can commit to trunk and review branches.
* **Ubuntu One** – Encouraging the adoption of Ubuntu One by application developers in their apps.

For many of these teams there will be an explicit focus on a team-specific bitesize bugs campaign to act as an on-ramp for new contributors, so you can expect to see a lot of buzz and interest in those campaigns.

Our plan for ‘buzz’ basically involves this. And a free t-shirt.

With the *Desktop* and *Server* teams we are also going to be [reviewing the active timelines](https://archivedblog.jonobacon.com/2011/01/22/making-ubuntu-more-personal-identify-contributions-to-engage-more-personally/) of prospective developers and asking members of those teams to reach out and provide a helping hand to those prospective developers to help them over the hump in being approved as an Ubuntu Developer. We have found in trials of this approach that it provides a very positive personal experience for the folks being mentored.

To manage this work, I have asked each of the pairs above to prepare a roadmap for the 11.10 cycle to coordinate where they will focus and they will track this work with weekly calls. In addition to this my team will be having regular best-practice review calls to ensure the best techniques and approaches learned from this plan are shared across all teams to the benefit of everyone.

So anyway, that is the plan, and I look forward to kicking the tires on it soon!