At UDS last week I took an action to write up a quick blog post that explains how UDS sponsorship works. This discussion was born out of the view that some people feel a little bent out of shape when they don’t get approved for UDS sponsorship. This is a common reaction at every UDS, but it really shouldn’t be. Firstly, UDS sponsorship is *not an entitlement*…there is no rule that says “*if you are a great Ubuntu contributor then you get sponsored to UDS*”, and likewise there is no rule that says “*if you are a bad Ubuntu contributor (if such a thing exists) then you don’t get sponsored to UDS*”.

Let me make this point really clear:

**Awesome contributors who do great work often don’t get sponsored due to sponsorship budget limitations**.

OK, now, I want you all to go back and re-read that again. Furthermore, if you see anyone griping about not getting sponsored for whatever reason, I would like to ask you to point them to this blog entry.

### How Sponsorship Works

As I mentioned, I said I would write a blog entry that explains how UDS Sponsorship works. Get ready, it isn’t exactly simple, but I think it provides a really fair method of identifying people who are most suitable for a given UDS. This is a system we have hammered out over the last few years.

This is how it works:

Firstly, we invite people to apply for sponsorship and they file their application in the sponsorship system. Sponsorship is open to everyone. We also ask the Ubuntu Engineering Management team and certain developers at Canonical to make recommendations in the system too. The outcome of this process often nets over 120 or so names in the system. We usually sponsor around 60 people, so our goal is to whittle the list down to the **people who are likely to bring most value to UDS for the goals of that specific release**.

The last bit is important…”*that specific release*”. There is always value brought by everyone at UDS, but given the limited number of people we can sponsor to UDS, it makes sense to bring in people who have valuable input for the goals and focus of the next release. This is not exclusive: we do also prioritize some folks based upon recurring value too (e.g. governance members, some core-devs etc), but as a general role we focus on that given release, not Ubuntu in general.

Inside our system we provide the ability for engineering managers and key staff to vote applications between +3 (considered essential for goals related to that release, and bringing huge input and value to sessions) and -3 (significant concerns or objections about that that person attending, such as worries about not attending sessions, wasting time, being disruptive to other attendees etc).

We then have two stages of scores being applied to candidates:

* Firstly we add **+1** to everyone who has never been to UDS before. This is because we always want to provide an opportunity for new folks to join UDS who have not been before and take part in such a valuable experience in the Ubuntu community. We also apply a **+1** to anyone who is an Ubuntu Member, core-dev, MOTU, or a member of a governance board. We pre-seed these scores because we consider the combination of new blood but also acknowledged experience to be a good combination.
* Secondly, we ask the Ubuntu Engineering Management Team and key staff members to go in and vote for people. They can vote between +3 and -3 and if they don’t know the candidate, the score is left at 0. Rarely do people get negative scores, and is typically only in cases when someone is considered extremely disruptive, abusive, a time-waster, or has demonstrated wasteful or disruptive conduct at a previous UDS.

The scores are aggregated to form a final score (e.g. if two engineering managers provide a -1 and a +3 the final score will be +2). With this we then have a big list of sponsored attendees listed in aggregated score order from high to low.

At this point we have to perform some editorial input on the lower part of the group. As an example, candidates 45 -> 55 may all have +2 scores, which gives us ten slots but then we might have 20 candidates with +2 scores. At this point I will assess the goals of the release and the needs of the engineering teams and shortlist this final ten in the group to form the final 55 or so. I usually approve 55 out of the 60 at this point because there are always engineering managers who have late-breaking needs that need to be satisfied, so I leave a buffer of 5 slots to accommodate these needs.

Finally, the list goes to Mark Shuttleworth who takes a final look and typically makes a few amends (typically people he wants to go who are not on the list) and then the list goes to Marianna who sends the invitations out.

At every UDS there people who are offered sponsorship but who cannot attend, so we also have a backup list of people with the next highest scores who we invite to take up the places of those people who can’t join us.

So that’s it – as you can see it is a pretty fair system – it takes multiple levels of input from a variety of staff and optimizes people if they have not been before or if they have achieved membership, are governors or are approved developers. I am sure some of you will take issue with the fact that this is all Canonical driven, but remember this is a Canonical funded event; UDS is not funded by a foundation or suchlike. I would though in future like to invite the perspectives of some governors on sponsorship applications if it makes sense.

Wrapping up, I want to drill this in one last time:

**Awesome contributors who do great work often don’t get sponsored due to sponsorship budget limitations**.

It doesn’t mean that we don’t love you. We do. Over half of the people who apply don’t get sponsored due to these space limitations, so don’t take it too personally. If you do take it personally, ping me on IRC and we can talk more.