[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the DPL: DSA and buildds and DAM, oh my!

On Tue, Mar 13, 2007 at 01:09:12AM +0100, Frans Pop wrote:
>On Friday 23 February 2007 03:13, Anthony Towns wrote:
>> I'm trying to be descriptive here rather than prescriptive or
>> proscriptive [...]
>I appreciate the clear overview of the current status. I would also like 
>to say that I feel the people currently holding positions in the various 
>teams are all highly competent, have the best interests of Debian at hart 
>and do the work that is done well.
>However, the last few years I have also had a very strong conviction that 
>the teams are just too small, that too much - often minor and routine - 
>work is not getting done, or at least not getting done within a reasonable 
>time frame. And also that even within the teams certain tasks too often 
>depend on the availability of a single person instead of the members 
>fluidly taking over jobs that need doing from eachother.
>It is also a fact that the persons who are in these teams have for the 
>most part been part of them for a relatively long time already. They are 
>not the same persons they were when they started the job. Some now have a 
>lot less time available (or even to some extend conflicting priorities) 
>due to new jobs, others have gotten less motivated to work on Debian due 
>to changes in the project.

Yup, agreed in these 3 paragraphs.

>IMO setting up an RT system will not fundamentally solve any of this, but 
>will at most make it more manageable. The only way to solve this is by 
>having new blood in the teams, people who will take on the most boring 
>and routine tasks with enthusiasm because it is new and who bring fresh 
>ideas and the energy to implement them to the teams.

The idea behind the RT setup is to help us on the way to growing the
teams. It might sound unlikely to some, but I'm told there have been
problems in the past with people tripping over each other when trying
to work on tasks. We have multiple volunteers who want to help out; as
more people come on board who may not have worked together in the
past, the probability of coliisions grows substantially. That's one
place where RT will help. It will also allow people to keep better
track of what jobs have been requested and help in terms of feedback
to the requestors too. It's not a magic bullet (we all know that), but
it should help.

>Of course I understand that in these particular teams the project (and the 
>current members) want to make very sure that new members have the right 
>mentality as mistakes on any of the core project machines can have huge 
>consequences. Fine, but you cannot convince me that among the 100-150 
>more active developers there are not sufficient people that have shown 
>through their contributions, their attitude in discussions and so on that 
>they _are_ basically competent and trustworthy.

We have quite a number of volunteers already. We have a list of people
to get back to in order to try and organise things with them, and I
must admit that things are overdue on that front. It's time to get it

>This can be further guarded by having a trial period with mentoring by 
>existing members, by not giving out full authorizations immediately, and 
>by having very clear agreements about what jobs a new member can do by 
>himself, what needs to be reviewed by existing members, and what he 
>should absolutely not touch.

Yup, sounds eminently sensible.

>So, basically my question remains: why does it have to be so incredibly 
>difficult to allow new members into these teams?

Historical reasons as much as anything else. That's not an excuse, and
things should be improving soon.

Steve McIntyre, Cambridge, UK.                                steve@einval.com
We don't need no education.
We don't need no thought control.

Attachment: signature.asc
Description: Digital signature

Reply to: