Re: Q to both candidates: preventing burnout by other contributors
Russ Allbery writes ("Re: Q to both candidates: preventing burnout by other contributors"):
> [analysis of structural problem with toxic behaviours]
I agree entirely with your analysis.
> In Debian, we have very few tools short of outright explusion from the
> project, which obviously everyone is very reluctant to use, and everyone
> knows that.
There are areas and situations where there *are* such tools.
For example, any non-maintainer contributor needs to stay in the good
graces of the maintainer(s). Any non-DM/DD contributor needs to stay
in the good graces of their sponsor(s). An RC bug squasher needs the
active positive approval of the Release Team. Everyone in the
Reproducible Builds team needs to maintain a good personal reputation
and help maintain a good team reputation, so that maintainers across
the project accept their patches.[3]
It's notable that while obviously there are many harebrained and/or
toxic people who might like to try to "contribute" to Debian, we don't
usually experience them as a big problem[1] because our existing power
structures largely work to defend our community.[2]
Core teams are accountable to the DPL, who has a much wider range of
practical options short of firing a team or an individual. (Whether
this is effective depends on how effective the DPL is as a manager,
and different DPLs' have had different levels of skills.)
Establishment and acceptance of that formal accountability has, I
think, helped the project solve some problems we had. Our core teams
are mostly working fairly well.
OTOH the problems we have heard described with Debconf show that the
DPL cannot be relied on to act effectively, because they may lack the
necessary management skills.
The big problem is DD/DM maintainers, including team members. We have
few useful tools between informal public opprobrium (which is a
terrible tool because it's unjust and creates a toxic discussion
environment) and firing someone from maintainership.
Formal peformance management systems in hierarchical organisations
often have an escalating system of advice/warning/reprimand.
I think it would be possible, without radical change to maintainers'
position authority, to institute an escalating system of private and
public advice/warning/reprimand.
But we lack authoritative institutions that are willing and able to
issue such statements.
Part of the problem is our culture of doing everything in public.
Discussions about issuing a team member with formal advice must not be
held in public. Where teams are involved, the team members lack a
suitable venue for the conversation.
Another problem is that no-one has a template process to follow. The
DPL could help here by defining a process and setting a good example.
The DPL as a post clearly has the moral authority to issue formal
advice/warnings/reprimands. But the institution of the DPL lacks the
capacity to use this tool in an effective way.
The TC hates to focus on behavioural problems, and does not like to
use its power to depose maintainers.
I guess what I'm saying is that maybe the DPL should indeed consider
creating an "oversight and mediation committee" who would deal mostly
in private, and would engage in both mediation and disciplinary
communications.
Ultimately that committee might even "recommend to the TC that
so-and-so be removed/replaced as maintainer".
Thanks for your penetrating analysis, anyway.
Ian.
[1] I'm excluding here the problem of harassment by outsiders, which
is very real, but a rather different issue with different causes.
[2] An exception is outsiders engaging in vigorous advocacy campaigns
in debian-devel.
[3] Someone maintaining a minority menu system needs to maintain a
good relationship with the maintainers of desktop packages - and if a
significant minority of desktop package maintainers decide that the
minority menu should be killed (for whatever reason) then the
project's power structure will act as executioner.
Reply to: