Re: Public minute project for the sprint
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.
On 12/14/20 2:18 PM, Jean-Philippe MENGUAL wrote:
> Hi,
>
> Here is a proposal of minute we could release on bits.debian.org. Any
> reedback is welcome, including rewording of deletion of not precise things.
>
> Regards
>
>
> "Sprint report of the Community Team
>
> 2020 has been a very new year for the team, as many things have happent
> since the 2019 sprint and the Debconf BoF. Most of the team was renewed,
> some former persons came back, making the team be composed of 7 members
> now. Since April, the team has a delegation from the DPL.
** 2020 has seen a lot of changes with the team since the 2019
Sprint(link) and the DebConf BOF(link) event. 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))
> It was the purpose of the Sprint Week-end, which standed the last
> October week-end. Formally, the team organized 2 3-hours meetings on
> Saturday and Sunday.
** The purpose of the Sprint Weekend, which started the last week in
October, was to formalize 2 3-hour meetings on Saturday and Sunday.
>
> Among the addressed topics, including back to difficult requests during
> the year, the team could have a consensus about some cross-ideas we can
> share publicly to help the community to understand our job and collect
> feedbacks.
>
** 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.
> Roel of the external activities on the Debian contributor status
** Role of external activities for Debian contributor status **
> =================================================================
>
> Issue: when the community gets knowledge about a person having criminal
> activities, not related to Debian, what to do?
>
** 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 probably does not want to know about the private life
> of people, some criminal activities may result inconfortable situations
> for the community. For example, how to be confortable during a physical
> event or whatever, to stay with someone who did sexual or violent offences.
>
** While the project is mindful of the individual privacy of its
members, some prior activities regarding criminal intentions or actions
((Wordy, I can change this if needed :) --DN)) 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. **
> Consensual proposals:
> The community team tends to think that the answer depends on the
> offender behavior:
> 1. The project should let anyone a chance to tell us things we should
> know about past actions:
> - approving expressively the code of conduct before being a Debian
> contributor
> - being asked: "Is there anything we should know about you that might be
> a problem for your interactions with the Debian community? e.g. past
> public online activities you now consider inappropriate"
>
** 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 contributor ((Contributor or Developer? -DN))
- 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 public online activities you now consider inappropriate"
((Is this limited only to online activities? I am not sure considering
the variety of past circumstances that could make others uncomfortable
would be limited only to things done online. I mention this in light of
the prior 'physical' concerns. The question may be better phrased to
ask, "Do you have any past activities that you think would be concerning
to our community such as online postings or documented legal offenses".
-DN)) **
> 2. If the person mentions problematic activities outside of Debian, but
> expresses a will to let it behind, then the community should not be
> unconfortable with this.
> If offenders don't improve, or continue to complain about their
> treatment, that's toxic behaviour for the community and the person
> should be requested to leave. The important thing is to inform him/her
> explicitly.
> If the person did not say anything but someone reports to the Community
> Team about knowledge of it, having an impact on an event, it is
> important to protect the reporter and take this account for future
> interaction with the reported person. Of course, the person is free to
> explain how he/she perceives his/her situation, but the project should
** 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)) **
> What should we do about people who are arguably not violating the CoC,
> but drive others out of the community or otherwise negatively impact the
> community?
**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? **
> ===============================================================================================================================
>
>
> Firstly, it seems clear that technical excellence is not an excuse for
> being problematic around other people (including bad actions against a
> kind of group (transphobic, racism).
**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.
> But sometimes the situation is more
> subtile: people feel excluded from a team, some people repeat a bad
> behavior interacting with the community (eg. continuing to push an
> argument over and over and over while it's obviously not going anywhere)
>
** 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 make the person stop
> bringing things up in public and causing grief for everybody else, the
> community team can request a temporary ban from the communication
> channels or DAM. It may be definitive if things don't change.
> Suggestion: "If you're reported 5 or more times for being a jerk, you
> should be encouraged (forced?) 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.
>
** 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)) **
> What process for more responsiveness and to be more trustable
** 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. It implies to answer any new request in less than 24 hours
> with an acknowledge message, registering the request in the internal
> tools, and address, forward or share it. In any case, at least one
> action should take place each week, with the reporter informed about it,
> related to his/her request. The action may happen after the weekly meeting.
>
** The community team will try ((will try or will do? --DN)) 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. **
> Some work in progress is done to define what cases may be addressed by
> the front officer, those which should be forwarded to a 3-people
> subgroup, those which should be handled by the whole team.
>
** 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, the onboarding
> with newcomers with mentoring, resources, etc
>
** 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 typical actions could
> violate the Code of Conduct
** 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 remember some
> cases where the code of conduct was not respected. A document will be
> written soon to explicit, for each section, how someone can be aware if
> he has chance to be compliant or not with the CoC.
>
**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 has a bad behavior inside or
> outside the community, he carries out the project reputation, so it is
> not acceptable
> * the important thing is less avoiding mistales than learning from them,
> improving oneself after them
* 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)) **
Be Well,
-Donald
--
--
-
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Donald Norwood
⢿⡄⠘⠷⠚⠋⠀ B7A1 5F45 5B28 7F38 4174
⠈⠳⣄⠀⠀⠀⠀ D5E9 E5EC 4AC9 BD62 7B05
Reply to: