Re: [all candidates] Removing or limiting DD rights?
gregor herrmann <firstname.lastname@example.org> writes:
> On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote:
>> On 25/03/13 at 16:22 +0000, 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 are
>> > just not paying attention to what they're doing or who just don't care
>> > about the goals of the project.
> Thanks for this question, which I would like to extend a bit.
> Im my understanding you are pointing to unconstructive behaviour
> related to technical work. What we also see (and discuss) every now
> and then is behaviour that is socially questionable or clearly
> unacceptable (from disrespect for peers to blatant abusive language).
> I guess we all remember such examples, which have led to
> demotivation, frustration, hurt feelings, and have driven
> contributors away.
Indeed, I do remember. But - like Moray - as far as I see, this happens
fewer times than it did in the past, at least on the most public lists
(it does happen nevertheless, especially in those long threads we all
know and "love"...). This being less of an issue than it was a decade
ago, is good. There's certainly room for improvement, nevertheless.
>> One small thing that we could improve on is earlier official
>> communication. For example, in case of seriously problematic behaviour
>> that could eventually lead to censure or expulsion, official warnings
>> could be issued to the DD, and Cced to -private@. In some cases, that
>> could help the DD realize that s/he needs a behaviour change, and also
>> limit the surprise effect if/when a final decision is taken.
> What other ideas do you (plural, for all candidates, in case you see
> the necessity to improve the handling of "social problems") see as
I'll answer your specific answers first:
> Examples that have come up in the past and might or might not be
> - Encourage everyone to chime in when they see potentially
> unacceptable behaviour? In public/private?
The problem with this is that multiple people independently chiming in
has the tendency to make things worse. A more coordinated effort would
help that, and if we had single coordinating contact point to help,
that'd be great. (These do exist, email@example.com and listmaster@, as Don
mentioned earlier, but I am as of yet, unsure whether they're used this
way, and how often.)
I would encourage chiming in privately, and in a coordinated manner,
with a single statement publicly, to discourage others from public
flaming (and instead, point them towards the coordinated effort).
> - Should we try to establish a Code of Conduct for project members?
> Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
> If yes, how would we do this, and how could we make sure it gets
> - Could the CoC for mailing lists
> be used as a starting point / be extended?
> - Or Enrico's Debian Community Guidelines?
I'm not a terribly big fan of Codes of Conduct, because they're vague
and very, very general, and as such, subject to interpretation. What I
would consider a flame, or common sense may be much different than
someone else thinks. I've grown up on IRC, and frequented channels where
foul language and flames were a daily show (and I'm not ashamed to
admit, that I enjoyed these, one could learn a lot about how not to
behave, and what triggers a flame. I found it very educational at the
Enforcing the CoC is also quite a big task. However, there's one good
thing about them: they send a message, that we're serious about
caring about and nurturing our community. For that reason alone, a CoC
is worth it.
I do like Enrico's guidelines though. Something along those lines, and
the mailing list CoC would make sense, in my opinion. Perhaps both! A
CoC, a short, generic code, and the Guidelines, for more in-depth
suggestions. The Guidelines would be treated only as such, though -
guidelines, not enforcable, but a reasonable basis of peace talks.
> - Another recurring topic is the Social Committee, cf. e.g.
> https://lwn.net/Articles/221077/ (or the ombudsman team mentioned
> in the article:
> https://lists.debian.org/debian-project/2007/01/msg00101.html )
> Would such a body make sense? With which powers?
I would find such a body useful, but not in the way it is explained in
Gustavo's mail (there's quite a few things I disagree with, like a
public pseudo package in the BTS for the task).
As for powers - I would not wish to grant the body any particular power,
but rather, ask them to channel issues to the DPL, and they together
would decide how to proceed, with the possibility of the DPL granting
the body the power to go forward with their decision. This doesn't mean
they wouldn't be allowed to talk to offenders or anyone else they wish
to involve, it just means that I would not wish to permanently grant the
team the power to, say issue warnings to DDs.
However, I'm open to discuss the issue further, the above is just my
opinion at the moment, I can be swayed with good arguments, and powers
can be granted at a later time too, if that becomes a better option.
> Short summary: Does Debian need procedures for intervening in cases of
> dysfunctional social behaviour and which?
Yes, we do. A combination of a Code of Conduct, Enrico's guidelines, and
a soc-ctte would be close to ideal, in my opinion. However, I'd rather
not go into details, because this needs to be a project-wide decision,
involving a lot more people, and the campaign period is likely not the
best time to discuss this in detail :)