Over the past development cycle, the Ubuntu Developer Advisory Team [1] reached out to many new contributors. As part of that work, we solicited feedback about our development process. We have summarized this feedback in the attached report. It is our hope that it will help drive further discussion about our development processes, tools, and documentation in the lead up to UDS and over the course of the next cycle. Attracting new developers and maintaining our welcoming environment for contributors is an important task for the project. We encourage both new contributors and existing developers to discuss your interpretations of the report as well as any other feedback you might want to share about your experience working on Ubuntu. The full text is below. It is also available as a PDF [2]. <pre>[1] <a href="https://wiki.ubuntu.com/DeveloperAdvisoryTeam">https://wiki.ubuntu.com/DeveloperAdvisoryTeam </a> <a href="http://people.canonical.com/~dholbach/d-a-t/12.10Feedback-Contributors.pdf" target="_blank">[2] http://people.canonical.com/~dholbach/d-a-t/12.10Feedback-Contributors.pdf</a> </pre> On behalf of the Developer Advisory Team, -- Vibhav Pant <pre> </pre>New Contributor Feedback - 12.10 The Ubuntu Developer Advisory Team developer-advisory-team at <a href="http://list.ubuntu.com" target="_blank">list.ubuntu.com</a> <pre> </pre>Number of people we reached out to: 66 Got feedback from: 29 Response Rate: 43.93% Topics Total Mentions Positive Improvement Needed Tools & Infrastructure 15 8 7 Processes 9 4 5 Documentation 10 6 4 Outreach 4 4 0 People 19 18 1 Report ====== In the 12.10 cycle the Developer Advisory Team reached out to 66 contributors to ask for their feedback. We received feedback from 29 (Response Rate: 43.93%). This does not include many other conversations we are involved in, for example when we help contributors with their development application. The general tone of the feedback was positive and we received quite a number of ideas for how we can improve our development workflow. Current members of the Developer Advisory Team are: Andrea Colangelo, Andrew Starr-Bochcchio, Barneedhar Vigneshwar, Bhavani Shankar, Christophe Sauthier, Daniel Holbach, Evan Broder and Vibhav Pant. Tools & Infrastructure ====================== The vast majority of contributors who mentioned tools and infrastructure generally enjoy using Bazaar and Launchpad. Especially the tight integration between Bazaar and Launchpad and the straight-forward process were noted as advantages. PPAs, daily builds, translations integration and many other things were also mentioned in a positive light. As points for improvement the learning curve, the amount of different options and tools and Launchpad-git integration were quoted. * The thing is Bzr-only in Launchpad - I would really like to have git as an option too * Launchpad is a pain to get working initially, and there's really a whole lot of stuff to read up on first before things become useful. * would try to reduce the number of tools available because sometime it's disorienting when you have to choice things and both have pro and cons. * Even though I'm more of a git fan personally, bzr's integration with launchpad makes contributions very easy and very fun. For instance unity or compiz - you pick up a bug, prepare a branch, request a merge and wait for reviews. Easy. * Pushing to launchpad can trigger builds, review, merges, ... That's quite amazing stuff which helps a lot in building and managing a whole distribution. * The tools, while occasionally cryptic and unpolished, make development easier, faster and even fun once you get the hang of them. * In general, I like the development process and the tools (from build systems to online services) are very easy to use. * It's not always clear which launchpad service is the right one to use. E.g. on a blueprint, if I want to offer a comment, should I edit the whiteboard, or pick a relevant name to email? Or is there somewhere a discussion feature associated with it? * The features provided by Launchpad are also interesting. * Launchpad environment which integrates all the development workflow; I can quickly and easily checkout sources of any package, commit a patch, link it to a bug report, ask for a review/merge, manage the translation, build a package and push it into a PPA, etc. That's just amazing.. * It was quite easy to create the branch and pushing it to launchpad as everything needed is explained by launchpad (where to push, how to push etc.). * Also, it would be very good to have a much easier way to submit bugs related to a ppa. Currently, they end up being emails sent to me. Having more visibility, would help the user and me. * Launchpad could be slightly improved (speeding it up, fixing some annoying bugs like <a href="http://pad.lv/523989" target="_blank">pad.lv/523989</a>, adding some markup options, etc). * I liked the automation that you accomplished using launchpad and bzr. * like the development process and the tools (from build systems to online services) are very easy to use * Bzr and Launchpad are very effective and make collaboration and peer feedback nearly painless. Processes ========= Processes in general were mentioned less as part of the feedback, the only improvements contributors requested were doing the follow more easily: getting in touch with package maintainers, finding out what needs doing, getting new packages into Debian/Ubuntu, quicker sponsoring and more stable release fixes. Our processes got some good feedback as well. * I am very satisfied with the helpfulness of the community, and I have never had any negative interactions based on any work that I have done. All of the comments from uploaders or reviewers of my work have been constructive, and this really helps one learn and remain motivated. * It would be nice if people doing bug triage got in touch with the package maintainer as well - sometimes some of the questions which get asked of bug submitters by bug triagers could be more useful with prior input from the maintainer. * The only part I feel that can be improved is the way I have to find packages that I have interest in helping. * Debian seems to have an enormous barrier to entry for getting new packages accepted into the archive. And unfortunately this is described as the easiest way to get new packages into Ubuntu! * Generally once a release has been released not too much care is giving to it - sure, there's an occasional sru, but for the rest it's ignoredâ€ * I think it's important for new contributors to see their work go into Ubuntu more quickly, the only thing that I think it should be improved is sponsoring, It takes some time to get someone work reviewed and uploaded to Ubuntu. * Anyone can jump on a bug, submit a fix for it, and have it accepted into the archive. * The most exciting things about being involved in development have most definitely been the UDS's. Documentation ============= The Documentation which has been a helpful resource for all new contributors. The improved developer portal (<a href="http://developer.ubuntu.com" target="_blank">developer.ubuntu.com</a>) provides useful tutorials like the packaging guide which have immensely helped contributors. The vast majority of replies mention it in a very positive light. The outreach and bug fixing initiatives were mentioned as great entry points as well. However, a contributor mentioned that too much documentation on our wiki is confusing, another contributor mentioned that the Ubuntu wiki could be more structured. * Generally, the wiki is really helpful here, especially with routine tasks such sponsorship for uploading (eg: <a href="https://wiki.ubuntu.com/SponsorshipProcess" target="_blank">https://wiki.ubuntu.com/SponsorshipProcess</a>). At this point I can't think of any easy way of improving this issue. However, a quick lookup page that lists all of Ubuntu development / packaging tasks are that links to existing documentation might be useful. However, I have always managed to look up what I have needed to find quickly with the various search tools. * What I think can be improved is the way the wiki is structured (or at least some of the pages on it). It looks like it contains all the information that is needed. But sometimes I just can't find what I am looking for and I have to go to google or ask on irc. * Documentation can always being improved. * The guys behind introducing new people to Ubuntu development have made it very easy for them to start contributing to Ubuntu, there is a lot of good documentation, a lot of training sessions on irc on <a href="http://ubuntuonair.com/" target="_blank">http://ubuntuonair.com/</a> nowadays no one should be afraid of contributing to Ubuntu. * There is a ton of great documentation, perhaps too much? * With the availability of great documentation made by Ubuntu developers, setting up my environment to start with Ubuntu development wasn't difficult at all for me. * There is a vast amount of knowledge in forms, wikis and how-to's. * The documentation and examples on how to make an SRU turned out to be less helpful than hoped, so I made a few beginner's mistakes that could have been avoided. * I really like the fact that I got quick feedback to my contributions. One thing that is really important for me is the bug fixing initiative wiki page and the fact that lately it seems to be updated regularly. * The community is also very helpful and there is a vast amount of knowledge in forms, wikis and how-to's. Outreach & People ================= We should take pride in the great feedback we received. Our processes, tools and documentation seem to work great for almost all our contributors. One thing we should be especially proud of is us as a community. Read the replies below: everybody seems to love working together with us. We received overwhelmingly positive feedback on fantastic help our developer community provides. More than majority of the contributors mentioned of our ever welcoming and helpful developers. A contributor writes â€œThe fact that actually someone took the time to review my patches, understand them, comment them and push them to ubuntu is greatâ€ . The #ubuntu-motu and #ubuntu-devel IRC channels have proved to be an indispensible resource for new contributors. Like one contributor said, â€œI have asked a simple question about packaging on IRC and in addition to the response, I have received a complete review of my packaging, with a clear list of all mistakes and what can be improved. I have appreciated a lot the discussion which was very friendly and helpful even if I was a total beginner 2 years agoâ€ , the developer community has always been an important factor in guiding new contributors through development in Ubuntu. A welcoming community it's still one of Ubuntu's proudest assets. * Thank you, it is great to have ones work noticed!! * it is really awesome to receive feedback like this when you don't expect it! * I really appreciate being contacted personally, it gives the impression that Ubuntu is a friendly and welcoming community. * People are very friendly and welcoming and vibrant. * The people that assisted me were helpful and encouraging. * from time to time people are unresponsive and you have to wait until someone else comes along. * My experience has been very positive, the ubuntu community it's a very welcoming place and being a known member before starting the work with the packaging helped me a lot. * The community is really really helpful in all work I've been doing - it's really easy to get information when there is a problem. * Community is always very responsive and all my questions are getting answered very quickly. * Everyone helps as much as possible, I really like that. Not only Canonical employees I mean the community as a whole. That's excellent. * The people helping me put everything in order so that didn't turn out to be a big issue. * So in perspective, Ubuntu got much friendlier, not only from a technical perspective, but also from an interaction level between requests and actual action. * "Mentoring moments"; when a "developer proper" takes time to guide one though a particular process (e.g. fixing a bug) is something I find extremely valuable an motivating. * I have asked a simple question about packaging on IRC and in addition to the response, I have received a complete review of my packaging, with a clear list of all mistakes and what can be improved. I have appreciated a lot the discussion which was very friendly and helpful even if I was a total beginner 2 years ago. * I felt a bit lost at the beginning because it was something I never did before, but had good advice and help from other members who pointed me to the wiki pages, explaining the process of pushing the changes to launchpad and submitting them to review for merge. * The fact that actually someone took the time to review my patches, understand them, comment them and push them to ubuntu is great because feels like the work you've been doing could benefit other people as well * Thankfully, the people helping me put everything in order so that didn't turn out to be a big issue. * I've known lots of people in the Ubuntu team, that have helped me a lot, and I've learned all that I know from them, this is the most positive thing. * All I've found a bit discouraging is the reliance on IRC participation; for example, at one point I'd prepared a package for REVU, but never managed to get anyone to look at it because I couldn't be on IRC at the appropriate time. * People (in the BugSquad, I did not talk to much other Ubuntu people) are friendly and helpful. (Newbie) questions are answered nicely, all in order to help one out and learn how Ubuntu development works. * People were very friendly and helpful. * Each time I interact on IRC or Launchpad, I have the same feeling, the communication is always smooth. * For a Debian maintainer, working in Ubuntu is very straightforward. I've never had much trouble getting sync requests approved, and in the more complex cases I've encountered (bootstrapping gcc-mingw-w64 in particular) other developers at home in Debian and Ubuntu have given me a hand. * The feedback feels quite constructive. * For the bulk of the work I've done so far, I've had a mentor (who was basically assigned to me). Someone who's been able to walk me through the dark arts of packaging and answer most of my questions when necessary. I suspect this is atypical of others who are just getting started with Ubuntu development. I consider myself lucky Highlights ========== Here are the highlights the Developer Advisory Team received in their inboxes. Totally worth a read! * There's a certain amount of satisfaction one can get out of writing software used by millions of people. * My experience working with Ubuntu has been overwhelmingly positive so far. * Thanks a lot for your review and the work you do to. Thats the kind of work needed to get more people easily involved in development of a complex operating system like Ubuntu! * It was the best experience I had in contributing to a linux distro. * It is a great platform to develop for. * My impression, not sure if I'm right or not, is that Ubuntu is very meritocratic, anyone can jump on a bug, submit a fix for it, and have it accepted into the archive * Contributing to Ubuntu is great beside knowing that your work is used by a lot of people around the glob makes you feel good, you're going to learn a lot of exciting new stuff like how your favorite OS works, how open source development works, you're going to have new friends, and of course you're going to have a lot of fun. * I like that everybody can fix bugs and add new features to software he uses. * I really do enjoy Ubuntu development, and love being able to create changes / fix bugs that help everyone else. Conclusions =========== The goal of the Ubuntu Developer Advisory Team is to reach out to new contributors. Over the course of the 12.10 development cycle, the team contacted many first time contributors offering our thanks for their work which helps to make Ubuntu better for millions of users. We also seek to identify stumbling blocks that might make participating in Ubuntu development be harder than it should. The Developer Advisory Team contacted the new contributors and solicited feedback on their experience with Ubuntu development. We asked three open ended question: 1. What was your general experience with Ubuntu development like? 2. What did you like about it? 3. What do you feel could be improved? The responses we received fell into five broad categories: 1. Tools & Infrastructure 2. Processes 3. Documentation 4. Outreach 5. People We reached out to 66 new contributors in total. Of these, 29 gave us their feedback on Ubuntu development, giving us a 43.93% response rate.