[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Public minute project for the sprint

Le 18/12/2020 à 18:43, Donald Norwood a écrit :
> Hi Jean-Philippe!
> I did a quick first pass and inserted a few changes and also a few
> clarification questions. I hope this survives the email format. Do you
> have this anywhere on git? It make make larger editing easier if required. Oh I was sure I had replied, my apologies. Many thanks for this work. I dont have any idea about a Git repo to post this work, but if -publicity has a place, I will use it. Note a wiki could be possible too. I also can do pad even if it is much more difficult for my screen reader

Here is the actual version:

"2020 has seen a lot of changes with the team since the 2019 Sprint [1] and the DebConf BOF event [2]. Most of the original team members team stayed with the team which is now comprised of 7 members under delegation from the DPL.

While things start getting results (processes, addressed requests, etc), it was important for the team to be able to work together in "live" during some time to make certain things speed up in our thoughts and action.
> ** (( I didn’t really understand this part. Do you mean that while the
> team was working on background processes like addressing, that the team
> was able to demonstrate that they could work in a "live" environment? --DN))

I mean the team improved its internal processes to address better the cases, but we still need to do, hence the need to work in live.

The purpose of the Sprint Weekend, which happent the last week-end of October, started the last week in October, was to formalize 2 3-hour meetings on Saturday and Sunday.

Some of the topics addressed were how to get back to some of the difficult requests we had, and to gather a consensus on some ideas to share publicly to help the larger Debian community understand our job and to collect feedback from the community.

Role of external activities for Debian contributor status

Issue: When the community receives knowledge of a [Debian Developer/Debian Contributor]s past criminal activities not related to Debian, what, if anything, should Debian do?

While the project is mindful of the individual privacy of its members, some prior activities regarding criminal activities could introduce some uncomfortable situations within the community. For example: Physical meetings between parties where one of them has had a past of sexual or violent offenses.

The community team tends to think that the answer depends on the offenders behavior: 1. The project should offer everyone the chance to be forthcoming about past actions: - Expressly approving this in the code of conduct before the party becomes a Debian Maintainer/Developer - Asking directly: "Is there anything we should know about you that might be a problem for your interactions within the Debian community? E.G. past activities you now consider inappropriate"

2. If the person is forthcoming about prior activities outside of Debian which may be of concern to the community and expresses a desire to move forward from the past, the community should be accepting of this. If a person continues with a behavior or contributes to the community in a manner that is toxic, they may be requested to leave. The most important thing here is to inform them explicitly (of the reason(s) why they are being invited to leave).
If the person was not forthcoming about prior activities outside of Debian which may be of concern to the community and someone else reports those activities to the Community Team in light of its impact to the community or its impact on the level of trust and comfort at an event, it is important to protect the reporter and take note of the account for future interaction with the reported person. Of course, the reporter is free to explain how they perceive their (or ‘the’) situation.
>> be careful about his/her interactions.
> (( I didn’t understand this part, do we mean the project has to monitor
> the person reported? Does the project issue a statement about the
> circumstance? Very tricky area here and I’m not sure it would be wise or
> beneficial for the accuser, accused, or the project. Perhaps someone
> with legal experience can contribute to the wording needed here --DN)) **

ack. Lets remove it then. THe idea is that knowing the situation, a basic monitoring is possible from the DAM and CT.

What should the Community Team do about people who are arguably not violating the CoC, but drive others out of the community or otherwise negatively impact the community?

First, we want to be clear that technical excellence is not an excuse for being problematic around other people, nor does it allow for bad actions against any kind of group, race, religion, creed, orientation, or origin.

Sometimes the situation is more subtle: People feel excluded from a team or process due to repeated bad behaviors experienced while interacting within the community (e.g. someone continuing to push an argument repeatedly while it's obviously not going anywhere.)

Proposal: After several private messages to appeal to the person to modify their behavior the community team can request a temporary ban of that person from Debian communication channels or ask for DAM intervention.
The wording of the messages would move to warnings should the behavior not change. Suggestion: "If you are reported 5 or more times for being a jerk, you will be encouraged to take a break for a while (4w? 8W?).

In some cases, we can talk to people periodically and remind them to try and interact better, consider other people's opinions more. > ((Specific people or a friendly internal reminder every few months? -DN)) **

Probably CT, to be precised

What processes do we have for responsiveness and to build trust inside the community? **

The community team will try to set a rota to assign people to a front office task. The front office will answer any new request within 24 hours with an acknowledgment message, then register the request in our internal tools (system?), and address, forward or share the concern. In any case, at least one action should take place each week with the reporter informed about the action related to their request. The action may happen after the weekly meeting.

We are still working to define which types of cases may be addressed by the front officer, those which should be forwarded to a 3-person subgroup, or those which should be handled by the entire team.

The community team agreed to improve the process writing for onboarding newcomers along with mentoring, resources, etc …

Writing a guide to help people determining what kinds of actions could violate the Code of Conduct

For each section of the code of conduct, the team tried to recall some cases where the code of conduct was not respected. Documentation outlining how someone can stay within compliance of the CoC while soon be authored for each section of the CoC.

In general, we had an agreement about some important ideas:
* If someone is a Debian Developer and demonstrates bad behavior inside or outside of the community, they carry with them the project reputation and such behaviors are acceptable. * The important thing is not to make less mistakes but rather to start learning from them and improving oneself after those lessons. ((I may have bungled that last one, sorry. --DN))

[1] https://lists.debian.org/debian-project/2019/07/msg00148.html
[2] https://debconf19.debconf.org/talks/71-anti-harasment-bof/

Reply to: