Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11090 > unrolled thread

Community Team - where we want to go

Back to article view | Back to linux.debian.project

Contents

  Community Team - where we want to go Steve McIntyre <93sam@debian.org> - 2019-10-09 23:30 +0200
    Re: Community Team - where we want to go Norbert Preining <norbert@preining.info> - 2019-10-10 02:50 +0200
      Re: Community Team - where we want to go Jonathan Carter <jcc@debian.org> - 2019-10-10 08:00 +0200
    Re: Community Team - where we want to go Scott Kitterman <debian@kitterman.com> - 2019-10-10 08:30 +0200
    Re: Community Team - where we want to go Mathias Behrle <mathiasb@m9s.biz> - 2019-10-10 10:10 +0200
    Re: Community Team - where we want to go Enrico Zini <enrico@enricozini.org> - 2019-10-10 11:20 +0200
      Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-10-10 13:50 +0200
        Re: Community Team - where we want to go Steffen Möller <steffen_moeller@gmx.de> - 2019-10-10 23:20 +0200
          Re: Community Team - where we want to go Steve McIntyre <steve@einval.com> - 2019-10-12 01:50 +0200
    Re: Community Team - where we want to go Charles Plessy <plessy@debian.org> - 2019-10-10 14:20 +0200
    Re: Community Team - where we want to go Karsten Merker <merker@debian.org> - 2019-10-10 16:20 +0200
    Re: Community Team - where we want to go Lucas Nussbaum <lucas@debian.org> - 2019-10-10 17:10 +0200
    Re: Community Team - where we want to go Martina Ferrari <tincho@debian.org> - 2019-10-11 06:10 +0200
      Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-10-11 13:30 +0200
        Re: Community Team - where we want to go Guillem Jover <guillem@debian.org> - 2019-10-12 04:10 +0200
          Re: Community Team - where we want to go Enrico Zini <enrico@enricozini.org> - 2019-10-14 13:50 +0200
            Re: Community Team - where we want to go Guillem Jover <guillem@debian.org> - 2019-10-14 15:30 +0200
            Re: Community Team - where we want to go Enrico Zini <enrico@enricozini.org> - 2019-10-14 15:30 +0200
      Re: Community Team - where we want to go Sean Whitton <spwhitton@spwhitton.name> - 2019-10-11 23:30 +0200
    Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-10-21 13:40 +0200
      Re: Community Team - where we want to go Holger Levsen <holger@layer-acht.org> - 2019-10-21 14:00 +0200
        Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-10-21 15:40 +0200
          Re: Community Team - where we want to go Holger Levsen <holger@layer-acht.org> - 2019-10-21 16:10 +0200
            Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-10-21 16:30 +0200
      Re: Community Team - where we want to go Enrico Zini <enrico@enricozini.org> - 2019-10-23 13:00 +0200
    Re: Community Team - where we want to go Wouter Verhelst <wouter@debian.org> - 2019-11-08 20:30 +0100
      Re: Community Team - where we want to go Charles Plessy <plessy@debian.org> - 2019-11-14 23:10 +0100
        Re: Community Team - where we want to go Sam Hartman <hartmans@debian.org> - 2019-11-15 02:30 +0100
      Re: Community Team - where we want to go Martina Ferrari <tincho@debian.org> - 2019-11-14 00:00 +0100

Page 1 of 2  [1] 2  Next page →

#11090 — Community Team - where we want to go

Hi folks,

We've had a lot of conversations this year about where the
Anti-Harassment (now *Community*) Team should be going: what we're
trying to do, and the relationship we'd like to have with the rest of
the project and the wider community.

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 with the rest of the project. Feedback welcome please!

Name: Community Team
====================

Role
====

The goal of the Community Team (CT) is to help Debian be a welcoming
place, focusing on response to difficult or contentious
communications, as well as other negative experiences and Code of
Conduct violations. It aims to encourage and foster a respectful,
productive, and inclusive atmosphere throughout the Debian community.

The team itself has no direct powers to enforce any decision, and
merely acts as an advisory body. It will aim to respond in a timely
matter when consulted, and to do so in a consistent way. The (CT) is
the team responsible for interpreting the Code of Conduct (CoC) when
necessary.

The team will respond to concerns raised by members of the project or
people interacting with them, working with individuals to help
them. The team recognises that technical development can lead to
arguments and passionate discussions. Where desired, the team will
work with contributors to help them express disagreement without
violating the CoC. When people do breach the CoC, the team will give
guidance on better ways to interact in the future. We will attempt to
consult with those on all sides of issues when possible. Nevertheless,
protection of the vulnerable and the community as a whole is the
ultimate goal of the team.

If things do not work out, and in cases with a pattern of repeating
problems, the team will raise concerns with other teams as
appropriate.

Members of the community should feel empowered to seek counsel when
they have doubts about the CoC, or when they feel it is being
violated. The team normally acts reactively, but might also try to
intervene when individual members witness a problematic situation.

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.

We break this down in more concrete terms:

Responsibilities include
========================

 * Interpreting the Code of Conduct;

 * Responding in a timely manner to incidents reported by members of
   the Debian community and those interacting with the Debian project;

 * Contacting individual contributors about their behavior when it is
   considered to be in violation of the Debian Code of Conduct;

 * Providing support and guidance for event incident response teams;

 * Offering advice and guidance for policies and implementation around
   community standards and guidelines;

 * Being available as a resource for those looking for content review
   of communications or who have questions about how possible actions
   may fit with the Code of Conduct;

 * In extreme incidents or after repeated harmful behaviour or Code of
   Conduct violations, writing reports for relevant teams (e.g. Planet
   admins, listmasters, DAM), to summarise relevant incidents along
   with analysis and suggested possible courses of action; and

 * Where there might be a Conflict of Interest, individual members of
   the team will be expected to inform the rest of the team, about it
   and recuse themselves from relevant discussion.

Examples of team activities
===========================

 * Releasing regular reports on incidents reported and the responses
   of the team;

 * Providing recommendations on communications when recommendations
   are sought by members of the community;

 * Quick response time alerting reporters that action might be taken;

 * Holding regular meetings (and emergency meetings, when relevant),
   to discuss incidents reported and actions to be taken;

 * Writing and providing reports to other teams concerning incidents
   or habitual behaviors; and

 * 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.

Examples of things the team does *not* do
=========================================

 * Remove blogs from community forums like Planet Debian

 * Ban users and contributors from email lists or other communication
   channels;

 * Take preventative action on mailing lists when an incident report
   does not come in, excluding general reminders to email lists about
   the Code of Conduct;

 * Mediate communications or conversations between individuals; or

 * Take punitive measures or actions against members of the Community.

Members of the Community Team may of course participate in discussions
as individual contributors to the Debian Project, and will not always
be expressing the views of the Community Team.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

[toc] | [next] | [standalone]

#11092

Hi

On Wed, 09 Oct 2019, Steve McIntyre wrote:
> Name: Community Team

> The team itself has no direct powers to enforce any decision, and
> merely acts as an advisory body. It will aim to respond in a timely

> Responsibilities include
>  * Interpreting the Code of Conduct;

As "just another group of Debian Developers" I am not sure how you can
usurp the right to exegesis of the CoC? What about if another group XYZ
(like the Debian TeX Team) decides that our responsability is
	Interpreting the Code of Conduct
?

Same old people under new name ...
Same old wine in new bottles ...
Nothing has changed.

Best

Norbert

--
PREINING Norbert                               http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[toc] | [prev] | [next] | [standalone]

#11093

On 2019/10/10 02:40, Norbert Preining wrote:
> As "just another group of Debian Developers" I am not sure how you can
> usurp the right to exegesis of the CoC? What about if another group XYZ
> (like the Debian TeX Team) decides that our responsability is
> 	Interpreting the Code of Conduct

Yep, any group in Debian can read and interpret the Debian CoC, likely,
probably anyone who ever reads it might have their own interpretation of
the CoC. What the community team is effectively doing here is just
offering a service to do so, they're not imposing an authority of how
every CoC violation should be handled. Instead, if you as part of any
leadership role in Debian (maybe the DPL, maybe a member of a team) are
seeking some feedback, you can use the community team as a sounding
board to get their view on it. At least, that's my understanding.

> Same old wine in new bottles ...

Some wine'ing has gotten old a really long time ago.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

[toc] | [prev] | [next] | [standalone]

#11094

On Wednesday, October 9, 2019 5:26:39 PM EDT Steve McIntyre wrote:
> Hi folks,
> 
> We've had a lot of conversations this year about where the
> Anti-Harassment (now *Community*) Team should be going: what we're
> trying to do, and the relationship we'd like to have with the rest of
> the project and the wider community.
> 
> 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 with the rest of the project. Feedback welcome please!

>From what does the team believe they derive their authority to do things like 
interpret the CoC and to whom is the team accountable?

Scott K

[toc] | [prev] | [next] | [standalone]

#11095

[Multipart message — attachments visible in raw view] — view raw

* Steve McIntyre: " Community Team - where we want to go" (Wed, 9 Oct 2019
  22:26:39 +0100):

Hi!

> 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 with the rest of the project. Feedback welcome please!

Like others I have some concerns whenever it comes to "responsibilities". I
would feel a lot more comfortable if this term could be replaced by "team
agenda".

> Name: Community Team
> ====================
> 
> Role
> ====
> 
> The goal of the Community Team (CT) is to help Debian be a welcoming
> place, focusing on response to difficult or contentious
> communications, as well as other negative experiences and Code of
> Conduct violations. It aims to encourage and foster a respectful,
> productive, and inclusive atmosphere throughout the Debian community.
> 
> The team itself has no direct powers to enforce any decision, and
> merely acts as an advisory body. It will aim to respond in a timely
> matter when consulted, and to do so in a consistent way. The (CT) is
> the team responsible for interpreting the Code of Conduct (CoC) when
> necessary.

This sounds like the team would represent the last resort when it comes to
interpretation of the CoC. In my understanding the interpretation of the CoC
may be an important tool for the work inside the team, but there is in no way a
project wide responsibility assigned.

> The team will respond to concerns raised by members of the project or
> people interacting with them, working with individuals to help
> them. The team recognises that technical development can lead to
> arguments and passionate discussions. Where desired, the team will
> work with contributors to help them express disagreement without
> violating the CoC. When people do breach the CoC, the team will give
> guidance on better ways to interact in the future. We will attempt to
> consult with those on all sides of issues when possible. Nevertheless,
> protection of the vulnerable and the community as a whole is the
> ultimate goal of the team.
> 
> If things do not work out, and in cases with a pattern of repeating
> problems, the team will raise concerns with other teams as
> appropriate.
> 
> Members of the community should feel empowered to seek counsel when
> they have doubts about the CoC, or when they feel it is being
> violated. The team normally acts reactively, but might also try to
> intervene when individual members witness a problematic situation.
> 
> 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.

For me it is beyond the tasks of the team to *ensure* the observation of the
CoC on Debian events. This sounds again like an official assignment that in
reality doesn't exist.
 
> We break this down in more concrete terms:
> 
> Responsibilities include
> ========================

Please make this unambigous. From what I see (I am not a native speaker) the
term "responsibility" comprises a wide spectrum of meanings like:
accountability, liability, charge, ownership, stewardship, duty, obligation,
business, etc.. I would personally feel much better with a term like 'self
identified tasks of the team'.

>  * Interpreting the Code of Conduct;
> 
>  * Responding in a timely manner to incidents reported by members of
>    the Debian community and those interacting with the Debian project;
> 
>  * Contacting individual contributors about their behavior when it is
>    considered to be in violation of the Debian Code of Conduct;
> 
>  * Providing support and guidance for event incident response teams;
> 
>  * Offering advice and guidance for policies and implementation around
>    community standards and guidelines;
> 
>  * Being available as a resource for those looking for content review
>    of communications or who have questions about how possible actions
>    may fit with the Code of Conduct;
> 
>  * In extreme incidents or after repeated harmful behaviour or Code of
>    Conduct violations, writing reports for relevant teams (e.g. Planet
>    admins, listmasters, DAM), to summarise relevant incidents along
>    with analysis and suggested possible courses of action; and
> 
>  * Where there might be a Conflict of Interest, individual members of
>    the team will be expected to inform the rest of the team, about it
>    and recuse themselves from relevant discussion.
> 
> Examples of team activities
> ===========================
> 
>  * Releasing regular reports on incidents reported and the responses
>    of the team;
> 
>  * Providing recommendations on communications when recommendations
>    are sought by members of the community;
> 
>  * Quick response time alerting reporters that action might be taken;
> 
>  * Holding regular meetings (and emergency meetings, when relevant),
>    to discuss incidents reported and actions to be taken;
> 
>  * Writing and providing reports to other teams concerning incidents
>    or habitual behaviors; and
> 
>  * 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.

> Examples of things the team does *not* do
> =========================================
> 
>  * Remove blogs from community forums like Planet Debian
> 
>  * Ban users and contributors from email lists or other communication
>    channels;
> 
>  * Take preventative action on mailing lists when an incident report
>    does not come in, excluding general reminders to email lists about
>    the Code of Conduct;
> 
>  * Mediate communications or conversations between individuals; or
> 
>  * Take punitive measures or actions against members of the Community.
> 
> Members of the Community Team may of course participate in discussions
> as individual contributors to the Debian Project, and will not always
> be expressing the views of the Community Team.


-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

[toc] | [prev] | [next] | [standalone]

#11097

[Multipart message — attachments visible in raw view] — view raw

On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote:

I join other respondents, with a risk of redundancy, with a few notes
due to the decision of not having delegated powers and being an
undelegated advisory group.


> The (CT) is the team responsible for interpreting the Code of Conduct
> (CoC) when necessary.

I feel strongly against this: "The team" hints at being the only team,
and "Responsible" hints at having power.

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.


> 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.


> Responsibilities include
> ========================

I agree with what Mathias Behrle wrote about this session.


> Examples of things the team does *not* do
> =========================================
> 
>  * 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.


>  * 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.

 - - -

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.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11101

>>>>> "Enrico" == Enrico Zini <enrico@enricozini.org> writes:

    Enrico> On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote:
    Enrico> I join other respondents, with a risk of redundancy, with a
    Enrico> few notes due to the decision of not having delegated powers
    Enrico> and being an undelegated advisory group.


    >> The (CT) is the team responsible for interpreting the Code of
    >> Conduct (CoC) when necessary.

    Enrico> I feel strongly against this: "The team" hints at being the
    Enrico> only team, and "Responsible" hints at having power.

    Enrico> I believe strongly that anyone who is /the/ person/team
    Enrico> responsible for interpreting the Code of Conduct needs to
    Enrico> gain that responsibility from an official delegation, and
    Enrico> absent a delegation, I believe that the only person
    Enrico> ultimately responsible for interpreting the CoC when
    Enrico> necessary is the DPL, overridable by a GR.

    Enrico> However, I also believe that any member of the Debian
    Enrico> community is responsible for upholding the Code of Conduct,
    Enrico> and I'm fine with the idea that one or more people or groups
    Enrico> could make themselves available to help with CoC
    Enrico> interpretation or supporting people if things get heated.

I strongly support the above.


It's going to be a day or two before I get a chance to comment on the
team's proposal.

I think that interpreting the CoC is something that requires a
delegation.
I think that ultimately the project could use interpretation of the CoC
in some cases, and that eventually a delegated community team will be
something the project needs.
    >> 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.

    Enrico> In the same light as above, I suggest s/work/make itself
    Enrico> available/, as any other group could make themselves
    Enrico> available to event organisers to help with Debian or
    Enrico> event-specific CoC.

This is an area where I actually think the project needs a single
delegated entity to coordinate IRTs with events.
I agree with Enrico that being *the entity* is not something that an
individual group of developers can do.
But I think that there are significant advantages in having project-wide
consistency in how we approach IRTs and to do that, I think a delegation
would be necessary.



    Enrico> Some more general feedback points.

    Enrico> I suggest to review your notes with the idea that there
    Enrico> could be two or more such teams in Debian posting the same
    Enrico> set of notes, and they shouldn't conflict.

    Enrico> Also, given the idea that there can be multiple groups doing
    Enrico> this, the name "Community Team" sounds possibly problematic
    Enrico> name to me, as it hints indeed at being /the/ team for
    Enrico> Debian Community issues, which could potentially be setting
    Enrico> the wrong kinds of expectations.

    Enrico> Although I would prefer a name that would make it explicit
    Enrico> that we're talking about /a/ /self-appointed/ group, I
    Enrico> wouldn't consider the naming a blocker: I know names are
    Enrico> hard, and I don't want you all to spend your energy picking
    Enrico> names.

    Enrico> Still, I'd acknowledge and keep in mind that the name does
    Enrico> sound ambitious, and as a consequence I'd expect you all to
    Enrico> be extremely careful in all team descriptions and team
    Enrico> actions to make it clear that you are /a/ community team,
    Enrico> not /the/ community team.


    Enrico> Enrico

    Enrico> -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
    Enrico> <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11105

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.

Best,
Steffen

[toc] | [prev] | [next] | [standalone]

#11109

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

[toc] | [prev] | [next] | [standalone]

#11102

[content summary: interpretation with delegation, role separation for
definition and enforcement of rules, distinction between guidance and
warning, timeliness.]

Hi Steve, Community team and everybody,

I think that the current changes in name and role of the A-H team go in
a good direction.  Here are some comments that I hope are in line with
and will help your efforts.

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.

> 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.

> 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.

 - 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 ?

>  * 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.

>  * Where there might be a Conflict of Interest, individual members of
>    the team will be expected to inform the rest of the team, about it
>    and recuse themselves from relevant discussion.

Thanks for including that point.

>  * Writing and providing reports to other teams concerning incidents
>    or habitual behaviors; and

Given what happened in the past, I think that it would be important to
put a clear limit on how far in the past the behaviour of people will be
investigated, and how behavioural patterns will or will not be
aggregated.  Timely and focused reaction will reduce contention.

>  * 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.

This implies that the CT will contact these people when it is available
to answer in a timely manner to their rebuttals, which is great,


Have a nice day, and thanks for your work on the reboot of the team !

Charles

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

[toc] | [prev] | [next] | [standalone]

#11103

On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote:
> Hi folks,
> 
> We've had a lot of conversations this year about where the
> Anti-Harassment (now *Community*) Team should be going: what we're
> trying to do, and the relationship we'd like to have with the rest of
> the project and the wider community.
> 
> 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 with the rest of the project. Feedback welcome please!
> 
> Name: Community Team
> ====================
> 
> Role
> ====
> 
> The goal of the Community Team (CT) is to help Debian be a welcoming
> place, focusing on response to difficult or contentious
> communications, as well as other negative experiences and Code of
> Conduct violations. It aims to encourage and foster a respectful,
> productive, and inclusive atmosphere throughout the Debian community.
> 
> The team itself has no direct powers to enforce any decision, and
> merely acts as an advisory body. It will aim to respond in a timely
> matter when consulted, and to do so in a consistent way. The (CT) is
> the team responsible for interpreting the Code of Conduct (CoC) when
> necessary.

Hello,

I have to object strongly to the last point.  As you have stated
above, the CT is a self-appointed group of DDs and insofar by
definition has no more powers within the project than any other
random group of DDs, so there is no way that the CT could be
responsible for and thereby have the power to decide over the
interpretation of the CoC in cases where such an interpretation
is contentious within the project.

> We break this down in more concrete terms:
> 
> Responsibilities include
> ========================
> 
>  * Interpreting the Code of Conduct;
> 
>  * Responding in a timely manner to incidents reported by members of
>    the Debian community and those interacting with the Debian project;
> 
>  * Contacting individual contributors about their behavior when it is
>    considered to be in violation of the Debian Code of Conduct;
> 
>  * Providing support and guidance for event incident response teams;
> 
>  * Offering advice and guidance for policies and implementation around
>    community standards and guidelines;
> 
>  * Being available as a resource for those looking for content review
>    of communications or who have questions about how possible actions
>    may fit with the Code of Conduct;
> 
>  * In extreme incidents or after repeated harmful behaviour or Code of
>    Conduct violations, writing reports for relevant teams (e.g. Planet
>    admins, listmasters, DAM), to summarise relevant incidents along
>    with analysis and suggested possible courses of action; and

I have to object to the term "responsibilities" again here. 
"Having the responsibility" implies a power to do so in a way
that is different from the power of any other project member. 
Members of the CT are of course free to perform any of the
actions listed above in the same way that any other project
member is free to perform them, but the CT is no more and no less
"responsible" for them than any other random DD, and if members
of the CT perform any of those actions they must not be given any
more or any less weight than the same action by any other DD.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#11104

On 09/10/19 at 22:26 +0100, Steve McIntyre wrote:
>  * 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,
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
that sounds a bit strange given the team doesn't really have the power
to take actions itself, but I can live with that.


How official is this group? If it is not delegated, should it be listed
(for example on https://www.debian.org/intro/organization.en.html) as an
official contact point? (I believe it should not)

Lucas

[toc] | [prev] | [next] | [standalone]

#11106

Hi,

Responding here on individual capacity, and my team mates will surely
have different views on some items. I will try to address some of the
comments and criticisms of our proposal at once.

First of all, I think that we did not make it clear enough that this is
"where we want to go", as the subject line reads. We're not there, but
we want to work towards this goal.

The main conclusion from that is that yes, some of things expressed in
the proposal require a delegation, I agree! Perhaps, the disconnection
lies in reading that the team does not want to be delegated: quite the
opposite, at least from my part! I had been in talks with the previous
DPL about delegation since last year, but the burnout caused by the
events around December and January delayed progress and then there was a
DPL change, so we had to start from scratch and with considerably less
support.

My view of this discussion is to try to reach consensus on what the CT
role should be when a delegation comes, work towards fulfilling that
role (without the powers and formalisation that delegation would
provide), and finally obtain a delegation when the DPL agrees the team
is ready. I believe we could finish this process within the next 12 months.


Many of the concerns raised were about wording and implication of powers
not yet granted by a delegation, so I will not address those individually.


On 10/10/2019 09:08, Mathias Behrle wrote:

> For me it is beyond the tasks of the team to *ensure* the
> observation of the CoC on Debian events. This sounds again like an
> official assignment that in reality doesn't exist.

Leaving aside the fact that the wording will be contingent on a
delegation, the team has already been liaising with DebConf (and
other-conf) organisers for a number of years to set-up incident response
teams and to communicate to the community that there is a CoC in effect
and that there are people to help when it is broken.

>>  * 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.

This needs to be clarified, yes. That means that the CT might issue
warnings, and finally escalate to other teams that might apply sanctions
at their discretion.


On 10/10/2019 13:18, Charles Plessy wrote:

>> 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.

Absolutely. The proposal is for DAM, listmaster, etc to be the final
judges on whether somebody has crossed a line serious enough.

>> 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.

We try to do that, as it is a more efficient use of our resources, but
it is not always possible. About your second sentence, you would be
surprised: sometimes people do want to improve and be better colleagues,
and I can see the work they put.

> 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.

Agreed.

>  - 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 ?

This is not theoretical, it happens whether at the guidance or at the
warning level, and the strategy is always to try to de-escalate, until
is time to raise the issue to other teams.

>>  * Responding in a timely manner to incidents reported by members of
>>    the Debian community and those interacting with the Debian project;

>>  * Writing and providing reports to other teams concerning incidents
>>    or habitual behaviors; and
>
> Given what happened in the past, I think that it would be important to
> put a clear limit on how far in the past the behaviour of people will be
> investigated, and how behavioural patterns will or will not be
> aggregated.  Timely and focused reaction will reduce contention.

I think this would be difficult to formalise that limit.. Sometimes you
look at old mail archives and what you see is that a person has behaved
badly in the past, but has improved considerably with time; and some
other times you will see the same patterns repeated for years. Sometimes
you don't care at all about the past, depends on the situation.

But also, most of that is public information that anybody can find, and
 might help better understand a complex situation and help a person
interact in a more constructive way. For non-public information, we are
also working on defining clear data retention policies and automatic
erasing of old correspondence.


On 10/10/2019 10:16, Enrico Zini wrote:
> 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.

I don't think that would be a good use of anybody's time. The CT wants
to be *the* team doing the proposed job, and it would be kind of silly
to have two teams doing the exact same thing. If there is another team
that the project feels more fit for the job, then the CT should disband.

> 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.

I thought we had reached an agreement back in May about the name, even
after it was clear that there would not be a delegation for now.. I'd
rather not spend more energy on bikeshedding.

> 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.

If we are working towards being /the/ CT, and drafting how that team
should be defined, that would be against our interests.


My 2¢,

Tina.

[toc] | [prev] | [next] | [standalone]

#11107

TL;DR: I think delegating the community team would be great; if that's
their desire let's work toward that.

>>>>> "Martina" == Martina Ferrari <tincho@debian.org> writes:


    Martina> The main conclusion from that is that yes, some of things
    Martina> expressed in the proposal require a delegation, I agree!
    Martina> Perhaps, the disconnection lies in reading that the team
    Martina> does not want to be delegated: quite the opposite, at least
    Martina> from my part! I had been in talks with the previous DPL
    Martina> about delegation since last year, but the burnout caused by
    Martina> the events around December and January delayed progress and
    Martina> then there was a DPL change, so we had to start from
    Martina> scratch and with considerably less support.


I think we may be talking past each other.

I strongly support the idea of delegating the community team.

I think the process we use is different depending on which direction
we're going to go.

In particular, I think even at this stage how we approach things depends
on whether we're on a delegation path or not.
If we're on a delegation path, the critical question is what are the
project needs in this area.  They drive the question of whether we have
the right team description and whether we have the right people for the
job.

If you're a group of developers, the key factor is what work you want to
do.

Yes, even for a delegation it's important that the delegates want to do
the job, and yes, that influences the task description a lot.
But ultimately, the delegates serve the needs of the project in a way
that  is not true for a non-delegated entity.  That service is the
presponsibility that justifies the power of a delegation.

If you're going down the delegation path, it is good to decide that
early.  That way we know that the project feedback matters in a
different way than if it is a non-delegated entity just soliciting
feedback on how they can be useful.

That way we're considering both the delegates and the task rather than
just what a team wants to do.

So if the intent is to move toward delegation, say that as a team now,
not later.
Once you do that I'll be happy to work with you just as I would any
other group approaching changing/renewing/creating a delegation.

--Sam

[toc] | [prev] | [next] | [standalone]

#11110

On Fri, 2019-10-11 at 07:27:30 -0400, Sam Hartman wrote:
> >>>>> "Martina" == Martina Ferrari <tincho@debian.org> writes:
>     Martina> The main conclusion from that is that yes, some of things
>     Martina> expressed in the proposal require a delegation, I agree!
>     Martina> Perhaps, the disconnection lies in reading that the team
>     Martina> does not want to be delegated: quite the opposite, at least
>     Martina> from my part! I had been in talks with the previous DPL
>     Martina> about delegation since last year, but the burnout caused by
>     Martina> the events around December and January delayed progress and
>     Martina> then there was a DPL change, so we had to start from
>     Martina> scratch and with considerably less support.

> I think the process we use is different depending on which direction
> we're going to go.

I agree as other people have voiced, that it should be made more clear
what are the things that are expected/desired to be part of a future
delegation, and what are the things that are going to be part of the
team operation while that is not the case yet.

> […] They drive the question of whether we have
> the right team description and whether we have the right people for the
> job.

Aha.

> So if the intent is to move toward delegation, say that as a team now,
> not later.
>
> Once you do that I'll be happy to work with you just as I would any
> other group approaching changing/renewing/creating a delegation.

This demand makes this interaction rather awkward, :/ given the
context this is in, and which we cannot discuss in here, and which
might require spelling out what I'll mention in the next paragraph,
which I think should have been no need to. :(

But then I see no reason at all why they need to do that now. Even though
they have already stated so, and the mail you reply to went as far as
mentioning a timetable of around 12 months, which TBH I pretty much
interpreted as a tactful way to say “once the current DPL term is over”.

Regards,
Guillem

[toc] | [prev] | [next] | [standalone]

#11112

[Multipart message — attachments visible in raw view] — view raw

On Sat, Oct 12, 2019 at 04:04:49AM +0200, Guillem Jover wrote:

> > Once you do that I'll be happy to work with you just as I would any
> > other group approaching changing/renewing/creating a delegation.
[...]
> But then I see no reason at all why they need to do that now. Even though
> they have already stated so, and the mail you reply to went as far as
> mentioning a timetable of around 12 months, which TBH I pretty much
> interpreted as a tactful way to say “once the current DPL term is over”.

If one wants a delegation from a DPL, I'd expect them to work *with* the
DPL, as the DPL is the person responsible for delegations.

If a team has an issue with a DPL, I expect them to acknowledge the
issue, state their long term plans and why they wouldn't work with the
current DPL, state what they'd like to do in an interim situation,
propose a GR.

Posting draft team missions where one has to read between the lines
about possible institutional conflicts and other unsaid issues, is
emphatically /NOT/ a way to build trust within the project.

I think the responsibility of interpreting the CoC should go to people
who we can trust not to wield it like a club, who are clearly named, and
so on. A delegation provides this.

Currently, as I understand it, interpretation of the CoC is the
responsibility of the DPL, overridable by GR. Needing to read between
the lines of a proposal like this, instantly makes me think of attempts
to grab that power away from the DPL. Of trying to force a self-written
delegation on the first DPL who gets distracted for a moment. This is
most emphatically /NOT/ a way to build trust within the project.

I have seen, in other communities, successful power grabbing attempts
done by emptional blackmail, refusals to take no for an answer, and
similar kinds of social pressure. I don't at all mean to imply that it
is what is happening here, and I trust at least some of the member of
the (AH|Community) team enough to believe it is actually not the case.

Still, I most emphatically do not want to have to read things between
the lines in a discussion like this one. Not when power is involved. Not
when trust is involved.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11113

On Mon, 2019-10-14 at 13:40:34 +0200, Enrico Zini wrote:
> On Sat, Oct 12, 2019 at 04:04:49AM +0200, Guillem Jover wrote:
> > > Once you do that I'll be happy to work with you just as I would any
> > > other group approaching changing/renewing/creating a delegation.
> [...]
> > But then I see no reason at all why they need to do that now. Even though
> > they have already stated so, and the mail you reply to went as far as
> > mentioning a timetable of around 12 months, which TBH I pretty much
> > interpreted as a tactful way to say “once the current DPL term is over”.
> 
> If one wants a delegation from a DPL, I'd expect them to work *with* the
> DPL, as the DPL is the person responsible for delegations.

With *a* DPL, certainly. But the project is conformed of people, not
abstract titles, groups and teams. Iff, say, some people cannot work
together, then I'm not sure why it would be more desirable to make
a huge mess out of that, instead of trying to work with someone else.
Time also tends to let things cool down.

> If a team has an issue with a DPL, I expect them to acknowledge the
> issue, state their long term plans and why they wouldn't work with the
> current DPL, state what they'd like to do in an interim situation,
> propose a GR.
> 
> Posting draft team missions where one has to read between the lines
> about possible institutional conflicts and other unsaid issues, is
> emphatically /NOT/ a way to build trust within the project.

That's the ideal, yes, but it also only works when such possible issues
can actually be discussed in _public_, while not being bound by
externally imposed non-leak restrictions…

Bringing up GRs here, seems to me to be the opposite of trying to make
Debian a more pleasant environment, though.

> I think the responsibility of interpreting the CoC should go to people
> who we can trust not to wield it like a club, who are clearly named, and
> so on. A delegation provides this.

And I think they made it pretty clear already, that they were ever
only considering assuming that (exclusive) responsibility, once and
*iff* the team becomes delegated…

> Currently, as I understand it, interpretation of the CoC is the
> responsibility of the DPL, overridable by GR. Needing to read between
> the lines of a proposal like this, instantly makes me think of attempts
> to grab that power away from the DPL. Of trying to force a self-written
> delegation on the first DPL who gets distracted for a moment. This is
> most emphatically /NOT/ a way to build trust within the project.
> 
> I have seen, in other communities, successful power grabbing attempts
> done by emptional blackmail, refusals to take no for an answer, and
> similar kinds of social pressure. I don't at all mean to imply that it
> is what is happening here, and I trust at least some of the member of
> the (AH|Community) team enough to believe it is actually not the case.

But you still brought all this up. :/

> Still, I most emphatically do not want to have to read things between
> the lines in a discussion like this one. Not when power is involved. Not
> when trust is involved.

Sorry, but this characterization seems rather unfair, when it seems
to me to be the reaction of just trying to work with the restrictions
imposed by previous events, characterized precisely by the thing you
are criticizing in this exact paragraph.

Regards,
Guillem

[toc] | [prev] | [next] | [standalone]

#11114

[Multipart message — attachments visible in raw view] — view raw

On Mon, Oct 14, 2019 at 01:40:34PM +0200, Enrico Zini wrote:

> Posting draft team missions where one has to read between the lines
> about possible institutional conflicts and other unsaid issues, is
> emphatically /NOT/ a way to build trust within the project.

To make it clear: I think the draft team mission that was posted is a
great start for a discussion, and I think we need teams to support
people in Debian, and I think we need a good way to escalate different
interpretation of the CoC.

What I think is not a way to build trust, is what Guillerme's reading
of Tina's message was implying. I think those things hurt everyone and
destroy good efforts, and I strongly wanted to push the discussion back
to the idea of constucting something together.

I see how my message could be read as implying that the whole draft
Steve posted is not a good way to build trust. To the contrary, I
consider it a good way to put cards on the table, and to start to work
out together how they should be arranged.

I was afraid I was hearing that some cards might not be kept on the
table, and I wanted to strongly object to that.

If all the cards are on the table, by all means, let's all find a good
way to put them together!


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

#11108

[Multipart message — attachments visible in raw view] — view raw

Hello Martina,

On Fri 11 Oct 2019 at 04:56AM +01, Martina Ferrari wrote:

> On 10/10/2019 10:16, Enrico Zini wrote:
>> 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.
>
> I don't think that would be a good use of anybody's time. The CT wants
> to be *the* team doing the proposed job, and it would be kind of silly
> to have two teams doing the exact same thing. If there is another team
> that the project feels more fit for the job, then the CT should disband.

I don't think Enrico is suggesting that there actually be two teams.

I could be wrong, but I think his point was that unless you're seeking a
delegation, it would useful to imagine that there *could* be another
team, while reviewing your own proposals.  That way, you can ensure that
they really are reasonable proposals for a non-delegated entity.

On Fri 11 Oct 2019 at 07:27AM -04, Sam Hartman wrote:

> If you're going down the delegation path, it is good to decide that
> early.  That way we know that the project feedback matters in a
> different way than if it is a non-delegated entity just soliciting
> feedback on how they can be useful.

Right.  I believe that Enrico's suggestion, quoted above, applies to the
case in which a non-delegated entity is seeking feedback.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#11126

[Multipart message — attachments visible in raw view] — view raw

Dear Steve:

It sounds like the feedback you've received falls into a couple of
categories:

1) Some minor tweaks, which you have responded to or are seeking more
input on.  Below the dashed line I have a couple of tweak/questions of
my own.

2) A concern that the responsibilities you have described might better
fit a delegated team than the current structure.

In dealing with this concern, it sounds like you have two options.  You
can either try and split  things into two parts.  You can describe what
you're doing now, and what you might want to do in the future.
Alternatively, you can simply acknowledge that your description is more
focused on an eventual goal.

Honestly, I think the most critical success factor for the team is
recruiting more people.  I'd like to propose a recommendation.  For now,
focus on recruiting rather than on splitting your
responsibilities/description into a now vs future split.  Recruit
assuming that you will eventually be delegated and that you will have
responsibilities substantially similar to those you have outlined.

Then say in early February we can revisit the delegation question.
(February is probably the earliest slot in ongoing delegation work where
we'd be able to bring the project-wide focus for the discussion) At that
time we could:

1) Choose not to delegate at that point.  If we make that choice it
probably would be worth coming up with a split set of responsibilities
(current vs future thinking) at that time.

2) Choose to delegate.  From my side the biggest question is likely to
be whether you have managed to recruit enough people to be responsive in
the areas where the project has indicated being responsive is critical.

3) Do a phased delegation.  So for example if you're still having
trouble recruiting enough people, delegate some of the responsibilities
including a significant focus on ongoing recruiting.


How does that sound?


----------------------------------------

I have two questions/concerns when I think about your description and
compare it to past discussions and the mail I wrote last night:

> * In extreme incidents or after repeated harmful behaviour or Code of
>   Conduct violations, writing reports for relevant teams (e.g. Planet
>   admins, listmasters, DAM), to summarise relevant incidents along
>   with analysis and suggested possible courses of action; and

my understanding from cambridge is that DAM would prefer not to get
recommendations on what to do in such cases.
Is DAM happy with the suggested possible courses of action language?
Even if not, it's fine to keep if other teams would appreciate that
feedback.

Under things the team does not do:

> * Mediate communications or conversations between individuals; or

Particularly in light of the de-escalation need I identified in my mail
last night, I'd like to understand better what you mean by mediation.

From past discussions it sounds like you definitely don't want to be
involved in finding solutions to technical problems.  You don't want to
be doing the work for example I'm doing working with the elogind
maintainers, systemd maintainers and others interested in init system
issues.

How do you feel about your interest and ability to step in and
de-escalate situations?
I'd be happy to give examples where that would have been useful in
private mail to the team.
At this stage, I just want to understand what you are willing/able to do
and what you are not interested in.

Thanks,

--Sam

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.project

csiph-web