Process improvements when excluding attendees from DebConf
Continuing the process improvements sub-thread from the "DPL blindsides"
thread [0] on debian-vote.
[0]: https://lists.debian.org/68870107-0cf6-da37-fe8f-ec615d923dfd@debian.org
> > - The DebConf Committee did not know
> > - The DPL did not know
>
> These I think were a lot more problematic. There were also some DebConf
> related problems that exacerbated the situation. The DebConf committee
> was formed half-way into the DC17 cycle (in January 2017), and at the
> time was overwhelmed by another harassment issue where there were lots
> of meetings and time demands. Because of this, the local team didn't
> really know yet how to interact with the DCC and at times they even said
> that they felt alone, it took a while to fix the DCC / DC-17 team
> relationship as well, there was just a lot going on during this time.
Not that it's much help to Teemu here, but I think those issues have
been resolved since then.
> In DebConf, a local team has every right to block any person for
> whichever reason they see fit. This is unlikely to change in the
> future, although I do agree that there should be some due process and
> at least the DCC should be kept in the loop because that's the best
> place to preserve some institutional knowledge on these matters.
So, putting on a current debconf-committee member hat. Let's talk about
what we could do to implement "some due process".
First: Looking at delegations.
The team delegation [1, 2] didn't explicitly delegate anything that would
force the local team to raise issues like this to the committee.
Although, it's probably expected by the mentorship role. The most
relevant section to me is this bit of section 3:
| As last resort, the DebConf Committee can override specific decisions
| in the context of DebConf organization.
This delegation is impossible to exercise without sufficient information.
[1]: 2017: https://lists.debian.org/debian-devel-announce/2017/01/msg00003.html
[2]: 2019: https://lists.debian.org/debian-devel-announce/2019/11/msg00003.html
The recent community team delegation [3] also doesn't force a local team
to consult with them, only:
| To work with event organisers to make sure that Debian Events have
| adequate incident response teams to respond to any concerns.
[3]: https://lists.debian.org/debian-devel-announce/2020/04/msg00005.html
I'm not convinced that delegations are the solution this problem,
anyway.
Second: The DebConf Code of Conduct
DebConf's code of conduct [4] does not define any plans of action, or
processes related to breaches. It only asks people who have concerns to
raise them to the community team (or possibly ask the content or debconf
teams for clarifications).
[4]: https://www.debconf.org/codeofconduct.shtml
Should we have a more actionable code of conduct?
They do seem fashionable at other events. See e.g. the "Procedure"
section of the PSF's code of conduct [5].
[5]: https://www.python.org/psf/conduct/
That would mean declaring processes for handling some kinds of concerns,
across multiple DebConfs. Sounds useful for continuity.
Designing such a process seems to fit squarely under the community
team's delegation. Do you guys have thoughts?
> As I mentioned above, the Debian event planning team has every right to
> make such a unilateral blacklisting, and I don't think that's going to
> change any time soon. Ultimately it's the organisers of an event who has
> the most control and responsibility to make sure that the attendees are
> safe, and they get to make the ultimate decision.
Yep, agreed.
> I do agree that they also have a responsibility to share this
> information with the DCC in the case of DebConfs, or the DPL or
> Community Team when it comes to other DebConf events. This would help
> provide some additional sanity checks and also for posterity.
This is where we seem to have ended up, but it's rather vague and
easily starts to involve 5 teams:
1. Local team: the point of contact, in this case, and some others,
historically, even though it isn't a clearly defined team, or a
defined point of contact in the code of conduct.
2. DebConf committee
3. Debian Community Team
4. Debian Account Managers (concerns relating to Debian members usually
end up here)
5. The DPL
I don't think all the teams there need to know all of the details. That
probably ends up being confined to the community team, and maybe the
point of contact.
But, if any appeals are raised, as in this case, there is very little
that the teams that don't know details can do to to help. Other than
stand in blind support (nothing wrong with that).
SR
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272
Reply to: