Re: Community Team - where we want to go
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.
Reply to: