Re: [all candidates] Removing or limiting DD rights?
On 2013-03-25 10:22, Steve McIntyre wrote:
Are we strict enough with our existing contributors? When we're
to work together as best we can to make the Universal Operating
happen, what could/should we do with contributors who hinder our
Sometimes that hindrance is inadvertent, sometimes it seems
deliberate. At other times it looks like we have developers who are
just not paying attention to what they're doing or who just don't
about the goals of the project. Occasionally we see direct action to
censure or even expel DDs, but these are only ever in the most
of cases. By the time that happens, large amounts of damage may be
done to the project: delayed releases, lost users, loss of motivation
for other contributors.
I'm wondering: is this something that you think is a real problem,
if so what do you think we could do about it?
Yes, I think this is a real problem, and that we have a duty to deal
with these issues with our users and free software as our priorities,
not only the possible hurt feelings of our volunteers. (It's clear that
offending our volunteers can be very bad for our users, but the purpose
of Debian is not merely to keep its members happy.)
There are two aspects of what you mention here that I would like us to
avoid mixing up, though both could be described as "DD rights":
- technical permissions, including "ownership" of packages
- project membership.
In some (unfortunate) cases it may make sense for us to remove both
together, but this should be as a result of thinking about two separate
questions. In other cases it could make sense to remove someone's
project membership while leaving them with some limited specific
technical permissions to participate in our work, or to remove specific
technical rights while leaving someone a project member.
Although removing project membership is a much more serious step to
take, we have in some ways been more cautious about the smaller step of
restricting or removing specific technical permissions. Just as we
sometimes need to reconsider the benefit for the whole project of having
someone as a member, not only the benefit for that individual, I think
we sometimes we need to reconsider the benefit to the whole project of
someone keeping specific technical permissions that they have previously
acquired. Discussions around package "salvaging" could be counted as an
attempt to improve things in this respect -- not all the solutions need
to be top-down from the centre.
Another reason for trying to separate the two aspects above is that we
should avoid seeing them in the same light. Removing someone's project
membership against their wishes will remain a negative statement. But
removing some technical permissions can be done while we continue to
value the person's work in other areas, don't intend any personal
criticism, and are grateful for someone's previous work on an area. For
example, I would prefer that people always gave up specific jobs while
they were still doing them well, but it is sadly natural to continue
until available time and energy are lower, and then not to want to leave
the job while doing it badly, and an external nudge may be needed.
Where polite requests don't work, it may be better for the person if a
third party takes a swift decision than if there is a protracted public
discussion of the person's merits for the task, contributions made and
harms caused, etc.