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 <[email protected]> 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 -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
