Kubuntu Policies (for council consideration)

[Harald Sitter]

On Wednesday 26 February 2014 11:09:56 Jonathan Riddell wrote:
> On Wed, Feb 26, 2014 at 11:21:49AM +0100, Harald Sitter wrote:
> > 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).
> 
> Membership of kubuntu-dev implies membership of kubuntu-members.  Asking in
> #ubuntu-devel just now
> 
> 10:30 < xnox> Riddell: to become a developer, one needs to show a
>               sustained contribution for more than one cycle, so yeah
>               6+ months is requirement for developers.
> 
> Allowing informal membership of kubuntu-packagers and kubuntu-ppa is a
> nice stepping stone to tell people they are valued and trusted
> contributors before we can give them full -membership or -dev
> privilages.
> 
> (And I still think 6 months is too long for -membership or -dev,
> building community needs letting people in without too much barrier,
> one of the aims of Ubuntu was to allow a lower barrier of entry than
> Debian.)

So it's a larger ubuntu issue and should be discussed as such.

Bringing me back to the original argument that if a person cannot be formally 
trusted and accepted into one of the existing teams, then everyone must review 
all new changes in every bzr branch before uploading as otherwise they might 
be uploading something that is not as good as it ought to be, or at the worst 
malicious content.

~kubuntu-packagers holds the qt packaging which is also meddled with by ubuntu 
developers who would rightfully assume that only formally trusted people can 
commit changes there. However, that would no longer be the case if we add 
people informally to that team simply because we decide to trust their 
abilities enough. So we'd then potentially lure !kubuntu members into 
uploading potentially bad or malicious content because they did not know that 
we have a lax policy on who gets to change the official packaging branches.

And that is why neither kubuntu-packagers nor kubuntu-ppa should be directly 
joined. We have trust validation processes in place (becoming kubuntu-dev or 
kubuntu-member), if the time barriers to join those are too long, then a 
resolution/exception should be sought in ubuntu at large, not work around the 
perhaps ludicrous barrier by allowing people to sneak in changes even though 
they really shouldn't be able to sneak in anything anywhere.

On a related note, what I just thought of: currently the exceptions read that 
manual additions to the teams happen at the discretion of the council, which 
is slightly silly if the argument is that individuals might be competent 
enough, as the only team able to asses that is ~kubuntu-dev and not ~kubuntu-
council.

HS