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

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

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.


Reply to: