Re: Sprint report from the AH/DAM/DPL Sprint, 22/23 June 2019
The DPL gets lots of feedback - lots of people start here first. This
is not necessarily wrong, but it's difficult to make things scale. One
person with reasonable amounts of time can mostly manage, and it's
good to have a good overview of everything. Sam has reviewed lots of
historical discussions, and is coping with it so far. Dealing with
reimbursements is much more draining!
DPL should not get involvd in AH-DAM process, as he does not have a
special authority in the project. Should be informed, yes, but not
involved. He has other things to decide (financial, external
communication, delegations).
So, what is the scope of the team? We want to be a resource for
mediating challenging communication and miscommunications. We will
pass reports to relevant teams if/when actions become necessary. We
will aid in the interpretion of the CoC. Fundamentally, we want to
help the Debian community become a more welcoming place for all.
If I take my example, while DD process, we did not understand each other
with my AM due to cultural diffrences (about opensource and his
practices, etc). He took info from sponsors and understood then
explained. I think AH should have such role in case of complaints:
culture or other, true misbehavior universally unacceptable. Thinking
about "if such bebaviour was gneralized" may help to decide wether a
situation should be explained or stopped. >
9. Setting up better process for AH
===================================
Sledge will talk to DSA to sort out RT queues for AH and work out what
we need.
We could possibly share some things (conversation logs etc.) in an
IMAP folder etc. too - let's work out the best process as we go.
Why nott nm infra?
Couldn't AH team have a tool similar as nm.d.o? Just like a DD process
is handled by application managers (and dek etc), any individual
conflict would enter in such tool and handled by the same way (a case
manager, opinion, a frontdesk to help, DAM decide at the end).
Suspending an cccount or rmoving it would follow he same parallel
process as getting a DD/DM status. But at the end, instead of ending on
DAM decision, the case manager could say "no problem" (and stop the
process), revert of the application manager saying "no possible" and
reject a DD request. In other words, with a paralll process based on nm,
the DAM would open or close accounts with a good follow-up, AH team
would have a tool too, stopping or making things go until DAM, just like
applications manager decide to go until DAM or not.
10. CoC - is it OK? Do we need to update it?
============================================
We agreed to change a couple of bits of context *around* the CoC:
* Assert it also clearly applies to Debian events
* Add the footer with contact info etc., as mentioned previously.
Sledge will prepare diffs and send round for review.
To actually modify the statements on the CoC pages, we probably would
need a GR, based on the original GR vote
(https://www.debian.org/vote/2014/vote_002). However, we can clarify
how we interpret it on the page and elsewhere. We assert that Debian
events are also places of communication - that should be obvious and
non-controversial.
How much leeway do we allow for "good faith" etc. in discussions? How
much is considered "thought policing"?
If we ever do update the CoC, we might think about adding something
about respecting boundaries.
Adopting a COC without inside the consequences of non-respect is a
problem I think. A GR should amend this document to include this too: if
violation, what happens, and all the procedure. If not clear, lets
people think all desired and ambiguous is necessarily origin of
conflict. Requsting a team to make a COC compliant without anyone knows
the procedure for violation is harm for everybody.
Regards
Reply to: