Re: Two GR concepts for dicussion
On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote:
> Another thought. Sam's written about having more people in our core teams
> a few times, and no doubt will have more to say in the future; but a
> single person can only focus on helping one or two teams at any one time,
> and there's no limit to the number of teams that can have problems.
s/can (have problems)/will at some point $1/
> Maybe it's worth thinking about a more general solution than DPL
> intervention for helping teams that have calcified to grow and improve.
It should be noted that DPL intervention hasn't really been a solution so
far, only a option that nobody ever utilized. That's TTBOMK - someone
correct me if I'm wrong.
> My idea was to have an annual round where any DD could nominate themselves
> to join any team -- DSA, ftpmaster, maintenance of some particular
> package, www team, whatever. Acceptance would be automatic, provided:
>
> * no more than three people are joining the team (if so,
> the existing team can select three, or the DPL can if the
> existing team don't)
>
> * the role isn't "core", or the person isn't already involved
> in two or more other "core" roles (eg, ftpmaster assistant isn't
> core, ftpmaster is; release assistant isn't, release manager is)
>
> * the person can demonstrate some minimal existing competence
> in the area
>
> * the person is willing to agree in writing to make every
> reasonable effort to work with the existing team (which the
> DPL will enumerate on request)
>
> (That's intended to be in *addition* to the existing members of a team
> finding people to join in and help, not instead of it.)
To avoid the impression that this is something correlated with DPL
elections, and to give people more time, maybe it's best if it's done
every two years rather than ever year. Or, even better, let's mix it up
to have something more useful:
* prospective members can nominate themselves every four months
(avoids having to wait 2/3rds of a year, but also avoids people annoying
the team with repeated applications)
* any candidate has to pledge a minimum 18 months availability to the team -
to avoid people nominating just for kicks, giving up after a few months,
and essentially wasting team effort spent for training them
* each team can decide during every such nomination round to accept
a candidate, but it doesn't have to accept more than three people
every two years
* teams have to decide to mark old members who practically went away
(aren't participating a lot) as latent, but can unmark them as such
every four months
* latent team members count for 50% of an empty seat
That would be a bit conservative (but much more liberal than today),
and it sounds to me like it's viable.
It wouldn't necessarily have to be strictly obeyed, i.e. we don't need to
carve the exact verbiage into the constitution; the teams can have some
leeway, when I say four months I really don't care if it's 4*30 days or
4*29.57 days. I think it's fair to expect that people will observe the
general spirit of General Resolution as voted and published on vote.d.o,
and not try to horribly contradict it.
For reference, we haven't had new member of the debian-admin team in 5.5
years now[1], or a new member of the webmaster team in 2.5 years[2].
These two teams are certainly different and have different helpers and
circumstances and all, but both have been brought up in a recent -devel
discussion so I'm mentioning their raw numbers as two relevant data points.
Under this kind of a scheme, I think that there would have been a fair
bit of new blood accepted during that time, even under this conservative
scheme. At the same time, there wouldn't be an inappropriate burden on
existing team members in order to accept a major influx.
[1] the last addition was first documented in
http://cvs.debian.org/webwml/english/intro/organization.data?root=webwml&r1=1.65&r2=1.66&diff_format=h
but it could have been even longer since then
[2] http://cvs.debian.org/webwml/english/intro/organization.data?root=webwml&r1=1.158&r2=1.159&diff_format=h
> That has two major prerequisites in order to work: that we're *all*
> willing to give up some of the control we're used to exercising over our
> domain within Debian (whether that be a package or some infrastructure
> or a role or whatever);
I think it's worth mentioning at this point that infrastructure teams were
never supposed to be (benevolent) dictatorships like package maintainers.
Individual packages have to 'click' together with the rest of the system,
and on a grand scale, they are a common responsibility of us all, but
project infrastructure is nothing else other than a common responsibility
of all, there is very little room for having it not 'click' right.
So while it's reasonable to expect package maintainters to give up some
dictatorship prerogative, it's reasonable to expect infrastructure teams
to have a dictatorship prerogative in very few areas of their work.
> we expect all developers individually to be willing to work productively
> in a team and that we're willing and able to deal with people who are a
> destructive influence in teams.
The team members should reserve the right to remove someone who can't get
along, so this shouldn't be particularly contentious.
In case of major disputes, there's always a higher instance like the
leader (who can reasonably decide to "undelegate" people from a team
should the need arise), and maybe in the future, a social committee.
> Doing that by GR would help people understand how they can expect this
> to be dealt with in future, and would offer the reassurance that the
> project isn't out on a vendetta against a few maligned groups, but is
> really trying to do something that's fair on *everyone* in order to
> improve the project.
Agreed.
--
2. That which causes joy or happiness.
Reply to: