On 2013-03-25 10:22, Steve McIntyre wrote:
Are we strict enough with our existing contributors? When we're trying to work together as best we can to make the Universal Operating System happen, what could/should we do with contributors who hinder our work?Sometimes that hindrance is inadvertent, sometimes it seems deliberate. At other times it looks like we have developers who arejust not paying attention to what they're doing or who just don't careabout the goals of the project. Occasionally we see direct action tocensure or even expel DDs, but these are only ever in the most blatantof 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, andif 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.
-- Moray