We’re at part 4 already - WOW!

The main reason for publishing these interviews is that I think sponsors get far too little pats on the back, hugs and free ice cream, also there’s a lot of people who don’t know about it yet and should because it’s their entry point to making Ubuntu better, improving their packaging skills and getting in touch with the awesome people that are in the MOTU team.

I talked to Nathan Handler who sent us a positive avalanche of review requests and is doing amazing work.

What has your sponsoring experience been like up until now? I have had a great experience with the sponsoring process. My sponsors have been very helpful, and they have been very quick in reviewing my patches. If one of my patches wasn’t perfect, they worked with me until it got uploaded. I’m looking forward to the day when I will be able to sponsor other contributors’ uploads.

Did you learn a lot in the process of sponsoring? Do you remember the last things you learned? I have learned almost everything I currently know from my sponsors, and I am still learning. Just the other day, I created a patch for a package in a bzr branch. I had never done this before. Without one of my sponsors advising me to do that, the patch probably would never make its way into the repositories. Now, I will know for next time to check if the package is maintained in a bzr branch before trying to patch it.

Which packages do you mostly look after? Do you follow some kind of strategy when you try to fix bugs and make Ubuntu better? I don’t look after any specific package(s). Up until about last week, I had been spending a lot of time merging and requesting syncs for packages in the universe and multiverse repositories. Currently, I am working on patching bugs and clearing up the really-fix-it list. Before I start any work on a bug, I read through every comment. This allows me to learn what sort of progress (if any) has been made. It also prevents me from working on a bug that someone else is already working on. Sometimes, there is even a solution to the bug that has been posted as a comment.

Is contributing to Ubuntu hard? If so, what should be easier? Contributing to Ubuntu is not hard once you learn some of the basics. Some of my first bugs were adding missing Depends/Recommends/Suggests to the debian/control file in packages. These types of bugs are very easy to fix. The hardest part for new contributors is locating these easy bugs. We can make it easier for them by tagging these easy bugs with the ‘bitesize’ tag. This tag was designed to be used to mark bugs that are easy enough for new contributors to fix. However, not many people take the time to search for new bugs that can be tagged with this tag. Another way we can help new contributors is by offering mentoring for bugs. For my first bug, Emmet Hikory (persia) was offering mentorship. Without his help, I probably would have quit working on that bug.

Is there a message you would like to go out to the Ubuntu sponsors? I would like to thank all of the Ubuntu sponsors. Besides patching bugs themselves, they also find time to test and upload the patches of contributors like myself, who are unable to upload directly to the repositories. Their hard work helps make this community the great community that it is.

One to new contributors? The first bug is the hardest. Before you can fix it, you need to learn about the layout of a package, and how to use the various packaging tools available. However, when your first patch gets uploaded to the repositories, you will feel a sense of pride in knowing that you helped contribute to Ubuntu. After that, patching bugs will become a lot easier. You will also feel more motivated to contribute. However, always remember, this is a community. You are never on your own. If you need help, ask for it. You will learn more by doing this, and you will also meet many new friends.

Thanks a lot for the great work you do! Keep it up! No problem Daniel. I have no intention of stopping any time soon. I’mlooking forward to getting to work more with you and the other MOTUs.

It’s great and refreshing to talk to people on their MOTU adventure. Their energy and passion for making Ubuntu better every day is just awesome. I also talked to Luke Yelavich who is not only an amazing person in our community (Accessibility team, various MOTU teams, etc etc.) but is also an excellent musician: I saw him play the drums and the piano in Prague and was absolutely astounded.

First of all thanks for doing sponsoring - you kick ass! :-) No problem, I’ll help whenever and whereever I can.

Do you still remember when you first were being sponsored? What did it feel like? Yes, I remember rather clearly. I found it both exciting, and nerve wracking. Exciting because I knew I was helping improve/update something in Ubuntu, as well as knowing I was another step further to becoming a MOTU. Nerve wracking because while I thought I’d done everything right, I was wondering whether I had missed some small thing that was vitally important.

I hope everybody was nice and friendly… :-) Of course they were, and encouraging.

I’m happy to hear that. :-)

Do you have a lot of conversations with people you sponsor? Do a lot of patches need discussion? I generally don’t have much in the way of conversation with people who’s work I sponsor, and most patches I sponsor don’t really need discussion, save for the occasional thing here and there that I’m happy to add myself, and remind the contributor about in the bug report.

That sounds good - it keeps the process efficient, but still instructional. Yes indeed.

So is there a pretty common mistake or anything else you’d like to see improve or are you generally happy? Mostly happy, but I think one thing that would be nice is to make sure all changelog entries are clear to the point that someone who has never touched the package before can pick it up and work out what has been done. I have also had to pull one or two people up occasionally on the lack of explanation in the changelog entries, so far as they state something along the lines of something similar to “kept blah from previous merged version” etc.

That makes a lot of sense - one thing I sometimes ask for myself is a reference to some kind of discussion that has happened before, like an upstream bug number or a reference to a CSV commit.

Yes. I find myself doing a merge, and trying to work out why a change was made, and having to ask the previous merger, and even them not even being sure why somethign was done.

Exactly. What kind of packages do you mostly sponsor? Is there anything new contributors could help you with? I mostly sponsor packages related to Ubuntu Studio, and accessibility related packages, mostly related to the GNOME accessibility stack, with the exception of helping with the sponsors queue from time to time. At the moment, there is nothing I need help with, but in the future, if I manage to grow the accessibility team and developer interest, sponsorship help may be needed.

So people with an interest in Ubuntu’s accessibility should keep an eye on https://wiki.ubuntu.com/Accessibility/Team or just talk to you? Just talk to me. The wiki is in no shape to be referred to atm.

Ok, excellent. ** What kind of patches / fixes would you like to see more?** Patches/fixes that go to Debian first, so they can be synced/merged. :) I can’t really think of any at the moment.

That sounds like a good advice - it sounds like a recurring theme in these interviews. :-)

Is there another message you would like to go out to new contributors?

A couple of things:

  1. Please make sure nobody is doing what you plan to do, so that nobody wastes time needlessly. If we don’t step on each other’s toes, we can get more work done, and be more efficient in getting work done.
  2. Take your time. Once you know you are the one to work on something, don’t rush it. You will only miss something that could be important, in which case you will have to go back and re-do it, taking up more time than is otherwise needed. If there is a time constraint, ask for assistance and work through it with someone to ensure it gets done as soon as possible, and before that big deadline.
  3. If you have a merge request filed, please check regularly to ensure that it is the latest against the latest debian version. A few times I have had to ask people to re-merge against a newer Debian revision. This can happen if the queue is long, and your request is not attended to straight away, so please ensure it is against the latest Debian revision. That way, the request can be processed, and you can move on.
  4. Other than that, get to know who you are working with, and who sponsors your requests. You then have a greater chance of getting good feedback/support when it comes time to apply to be a MOTU.

That’s great advice, I’m sure new contributors will appreciate it. In terms of getting to know your fellow developers: there’s always somebody who can help you out in #ubuntu-motu. :-)

Yep exactly.

One piece of advice from myself: if you ever get to see Luke Yelavich play the drums or the piano, skip whatever plans you had before and go to see him. :-)

lol! I’m not that good. :)

He’s always that modest. :-)

Thanks a lot for the great work you do! Keep it up!

No problem, and don’t be affraid to help out however you can. We won’t bite.