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: