Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[all candidates] Removing or limiting DD rights?
0 views
Skip to first unread message
Steve McIntyre
Mar 25, 2013, 12:30:03 PM3/25/13
to
Hi guys,
First of all, thanks to all three of you standing in the DPL election
this year. I know it's a daunting task! :-)
I've already seen some debate about how we could/should attract more
contributors, which is a perennial question in Debian. I personally
don't think we're ever likely to "solve" that issue permanently, but
it's clearly something that's always going to be very important for
us. I have a related question, but more on the opposite end of the
spectrum I suppose:
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. Occasionally we see direct action to
censure or even expel DDs, but these are only ever in the most blatant
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, and
if so what do you think we could do about it?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130325162...@einval.com
First of all, thanks to all three of you standing in the DPL election
this year. I know it's a daunting task! :-)
I've already seen some debate about how we could/should attract more
contributors, which is a perennial question in Debian. I personally
don't think we're ever likely to "solve" that issue permanently, but
it's clearly something that's always going to be very important for
us. I have a related question, but more on the opposite end of the
spectrum I suppose:
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. Occasionally we see direct action to
censure or even expel DDs, but these are only ever in the most blatant
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, and
if so what do you think we could do about it?
--
Steve McIntyre, Cambridge, UK. st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130325162...@einval.com
Lucas Nussbaum
Mar 25, 2013, 1:10:01 PM3/25/13
to
On 25/03/13 at 16:22 +0000, Steve McIntyre wrote:
> Hi guys,
>
> First of all, thanks to all three of you standing in the DPL election
> this year. I know it's a daunting task! :-)
>
> I've already seen some debate about how we could/should attract more
> contributors, which is a perennial question in Debian. I personally
> don't think we're ever likely to "solve" that issue permanently, but
> it's clearly something that's always going to be very important for
> us. I have a related question, but more on the opposite end of the
> spectrum I suppose:
>
> 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. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most blatant
> 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, and
> if so what do you think we could do about it?
I think that there's an unavoidable amount of such problems in a
> Hi guys,
>
> First of all, thanks to all three of you standing in the DPL election
> this year. I know it's a daunting task! :-)
>
> I've already seen some debate about how we could/should attract more
> contributors, which is a perennial question in Debian. I personally
> don't think we're ever likely to "solve" that issue permanently, but
> it's clearly something that's always going to be very important for
> us. I have a related question, but more on the opposite end of the
> spectrum I suppose:
>
> 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. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most blatant
> 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, and
> if so what do you think we could do about it?
large-scale volunteer-based project such as Debian. Solving those
problems is very hard, and I don't think that our current ways of
dealing with them can be improved much.
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.
Lucas
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gergely Nagy
Mar 26, 2013, 9:30:03 AM3/26/13
to
Steve McIntyre <st...@einval.com> writes:
> 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?
I do not believe we're strict enough, not in general. On the other hand,
> 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?
I'm not a big fan neither of overruling DDs, nor of limiting them. I'll
explain below.
> 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. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most blatant
> 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, and
> if so what do you think we could do about it?
fairly rare, and I certainly hope it will stay that way (and we really
should not let things get that far). However, causing damage (due to
negligence and/or lack of attention) is far more common, and is a real
problem, one we should be dealing with much, much better.
The salvaging effort was/is something that gave me great hopes, because
it approached the problem from a less personal angle. The less personal
an effort is, the more successful it can be in this case, as far as I
see. Telling people they're harming the project is a lot different than
telling them that a particular package needs more love, and then going
ahead to aggressively hug said package to give it more love. I think the
salvaging idea is something that we should push forward with,
aggressively. While this is not a solution to every problem, it would
help in quite a lot of cases. How well this works, also depends on the
people involved, so great care must be taken to avoid as many bruises as
possible. (But not at the expense of dropping it alltogether and doing
nothing! Better some bruises and a handshake months or years later than
silently holding grudges forever.)
But alas, salvaging will not solve everything, and in some cases, it is
likely not an option either. In those cases, we should not be afraid of
overruling the maintainer, and if need be, forcibly transfer the package
to someone else. Yes, this would also have consequences we'd rather
avoid, there would be bruises, but if there's no better option, when all
other kinds of negotiations failed, then I see no better option.
Negotiation is something we should perhaps be practicing more, and
earlier.
In short, we have the procedures to completely revoke or severely limit
DD powers, but this is a power we should exercise rarely. Instead, we
should work towards discovering problems much earlier, and work more
aggressively towards resolving them, before more harm's done. Among our
tools to help with this quest, we have salvaging, and once a problem's
discovered, earlier negotiation attempts, possibly involving the DPL as
a mediator.
--
|8]
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
gregor herrmann
Mar 26, 2013, 5:00:03 PM3/26/13
to
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.
> 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.
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.
Lucas' reponse already shows an idea that might also be used for
these cases:
> 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.
the necessity to improve the handling of "social problems") see as
viable?
Examples that have come up in the past and might or might not be
helpful:
- Encourage everyone to chime in when they see potentially
unacceptable behaviour? In public/private?
- Should we try to establish a Code of Conduct for project members?
Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
examples.
If yes, how would we do this, and how could we make sure it gets
respected?
- Could the CoC for mailing lists
(http://www.debian.org/MailingLists/#codeofconduct)
be used as a starting point / be extended?
- Or Enrico's Debian Community Guidelines?
http://people.debian.org/~enrico/dcg/index.html
- 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?
Short summary: Does Debian need procedures for intervening in cases of
dysfunctional social behaviour and which?
Thanks to all of you for standing/running in this vote, and for
taking the time to answer all these questions!
Cheers,
gregor
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
`- NP: Rod Stewart: Smile
Moray Allan
Mar 28, 2013, 11:50:01 PM3/28/13
to
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 are
> just not paying attention to what they're doing or who just don't
> care
> 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
> blatant
> 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,
> and
> 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
> 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. Occasionally we see direct action to
> censure or even expel DDs, but these are only ever in the most
> blatant
> 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,
> and
> if so what do you think we could do about it?
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
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Moray Allan
Mar 29, 2013, 1:10:01 AM3/29/13
to
On 2013-03-26 14:58, gregor herrmann wrote:
> 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).
While we rarely take formal action, I think that the "social" standards
> 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).
we apply to each other have increased over the years. And my impression
is that abrasive behaviour on the mailing lists or the main developer
IRC channels has significantly reduced over the years.
The more negative social behaviour that I remembering seeing recently
has tended to be in less visible places, for example in topic-specific
development IRC and in replies to individual bug reports. Those who I
saw behaving negatively may not have intended to be rude or aggressive
or dismissive, but people who are trying to help us and receive a
negative response in this way may be discouraged from further
involvement in Debian -- a single person with negative social behaviour
can scare off many potential contributors.
> What other ideas do you (plural, for all candidates, in case you see
> the necessity to improve the handling of "social problems") see as
> viable?
teams set extremely high standards that others wish to emulate, but I
realise that this won't solve every problem.
Looking at your list of ideas:
> Examples that have come up in the past and might or might not be
> helpful:
> - Encourage everyone to chime in when they see potentially
> unacceptable behaviour? In public/private?
help the person improve their behaviour, and not of trying to shame the
person. How public or private depends on the details of the situation
and the relationship of the person "chiming in" with the topic and with
the person they see as behaving unacceptably, and I don't think it's a
simple binary question -- but as the goal isn't to shame people, the
default should tend towards saying something in private.
> - Should we try to establish a Code of Conduct for project members?
> Cf. https://openhatch.org/wiki/Project_codes_of_conduct for
> examples.
> If yes, how would we do this, and how could we make sure it gets
> respected?
> - Could the CoC for mailing lists
> (http://www.debian.org/MailingLists/#codeofconduct)
> be used as a starting point / be extended?
> - Or Enrico's Debian Community Guidelines?
> http://people.debian.org/~enrico/dcg/index.html
respected or enforced. Perhaps people miss the final important points
because they come after a long list of more technical ones.
I've previously done some research on companies' and professional
organisations' written codes of behaviour. In my view the best ones
don't try to set out rules but offer a handful of concise and memorable
aspirations. A general "code of conduct" for Debian might be valuable,
but then it should cover more than only "social" issues, and some more
detailed guidelines would probably still be necessary in addition.
For an overall code of conduct, going through a formal process to adopt
it might be part of the point of having one (both to make people think
about it, and to increase the visibility of its adoption to people
outside the project), but it's also useful to have more detailed
guidelines that can be updated without formal agreement.
At the very minimum, more people should promote Enrico's Debian
Community Guidelines -- they don't need any more official status for you
to use and mention them, and thus influence other people to do the same.
> - 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'm unsure about the practicalities of creating one and keeping its
membership updated. If we were ever to move towards an elected board,
it might make sense for that group to take on this role as well as its
other duties. In that case the problem of defining what "social"
matters such a committee covered, and what powers it can use in
response, would be avoided, and the question of membership would be
reduced to a, by then, previously solved problem. While a general board
wouldn't be selected purely for "social expertise", it seems to me that
the overall composition of such a board would necessarily reflect the
project's "social" aspirations.
Even without us working out how to give special powers over social
matters to an appropriate group, a group like the proposed "ombudsman
team" could certainly help in some cases. It could help even more if it
was advertised as a contact point in some relevant places, as, for
example, a path to reduce the possibility of offended potential new
contributers walking away after they feel that they get a rude response.
> Short summary: Does Debian need procedures for intervening in cases
> of
> dysfunctional social behaviour and which?
respects might be helpful (for example to avoid offended new
contributors feeling helpless about it or assuming that Debian is just
univerally rude), but equally I don't think that in "social" matters it
makes sense to aim for a full and precise set of rules or a predefined
universal procedure for dealing with them.
--
Moray
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Gergely Nagy
Mar 30, 2013, 6:40:01 PM3/30/13
to
gregor herrmann <gre...@debian.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
> 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.
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
> viable?
> Examples that have come up in the past and might or might not be
> helpful:
> - Encourage everyone to chime in when they see potentially
> unacceptable behaviour? In public/private?
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, ow...@bugs.d.o 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
> examples.
> If yes, how would we do this, and how could we make sure it gets
> respected?
> - Could the CoC for mailing lists
> (http://www.debian.org/MailingLists/#codeofconduct)
> be used as a starting point / be extended?
> - Or Enrico's Debian Community Guidelines?
> http://people.debian.org/~enrico/dcg/index.html
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
time.)
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?
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?
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 :)
--
|8]
--
To UNSUBSCRIBE, email to debian-vo...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages