Re: Community Team - where we want to go
Thanks for all the feedback already, folks - it's really appreciated!
Several of you have expressed reasonable concerns about a
non-delegated team of people setting themselves up as interpreters of
the CoC, and that's totally understandable. We *have* been applying
our own ideas about the CoC already, but so do many others in
day-to-day interactions. We see a wider role, though.
What we're definitely hoping to get to at some point is a delegation
from the DPL here. We know that we'll have to build trust with the
DPL, the project and the wider community to get there. Part of that
starts here: we want to openly talk about the role and
responsibilities that we see for the team now and in the
future.
Apologies if I wasn't clear enough in explaining this up-front! :-/
Now, responding to some of the individual points directly. This is
quite long, but I'd rather respond to grouped things together than
spam the list N times here.
I hope I've responded to people's points reasonably in this summary;
If you think otherwise then please point it out.
On Thu, Oct 10, 2019 at 10:08:55AM +0200, Mathias Behrle wrote:
>* Steve McIntyre: " Community Team - where we want to go" (Wed, 9 Oct 2019
> 22:26:39 +0100):
>>
>> * Proactively writing emails to those who habitually make the
>> community a hostile place, informing them that their behavior is
>> harmful to the community, that action may be taken in the future,
>> and that the Community team is a resource to provide explanation or
>> guidance.
>
>What does mean "that action may be taken in the future"? Which actions in which
>context does the team want to perform? Is this a pure informal step about
>actions of other teams? I think the following negative list is not the way to
>go, but a clear statement should be made.
As Martina explained - we don't expect nor want powers to take direct
action if people are disruptive and not following the CoC. What we
will do is try and warn people that we think they are not behaving
according to our agreed standards and (*importantly*) give suggestions
on how they might improve. If that doesn't work, we will share our
feelings with those teams in Debian that do have powers: listmaster,
Planet admins, maybe DAM in extremis.
This is a perfect example:
On Thu, Oct 10, 2019 at 11:57:21AM +0200, Gerardo Ballabio wrote:
>Enrico Zini wrote:
>>> * Remove blogs from community forums like Planet Debian
>>
>>This I think is something the team could actually do, just as any Debian Developer could do it, having commit access to the planet config.
>
>While technically they have the ability to do that, they are not
>allowed to. Reading from
>https://wiki.debian.org/PlanetDebian#How_do_I_add_myself_to_Planet.3F
>:
>
>"Any contributor may add, amend or remove *their own* blog entry from
>Planet Debian." (emphasis in the original text)
>
>I.e., they may not remove other people's blog. Only Planet admins can do that.
ACK - we'd instead talk to Planet admins to share concerns if needs
be.
On Thu, Oct 10, 2019 at 11:00:43AM +0200, Gerardo Ballabio wrote:
>Steve McIntyre wrote:
>> Within the team, we've brainstormed about this and come up with the
>> following to describe our role and responsibilities. We'd like to
>> discuss it now wit h the rest of the project. Feedback welcome
>> please!
>
>that looks good (I especially like the "Examples of things the team
>does *not* do"), but I think you should also add something on how the
>team will be handling confidential information that it's going to have
>access to as part of its job.
>
>I suppose it won't be easy to strike a good balance between the right
>to privacy, the right of accused people to know what they're accused
>of and by whom and to defend themselves, the right of victims to not
>having to confront their abusers, and so on. So this deserves to be
>thought through carefully and clear guidelines should be set.
Agreed. It's not an easy situation. We've already been talking to the
privacy team to get advice on sensible ways to do this. We will
describe our workflow and guidelines more fully as that comes to
fruition.
On Thu, Oct 10, 2019 at 09:18:07PM +0900, Charles Plessy wrote:
>Le Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre a écrit :
>>
>> The (CT) is the team responsible for interpreting the Code of Conduct
>> (CoC) when necessary.
>
>Like others and for the same reasons, I think that to be responsible for
>interpretation it would necessitate a delegation. I would like to add
>if you follow that direction, then it would be better that the team does
>not take responsabilities such as judging the behaviour of others, that
>would lead it to be both raising a question of interpretation and giving
>an authoritative answer at the same time.
I've had similar feedback privately from somebody else, and I
understand the idea. My main worry with separation like this is
finding yet more volunteers to do two jobs rather then the one we
envisage.
In the vast majority of cases, we *expect* to be simply giving advice
to people when we think they might not be following the CoC. We'd be
happy to help interpret the CoC when people ask us to, as well. For
cases where advice and warnings are not having the effect we'd hope,
we'll share concerns with other appropriate teams and discuss
them.
>> Where desired, the team will work with contributors to help them
>> express disagreement without violating the CoC.
>
>I think that providing behavioural guidance is an excellent goal.
>However I think that it will be more effective by addressing the
>community in general. To be frank, I do not have the impression that
>the people who usually express themselves "bluntly" will actively seek
>your advice.
Nod, agreed.
>> When people do breach the CoC, the team will give guidance on better
>> ways to interact in the future.
>
>I also feel that it is important that people are being explained when
>they hurt others. But I have one comment and one question:
>
> - Given what happened in the past, I think that it is crucial that
> there is a crystal clear difference between being given guidance and
> being given a warning. For instance, it could be that any message
> from the CT is not a warning unless stated otherwise.
+1
> - I think that it is bound to happen that one day, a message of
> guidance will be badly received, and will lead the receiver to behave
> worse than if they did not get a message. What is your plan in that
> case ?
That's a really good question, and thanks for asking it. We've already
been discussing how to grow our team and make more effective use of
volunteer time. Part of that would involve a subset of the team
handing each case initially, with the option to then escalate and call
in more opinions and more help when needed. If there is a real problem
with people disgreeing with us strongly and behaving worse when given
advice, we will share our concerns with other teams. We genuinely
don't want to get that far in most cases, of course - we're trying to
improve the community, not get into arguments.
>> * Responding in a timely manner to incidents reported by members of
>> the Debian community and those interacting with the Debian project;
>
>This timeliness is extremely important and I think that it is great that
>you mentionned it. In case of overload, I think that timeliness should
>be given priority over exhaustiveness. That is: drop the less grave
>cases if there is no time to respond to all at the same time.
You're reading my mind. :-)
On Thu, Oct 10, 2019 at 11:16:59AM +0200, Enrico Zini wrote:
>
>I believe strongly that anyone who is /the/ person/team responsible for
>interpreting the Code of Conduct needs to gain that responsibility from
>an official delegation, and absent a delegation, I believe that the only
>person ultimately responsible for interpreting the CoC when necessary is
>the DPL, overridable by a GR.
>
>However, I also believe that any member of the Debian community is
>responsible for upholding the Code of Conduct, and I'm fine with the
>idea that one or more people or groups could make themselves available
>to help with CoC interpretation or supporting people if things get
>heated.
>
>At that point, however, the CoC interpretation is not a responsibility
>but an offer of help, whose value can maybe come from experience and
>reputation of a person or team members inside the project.
Yup, of course. That's where we are now, with a path to eventual
delegation in mind.
>> Finally, the CT will also work in combination with event organisers to
>> deploy incident response teams on the ground and ensure that the CoC
>> is observed for Debian events.
>
>In the same light as above, I suggest s/work/make itself available/, as
>any other group could make themselves available to event organisers to
>help with Debian or event-specific CoC.
Sure, it's a volunteer setup. We've already been working with event
organisers for a while so we have some relevant experience but we're
not so arrogant as to say we're the only ones who can help here!
>> * Take punitive measures or actions against members of the Community.
>
>I find this point a bit tricky, because I think that what is "punitive"
>is up for subjective interpretation. For example, feeling forced to
>engage with individuals wearing a Community Team badge could already be
>seen by some as a punitive measure.
>
>You may want to remove this point entirely, as it's mostly covered by
>the other examples of what the team does not do.
Possibly, yes. Fair point.
>Some more general feedback points.
>
>I suggest to review your notes with the idea that there could be two or
>more such teams in Debian posting the same set of notes, and they
>shouldn't conflict.
>
>Also, given the idea that there can be multiple groups doing this, the
>name "Community Team" sounds possibly problematic name to me, as it
>hints indeed at being /the/ team for Debian Community issues, which
>could potentially be setting the wrong kinds of expectations.
>
>Although I would prefer a name that would make it explicit that we're
>talking about /a/ /self-appointed/ group, I wouldn't consider the naming
>a blocker: I know names are hard, and I don't want you all to spend your
>energy picking names.
>
>Still, I'd acknowledge and keep in mind that the name does sound
>ambitious, and as a consequence I'd expect you all to be extremely
>careful in all team descriptions and team actions to make it clear that
>you are /a/ community team, not /the/ community team.
I know what you're saying, but I think this is covered by our goal of
heading towards delegation. I'd be very concerned about duplication of
effort and maybe clashes if we had more than one Community Team group
working within our project. Hey, let's collaborate - it's what we do
in Debian!
On Thu, Oct 10, 2019 at 11:14:41PM +0200, Steffen Möller wrote:
>A community team is a good thing. Just its apparent focus on the Code of
>Conduct is unfortunate. The biggest modulators of how we interact among
>ourselves and how much inviting we are perceived as a community imho
>currently are (somewhat ordered):
>
> * salsa
>
> * blends
>
> * debconfs
>
> * sprints
>
> * patches by .deb maintainers on github/bitbucket/...
>
> * news on Debian being adopted by some 3rd party for something fancy
>
> * our discussion on the mailing lists
>
>And I want more of that. I wish the Community Team comes up with new
>ideas that are all positively minded. The CoC is somewhere out there but
>luckily not omnipresent. I have some confidence that no (zero) DM/DD
>enjoys to be meeting regularly in some group to discuss that CoC and its
>application ... this is just nothing why we are here. And consequently
>DDs distrust other DDs that volunteer to be on such a team. So, have
>your Meta Team and talk about how to evolve our togetherness. That shall
>involve having an eye on that we are no intentionally or unintentionally
>hurting each other in our communication but should by no means dominate
>what that team is about.
Fair enough! As I hope I've explained, we're hoping to improve how our
community interacts, to make Debian a more welcoming place. We don't
claim to have a monopoly on good ideas and good intentions, and we
genuinely hope that all Debian contributors and community members will
want to do this too, naturally. We do worry about the CoC here, for
those small numbers of cases when things *don't* go so well.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"War does not determine who is right - only who is left."
-- Bertrand Russell
Reply to: