Re: On having and using a Code of Conduct
On Thu, Jan 03, 2019 at 11:26:11AM -0700, Eldon Koyle wrote:
> I think there are many who are concerned about the process, not the CoC
> itself. Here are the main concerns as I see them (at least from the few
> who have come forward), and I believe these are the reasons that people
> are worrying:
So, responding to those points in turn (and bearing in mind that this is
not an official statement of any kind):
> 1. The process itself is not well documented (it's new, so expected)
Process of what? It's true that the relationship between AH and DAM is new
and we're finding how best to work together, but that's not really a
process.
> 2. The accused isn't allowed to address the claims against them
That's a rather simplistic view. Cases reaching AH and DAM typically do so
as a last resort after going through many iterations of feedback.
> 3. The a-h team is acting as both prosecution and judge/jury (usually
> separated to reduce confirmation bias)
Except that they can't actually *do* anything above and beyond and ordinary
DD. AH are not delegated and don't have any special powers; it's up to
maintainers of services whether their recommendations are implemented.
> 4. The proceedings are closed, so claims of unfairness aren't refuted
If you have suggestions of how to open proceedings up without compromising
the confidence expectations of any of the involved parties, we'd all be
delighted to hear them. It's a hard problem, it always has been.
> 5. There doesn't appear to be an appeals process (contact DAM?)
The ultimate appeal is through a GR, but that's a pretty blunt tool. We
have proposals in discussion internally already to make this better.
> I believe that the a-h team gives people warnings and tries to help them
> understand why what they are saying is unacceptable and how they might
> have been able to express their opinion more appropriately before
> starting this process, but again I have no evidence of this, and they
> cannot provide it.
What is it that leads you to believe it then?
> IANADD, but the limited information available about the process and the
> outcomes is difficult in a community that is typically as transparent as
> possible, and I think it is reasonable for people to have concerns about a
> closed process. Any information that can be provided about the process
> would probably help with these concerns -- and it should be published
> somewhere other than mailing list archives.
>
> This situation is especially difficult since the interpretation of the
> CoC can be highly subjective, and there is no real feedback on how the
> a-h team is interpreting it. Maybe writing a more in-depth document on
> the a-h team's interpretation of the CoC would help (examples of bad
> behavior, examples of behavior that although someone might be offended,
> is not forbidden)?
>
> In Norbert's case, I get the impression that the bar was raised for him
> after his first offense, and he may have actually been removed from the
> project for insubordination (ie. re-adding his blog to planet, which
> although ill-advised, may have been an honest mistake as he removed the
> offending post before doing so). However, I only have half of the story.
If you have only one half of a story, it is dangerous to draw absolute
conclusions from it.
> Finally, due to 2 and 3, there is going to be a lot more bias (toward
> guilt) in this process than in a typical legal proceeding (this is about
> the process, not the a-h team; it is just the nature of searching for
> evidence of a crime or breach of the CoC in this case -- it is the
> reason we have a hopefully impartial judge hearing both sides in legal
> proceedings).
Other people have expressed far more cogently than I can how Debian, AH and
DAM are very much not courts and these are not legal proceedings. Debian is
a private members organisation and is governed primarily by its own
foundation documents.
> This is especially difficult since the interpretation of the CoC can be
> highly subjective, and there is no real feedback on how the a-h team is
> interpreting it. Maybe writing a more in-depth document on what the a-h
> team expects and what kind of behavior is the most common or most
> disruptive would help?
All Debian teams are volunteer-staffed and overstretched. If you are able
to make a contribution to this document in some way, I'm sure they would
appreicate the help.
--
Jonathan Wiltshire jmw@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
Reply to: