Re: Community Team - where we want to go

[Martina Ferrari]

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 interactin

Re: Community Team - where we want to go

[Steffen Möller]

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

Re: Community Team - where we want to go

[Lucas Nussbaum]

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

Re: Community Team - where we want to go

[Karsten Merker]

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.

Guest Content Enquiry

[Emily from ProPrivacy]

Hi there,

I am just emailing to ask if you would be interested in placing any guest
content on your site?

I represent ProPrivacy, an online resource dedicated to helping everyone
reclaim their online privacy and stay safe in the digital age. We're
looking to spread our message far and wide and I think would be a good fit
for us as we have plenty in common with the technology niche.

If you're interested, can you please let me know the requirements we would
have to adhere to in order to get published on your website?

Looking forward to hearing from you!

Best Wishes,
Emily Walsh

*Outreach Specialist at ProPrivacy
*
[image: beacon]

Re: Community Team - where we want to go

[Charles Plessy]

[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

Re: Community Team - where we want to go

[Sam Hartman]

> "Enrico" == Enrico Zini  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> 

Re: Community Team - where we want to go

[Scott Kitterman]

On October 10, 2019 9:00:43 AM UTC, 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 with the rest of the project. Feedback welcome please!
>
>Hi Steve,
>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.
>
>Scott Kitterman wrote:
>> From what does the team believe they derive their authority to do
>things like interpret the CoC and to whom is the team accountable?
>
>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?
>
>My understanding is that the team is expecting to receive a formal
>delegation from the DPL which would give them such authority. Given
>also that they are going to handle confidential information (see
>above), my opinion is that a delegation is indeed necessary.

What's the basis for this understanding?  I've not seen anything discussed to 
that effect, in fact the last time this came up (that I'm aware of) there was 
substantial push back from the team on the idea?

>However, I'd also observe that it's quite common in Debian for people
>to take over a specific responsibility and be granted a de facto
>"monopoly" over it without a formal delegation. For example,
>maintainers take ownership of their packages without being delegated,
>yet everybody accepts that it is a very bad thing to act on a package
>against the maintainer's will. That isn't really different from the
>Community Team claiming ownership of interpreting the CoC simply
>because they were the first who started working on that.

I think you inadvertently make my point for me.  The maintainer role is defined 
in Debian policy and the tech-ctte had a constitutionally defined 
responsibility to decide who the maintainer is in case of disputes.

Yes, one can volunteer to be a package maintainer for a particular package, but 
the role and it's oversight are well documented by the project.  There's 
nothing self-defined about it.

Scott K

Re: Community Team - where we want to go

[Gerardo Ballabio]

I wrote:
> That isn't really different from the Community Team claiming ownership of 
> interpreting the CoC simply because they were the first who started working 
> on that.

Thinking again about it, maybe they should have filed an ITP bug?!?

Gerardo

Re: Community Team - where we want to go

[Gerardo Ballabio]

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.

Gerardo

Re: Community Team - where we want to go

[Gerardo Ballabio]

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

Hi Steve,
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.

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

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?

My understanding is that the team is expecting to receive a formal
delegation from the DPL which would give them such authority. Given
also that they are going to handle confidential information (see
above), my opinion is that a delegation is indeed necessary.

However, I'd also observe that it's quite common in Debian for people
to take over a specific responsibility and be granted a de facto
"monopoly" over it without a formal delegation. For example,
maintainers take ownership of their packages without being delegated,
yet everybody accepts that it is a very bad thing to act on a package
against the maintainer's will. That isn't really different from the
Community Team claiming ownership of interpreting the CoC simply
because they were the first who started working on that.

Gerardo

Re: Community Team - where we want to go

[Enrico Zini]

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 


signature.asc
Description: PGP signature

Re: Community Team - where we want to go

[Mathias Behrle]

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