Understanding the definitions and expectations of our membership processes

[Robert Collins]

On Thu, Jul 28, 2011 at 10:04 AM, Chase Douglas
<chase.douglas at canonical.com> wrote:
> The other thing that I forgot to mention is that moving to a "trust"
> model of requirements resolves the issue that I face: acceptable for
> core-dev, but not for motu, and thus I'm not acceptable for core-dev. I
> was told that I would be strongly considered for core-dev because of the
> amount of work I've done on packages in main. However, core-dev implies
> MOTU, and since I haven't done any (well, very little) universe work, I
> couldn't be a MOTU. Hence, I'm stuck, and I seriously have no extra time
> in the day to do any universe work.

We've had a trust model going -way- back (e.g. in discussions about
MOTU membership back at UDS google, I distinctly remember exactly that
theme).

So I wouldn't say 'moving to a "trust" model of...' - we certainly
/had/ one, where we wanted a combination of trust (will do the right
thing, won't abuse privileges, knows when they are out of depth) and
-enough- technical competency, and -significant, sustained-
contribution.

Perhaps we've had a slow evolution of the assessments to look more at
proven technical competency than trust; and if so, I think thats a
mistake. Lets get back to the basics:
 - is the person contributing to Ubuntu in the long haul [yes, then
they should be a member]
 - are they trust worthy enough to let them upload to the primary
archive [yes, then they should get -some- upload rights, whether that
is PPU, MOTU or core]
 - are they technically competent to upload directly to 'main' ? [yes, core-dev]

-Rob