The below is a discussion from UDS Jaunty about existing developer processes. The whole summit was present

Ubuntu Developer Process Review

How well are the Ubuntu Developer application processes (becoming MOTU, Core-dev, etc) working? How can we improve them?

Room Survey

Who thinks the processes are too complicated?

• fta: Problem wasn't MOTU by itself, application was out of place, took him too long to process his application. Still not sure MOTU was the right thing to do for him, it's been blocking his way.
  • dholbach - main and restricted supported by Canonical, universe and multiverse is everything else, MOTU uploads to universe/multiverse, coredev can upload anywhere.
  • slangasek - We are running a session at 11 that addresses archive reorganization. To allow individidual contributors to have upload rights in a more fine grained manner. So individuals can have upload rights to a specific package.
    • - Tech board will approve upload rights - Includes the ability to allow a subset of packages. -
• jono - I can either go through MOTU or through core-dev and work on whatever part of the archive.
  • - persia - people are encouraged to go through MOTU first. - luke - you have to earn that trust since it affects millions of users. - pitti - lower barrier to get into MOTU - james - We need to maintain both levels of entry, MOTU is lower barrier - jono - sometimes a MOTU might feel like a second class citizen, like they are a different type of developer. (This is accurate and by design - core-dev is open to anyone who's up to it)
    • - no one in room raises hand, but he's gotten a lot of email about it.
    • - andy whitcroft - they are different, and by design - daviey - if you have to become a MOTU first, then it's a ladder. - NCommander - sometimes people get a lot of barriers, the process needs to be there to become core-dev without becoming MOTU - persia - MOst of the limitations should be addressed by archive reorg - slangasek - We have multiple channels, if people feel separate should we reconsolidate mailing lists and channels? - james - We have separate channels and separate processes - slangasek - We have to balance each other, archive reorg is not going to make a lot of that disappear. The distinction between MOTU/core-dev goes away in that case. - james - Split things based on the upload rights - luke - You earn the privilege to upload, it's still a trust thing. You earn the privilege and it can be taken away. - persia - It's better to use responsibility instead of right/privilege. If we can make one community that would be better. - hobbsee - Splitting the channels, ubuntu-devel is actual development, -motu is packaging. Maybe rename -motu to -packaging - mdz - -motu is a place to ask questions about development, not to actually do ubuntu-development. But core-devs have questions about packaging and stuff too - daviey - Are we trying to fix something that is not broken?

      - mdz - People raise your hands if you went through the process. Lower your hands if it went how you expected? (No one lowers hands). ie. people expected it to be rough. - SteveA - we need clearer steps - NCommander - unless you hunt someone down in IRC it can sit in the sponsorship queue for months, if it wasn't so slow it wouldn't be so bad. - jono - this was raised yesterday, do we feel that you want that sense with IRC we should ... - ted - It should just work as documented. 3 days. Otherwise there are issues where we have run into freezes. - NCommander - there are a lot of trivial patches that just sit there. - infinity - if there is a porting fix, there aren't a lot of people who can test this.

* Making people move closer to the mic.

• The sponsorship queue is too slow, without being aided by contacts. wgrant You really need one person to look after packages, not a general sponsorship process. This is really a problem in main. There is no clear ombudsman for the sponsorship queue, especially in universe. So many packages need to have a particular developer poked to look at it.
  • - many motu developers also don't spend enough time sponsoring random packages because a good deal may be ones they aren't familiar with

• !!JORGE, by battery is flat.!!
  • andrew - persia - dholbach - teams handle going through the sponsorship queue. slangasek - Canonical core-devs are told to look at main to go through the sponsorship queue as part of their workflow, fewer of us who work in universe. hobbsee - more of them going on in universe than in main slangasek - has there been any improvement? mdz - don't we have data for this? james - last time I looked universe queue was smaller than the main queue. dholbach - we've caught up, it used to be backed up slangasek - depends on where in the cycle we are. The person needs to understand expectations. persia - We need a consistent policy, when it belongs in the queue and when it belongs someplace else james - there needs to be a defined process
    • - when you assign a package to yourself you don't HAVE to upload it, just put it back in the queue eventually (but this makes it take longer) - if it's not suitable at least get it off the list
    nxvl - some sponsors are too picky with little things (ie misplaced comma in a change log) dholbach - We don't want additional round trips. Stevek - JFDI == Forwarding Patches to Debian ==
    • - some sponsorship should go into debian or other upstreams
      • - ? Could we make it more clear before packages end up in sponsorship queue?
    Could be better
    • People with direct upload rights tend to not submit their packages back to debian
    • mdz - what's the resolution on trivial changes? Let's put that to bed if people are fixing it for them so there's no round trip.
      • - the point of this process is to make it easier for people to contribute
      - dholbach - Upstreams aren't interested in going through our process - persia - - hobbsee - Send out what we expect our sponsors to do so it's clear - persia - documentation is out of date. - dholbach - I updated it - slangasek - concerns with passing on sending patches to debian without it first getting through the sponsorship queue. Debian themselves can be frustrating about accepting patches as well. So pushing contributors there might be bad as well. - NCommander- what about a sandbox in place to experiment with this?
      • - this was the idea behind "Grumpy" wasn't it? (way way way back in the day)
      - mdz - if only the packages were in bzr!! - some new guy - all you need is another queue? One per release? - pitti - let's keep this simple: could assign to self and then upload it after the release with current queue - ? - does the existing workflow in launchpad work for this?

Jono

Is there any consistencies on things that we need to improve that we can do today?

• Sponsorship queue - primary issue is man/womanpower
• Debian patches - Ncommander - how many people work on the sponsorship queue without being pinged on IRC - as part of their normal workflow. - dholbach - it's ok if people don't work on the queue in general but only get poked on IRC or just work on bug lists
  • --- But does that mean ANYONE is looking in the queue?
  - Jim Lieb - staggered by the processes in Debian when I first started with sarge. The change I think in the archive here, feels like going from owner/group metaphors to ACLs. If you have ACLs the person sponsor is experienced with it. So he does stuff on the kernel but should not be trusted to do java, groups should not block, we should be looking at it from the point of view of the packages, not the entire archive. jono - each package should have its own kind of assessment? rather than having a general sponsorship queue, have most packages going to specific groups of well-defined responsible people jim - I send my patches to a specific team (kernel), not a general queue. mdz - we have a higher ratio of packages to developers, we need to have a safety net for packages that don't have a particular person to find in Ubuntu. slangasek - firefox and the kernel are large projects with their own VCSes, if you're sending it to the sponsorship queue sometimes the patch belongs in upstream and we don't have commit rights to upstream projects. ncommander - team gets overwhelmed and a blocker slangasek - there shouldn't be any authoritative source

  YokoZar - who just normally looks at the sponsorship queue rather than waiting to be poked? (4 people)

  • - we have way more packages than developers - only way through the queue is to poke someone for most packages that are related to things someone has worked on - dholbach - we have several hundred packages going through the queue every month, so things are being processed.
    • -- though this includes people asked to specifically sponsor some packages
    - slangasek - main queue - oldest one in the queue was a month
• kirkland -
• mdz - it's important that this is an ongoing feedback keeps flowing, it's difficult for us to measure what it's like for new contributors, we need to hear from new contributors.
• jono - better way to get more feedback from our processes.
• nixternal - no one reads the docs, everything is documented. We can document until our faces turn blue, but people gotta read it.
  • - jono - we tend to fix problems by documenting it instead of making the process simpler. - where can we make the processes leaner?
• mdz - we need to find processes that can be removed when we review them
• kirkland - I lobby for some bit of objectivity, there's no guideline that says "before you're ready to apply" kind of checklist, like you've done this X times, that X times. (A broad trigger)
• mdz - why should they need to apply instead of "I think you're ready."
• persia - we should change the process so that we initiate the "you're ready".
• jono - This sounds clicheish
• mdz - projects I've been involved in has been that way
• slangasek - what problem are we trying to solve? - Jim - (DIGITAL UNIX story!) - Language called D. He's got a package in ubuntu, we should be focusing on getting that person involved: packaging is just the box it comes in, once it's running is all that matters. easier packaging, should be judging whether the package is good rather than the packager...
  • -- but we have 20,000 packages for 400 devs, 150 of which have upload rights, so that scale isn't quite going to work -- archive reorganication will help fix that -- slangasek - there is no community to care about the package.
  - Persia - there isn't a specific checklist of things to do, because there are different classes of patches and alot of this is subjective and flexible. - mdz - pull rather than push; risk of being cliquish is reduced compared with small projects - slangasek - what's distinction between clique and community?
  • - mdz - attitude
  - ? - I've actually read the documentation, and it makes me very cautious about applying to be a developer because it looks like a muddy process. We're very technical but can't define a clear set of what you need to do to get in (lintian and such aren't incomplete)
  • - - problem is we don't have a definition: it's about people rather than packages and such.
• dholbach - it's not so much about the bit in launchpad, we're fixing things for millions of users. core-dev and motu is about trust
• mdz - it's about building a relationship not counting numbers (ScottK - I second this idea)

- jono - this all comes down to trust.

• mdz - in the end how much you trust someone comes down little to what you know and what particular things you've done, it's more about the person
• ScottK - I'm convinced I got core-dev not at all because of what I knew technically (IMO it's not so much), but that I was trusted to know my limits, not break stuff much, and fix it when I did. (Read aloud to the crowd)
• - back in San Francisco 2 years ago we tried to make it more people based but have since veered off course
• Jono - we're risking making this process convoluted, but we should make it clear that I should show regular intentions and ability, right now we're getting a bit too process focused
  • - we should make our process as lean as we can get
• Jono - where should we be focusing our future efforts on discussion?
  • - answer: documentation, major barrier to entry, scares people away
• jono - some people have joined the project in good faith, but the time with the queue and such has scard them away

Persia - How to become one, How to learn the skills, Determining what one actually does. jono - problem we have right now is the time people are going through the queue is discouraging them to become involved. nand - do we have numbers? persia - universe is 250 bugs a week we process, I suspect half turn into uploads. dholbach - "MOTU Usability" - user-centric MOTU. humanity towards MOTU mdz - if we acknowledge that this is about trust in individuals, then it needs an individual basis - you can't build a relationship with a queue or even a group of people

• -? - sounds like the mentoring project - currently everyone who's asked has found a mentor, but we're running out of mentor manpower

? - we seem to form relationships by time zone, especially for people who are only around a few hours a day ? - this sounds like a social network ? - we like mentors to have different native languages so people use english more, which unifies the project and helps them reach out to other devs