Kubuntu Policies (for council consideration)

[Harald Sitter]

On Wednesday 26 February 2014 09:54:20 Jonathan Riddell wrote:
> On Tue, Feb 25, 2014 at 09:35:12AM +0100, Harald Sitter wrote:
> > On Mon, Feb 24, 2014 at 5:55 PM, Jonathan Riddell <jr at jriddell.org> wrote:
> > >> > It is useful to be able to add people to these teams where it eases
> > >> > beginning to contribute to Kubuntu (thinking sgclark currently), bzr
> > >> > branches can be easily reviewed. ~kubuntu-packagers
> > >> 
> > >> Indeed. There is a very discrete work flow for how one easily reviews
> > >> a branch. That's a merge, and adding people to pseudo teams at the
> > >> discretion of one council member is completely bypassing that. So, all
> > >> that does is make it very convenient for people to not easily review
> > >> the bzr branch at all, then upload, break things, giving me a
> > >> heartattack.
> > > 
> > > it's far more hassle to merge in a new branch, doing that 50 times makes
> > > a lot of hassle.> 
> > - bzr qdiff --new $REMOTE
> > - (review)
> > - bzr merge $REMOTE
> > 
> > that seems considerably more convenient than:
> > - bzr qlog
> > - (find revisions that are different)
> > - (review)
> > 
> > former even can be scripted easily?
> 
> That means new contributors will spend 6 months when we don't trust
> them enough to commit directly, 6 months when they are blocking on
> someone reviewing their work and 6 months when existing members have
> to put in time to review it.
> 
> Community made software needs processes which allow contributors to be
> brought in as soon as they are competant, otherwise they'll get
> frustrated, feel sidelined and leave.

To me the solution then seems to revise kubuntu-dev membership criteria and 
control? If they are competent and trustable enough they should become member 
of kubuntu-dev as that attributes technical knowledge (and could easily get 
added a 'technical trustworthy' attribute).

Currently ~kubuntu-members has absolute control over everything, regardless of 
technical ability. So if we were to divide the control up between ~kubuntu-
members (stuff that requires overall trust) and ~kubuntu-dev (stuff that 
requires technical knowledge and trust), it should nicely solve the problem 
you highlight?

Adding people to kubuntu-packaging/kubuntu-ppa directly really enforces a two-
class system which ought to be worse than not accepting them in for 6 months. 
Namely, they'd be good enough to do things on their own but really we don't 
want them to fiddle with the real meat (i.e. the archive).

HS