Making Ubuntu More Personal

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.

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, 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?

  • jimms

    nice information thanks champ

  • http://blogs.gnome.org/bolsh Dave Neary

    Link for you: http://www.itworld.com/open-source/78271/mentoring-open-source-communities-what-works-what-doesnt

    I like loosely organised mentoring, but a lot of people ask for mentoring without then putting the time into their projects.

    The important step I think is getting someone from newbie to newbie mentor as soon as possible – you shouldn’t need to be in the top 1% “superstars” to be a mentor.

    And, as you allude to, making it visible when someone interacts with the project is useful – if the person is in contact with 8 or 10 different people, they should all be able to see the flow of activity. The challenge is how to make the process work without making it too spammy/chatty.

    Cheers, Dave.

  • Seung Soo, Ha

    Nice post!

    I liked the first paragraph, especially what you said about “write” communities as opposed to “read” communities.

  • http://neosap.org Jack Duncan

    Hi Guys, Your ability to communicate world wide is inspiring and should be a model. The weekly updates are great. I have been a UBUNTU fan for years. Here in the USA so many of us took employment hits with ‘outsourcing’. Again,this year, I have been whacked with a layoff but Ubuntu keeps my systems analyst brain functioning and allows me to keep my head in the game when my head could be crashing. You guys are in the day-to-day process and whatever direction you want to take us I will fully support!! You talk about leadership, there is also a side affect that you can’t feel and thats the affect on those of us not currently employed that have a place to keep busy and feel good. Sounds weird huh? Warmest regards – Jack (ps – great pic)

  • Ryan B

    For people who just start out with Ubuntu (non technical users) finding your way around can be a daunting task. So the documentation should be top notch, a newbie user manual would help. A manual which goes into the tiny details. I’m in IT but even I miss the connection between certain points when reading the chapters on the terminal. Who better to write the documentation than the developer. Getting the technical and non technical users involved is the key. Making them understand each other that’s what’s it’s all about.

  • toymistress

    i love my ubuntu when its working n i have it on a dual boot wth vista..

  • toymistress

    i hope you folks can keep improving things ..

  • leoquant

    An other effort which could make Ubuntu more personal: https://wiki.ubuntu.com/guesthouse_and_house_exchange/

  • Anon

    Well I think there are a few things that have made such a thing detrimental to gaining community support.

    They’ve been said before but they really need to be addressed if you want more developer support to follow.

    I’ve gone from user of ubuntu, to bug reporter, to developer and PPA publisher. In that time I have seen things get worse as Canonical struggles with scaling problems of the user base.

    The ignore tag in launchpad called “opinion” which was added after the whole menu bar controversy to silence the majority.

    Yes, it’s helpful for filtering out the “me too” spam however it also segregates the community you’re trying to involve.

    How many people do you think are going to stay around when they realise their bug reports are being ignored? How many of those people would have later become contributors to Ubuntu? My guess is quite a few. These are people that care about the software they use after all and have taken the time to login to launchpad and make it better.

    The confirmed bug reports that get ignored for years in the hope that upstream fixes the problem and it gets synced into ubuntu without any effort on the community or Canonicals part.

    This needs to be addressed. There’s only so much “does this work for you in the latest version?” a person can take before they give up all hope and just say “i’m done”. I’ve seen it quite a few times in bugs on launchpad where people get frustrated with the process.

    I think you could fix part of the problem by encouraging bug submitters to help fix the problems.

    Provide information about where to download the latest source, compile and see if the issue gets fixed. That takes a lot of work so it’s probably best you provide an easy reference for members that triage the bugs, perhaps something added directly to launchpad that provide details such as build instructions, how to debug an issue, etc.

    Launchpad has functionality that communicates with upstream but I don’t think that it’s used enough and also goes far enough in working together with upstream.

    As a packager I didn’t follow the steps you listed. It grew out of a frustration of Ubuntu always having out dated packages.

    I wish there was better communication with Debian on requesting packages get updated or being able to comment on how packages are made. Currently if there is a problem in a Debian package you have to file a bug in launchpad, file a bug in Debian and then link that bug number in launchpad.

    Since a lot of the packages are simply pulled from Debian I wish that part integrated better so that there is a process for communicating and contributing wasn’t so segregated.

    This might have gone slightly off topic however I believe it is important because a lot of packagers in my opinion come from launchpad. They don’t turn up on the mailing list one day saying they want to package software. If they get put off by the Ubuntu bug reporting process and patch submission with upstream then they’re simply not going to ever get to the packaging stage.