Community is a *deeply personal* experience. While *write* communities such as Open Source get together to make things (as opposed to *read* communities who consume content together), the attraction and thrill is only partially in the collaboration. What really makes *write* communities fun are the personal relationships that develop; what starts as nicknames on a screen shortly burst with life and become friends who we enjoy spending time with, sharing our ideas with, and in many cases relying on to help us through tough patches of our lives. The very reason Open Source and community attracted me in the first place is that this is not just boring, cold, and unfeeling computing, it is computing driven by people who share their humanity to make the world a better place.

I like that.

I like that a lot, and I think lots of you good people do too.

Over the years in my role as *Ubuntu Community Manager* I have seen the project grow from strength to strength. I am hugely proud of all of the efforts the community has made and the achievements that we can associate with the project. I really feel we are on target for breaking new ground for desktop Linux. While there are many desktop distributions, and many of them perform stunning work, the furthest many have got to mainstream success with users (aside from just Linux enthusiasts) has been getting close to the chasm…but not taking a run-up to get over it. I feel like we are teetering on the edge of the chasm with Ubuntu, and now we have the opportunity to thrust it over into the mainstream, and therefore thrust Free Software into the mainstream.

Throughout the growth in our community, we have naturally needed to develop some processes and procedures in how people can participate. As we have scaled more and more, we have relied on these processes more and more. We can broadly break these down into two areas; **education** and **assessment**.

*Education* is how new contributors can learn how to participate and interact with Ubuntu and it’s contributors in a safe environment that (a) encourages the new contributor to try things and learn, but (b) protects Ubuntu from mistakes that rookies often make. *Assessment* is how we assess new contributors when they take this education and experience and apply to gain elevated privileges in our community such as uploading packages to the archive, becoming a governance council member, or being sponsored to the [Ubuntu Developer Summit](https://uds.ubuntu.com/).

Let’s look at an example of what I am talking about.

If someone chooses that they would like to contribute to Ubuntu as a packager — that is, packaging software, fixing bugs, and other maintenance work — well, we have a pretty standard workflow for how this happens. It looks like this:

#### Education

* The new contributor reads our documentation, joins our learning events, and otherwise grows their skills in Debian packaging and Ubuntu.
* They then road test this knowledge by fixing bugs and contributing their changes to the sponsorship queue. This queue is a list of contributions that new packagers make from across the project.
* We then ask our existing `core-dev` and `motu` developers to review these contributions, offer feedback, and when the contribution is in shape after a little bit of back and forth, it is uploaded.

*Important points to note*: the contributor may provide ten contributions and get ten or more different people providing feedback. That is ten mini-relationships growing, with each not necessarily getting to know the contributor in any significant detail, and the contributor not getting to know any Ubuntu developers in any significant detail either. This process also assumes that someone will pick up their contribution and review it.

#### Assessment

* When the contributor has made a number of contributions, it is often unclear when they should apply for upload rights (as many different people have reviewed their work and don’t see the amalgamated growth in skills). Typically another community member will encourage them to apply.
* The contributor puts together a wiki page outlining their contributions and the work they have performed. They also ask others to write testimonials advocating their approval as an uploader.
* A governance board then reviews the wiki page, asks the contributor some questions, and then has a vote to either accept or reject their application for upload rights.

*Important points to note*: (a) the governance board may have never worked directly with the contributor, and (b) are therefore basing their assessments on what I would refer to as a *tick-box* review. That is, a set of criteria that show that the contributor has performed useful technical skills, but does not really assess the *trust* in that person (i.e. do we trust this person to have the keys to our archive?). The reason: *trust* is difficult to assess when the contributor has had a wide range of small interactions with other peers (and again don’t see the amalgamated growth in skills), and the governance board may have not had any direct contact with the contributor themselves.

While this process has certainly born much fruit and many contributors have successfully been through it, it is far less personal than I would like. I would like to see a contributor’s education and assessment experience be more attuned to a specific mentor or small set of mentors, of which I will discuss a little later.

### What I Want To Shoot For

Over the years I have met a number of people who have proudly told me who inspired them to get into Open Source and a given community. Often statements of “*XYZ really inspired me to get involved*” or “*XYZ really helped me over some obstacles in getting involved*” really resonate with us when we hear these stories. Essentially, **people join because of the software, but they stay because of the community**.

We often here of these heartening experiences, but they are not systematically part of our community. Our community processes are not designed to produce those kinds of statements, but to ensure everyone gets a fair crack of the whip at learning the skills required and being able to contribute if they meet quality requirements. Our processes are designed to deliver education and assessment in a form that results in successful contributions. What I am proposing is that we improve our processes and community to engineer exactly those kinds of statements; statements that celebrate that personal interactions with another community member helped someone realize their full potential and stick with it, despite any obstacles in their way.

As an example, I think it could be a more pleasant experience for a prospective new developer to have a single mentor who guides them through their education and assessment experience. This person would review their work, see their progress, and frankly, if that person is already a trusted `core-dev`, I think they should be empowered to have the responsibility to approve someone for upload access (possibly with another person as a co-supporter of the new contributor if we want to be sure). I think this would be a far more enjoyable experience for the new contributor and would save a lot of time and effort in which the new contributor has traditionally had to build a case to convince a governance board that they have the chops.

### Growing a Community-wide Personal Experience

Of course, the aforementioned developer review case is just one example of an opportunity for injecting more of a 1-on-1 social connection into our community. While I don’t think for a second that our culture is broken, my suggestions here are merely wishing to optimize our culture around what so many of us truly enjoy about community – a sense of personal engagement.

This personal engagement can apply to many other areas. Here are just a few examples after a few minutes of thinking:

* **Highlighting inspirational leaders** – the Ubuntu community is jam-packed with incredibly inspirational leaders. Not all of these people have the words *leader, manager, team contact* or other such title; many are regular Joes and Josephines who we know and respect as always performing good work and having a constructive, balanced and positive approach. I would like to celebrate these people more. We have done this in the past with the [Hall Of Fame](https://hall-of-fame.ubuntu.com/), blog entries, and more, but I think we can do even more of this.
* **Encourage more and more mentoring** – mentoring is a hugely valuable feature in a community and is the heart of building a 1-on-1 connection between new and existing contributors. Of course, it is a complex challenge at times – it requires good mentors who have time to help new contributors. I wonder if we can come up with some ideas for improving mentoring in our community.
* **Building a culture of trust** – as I said earlier, I think we may want to consider thinking more about how we build a culture of trust in which a solid demonstration of trust and capability can open doors. Put it this way, if a *Colin Watson*, a *Martin Pitt*, or a *Iain Lane* recommended someone for upload access, I personally would take their word for it and trust their judgment; they are smart people who take care and attention in their work. Sure, we have governance boards who we ratify as having this capability, but I wonder if we should expand it beyond governance boards? While we should be conscious to not turn Ubuntu into an “old boy’s club”, I also think there is a huge opportunity to make our processes leaner and *trust the judgment of people who we trust to have good judgment*.

So what is my goal with this blog entry? I really have no fixed goal other than sharing some of my thoughts recently. This is something I want to have a discussion in the community about, and I welcome your (constructive) feedback and ideas. How can we create more experiences that feel personal, social, and like someone cares about your success in our community?