[ghc-steering-committee] Dealing with abuse on the issue tracker

[Simon Peyton Jones]

But since the HF Guidelines don't actually pertain directly to the GHC
proposal discussions, perhaps a good first step would be to actually create
a code of conduct that is stated to apply to participants in these
discussions, so that we have something concrete to point to. This could be
more or less a copy of the HF guidelines. (Though I would prefer doing
something more than just* referring to* the HF Guidelines; that would seem
confusing since it specifically states that it applies to members of a
Haskell commitee, rather than discussion participants.)


I agree -- I'd like our main proposals process page
<https://github.com/ghc-proposals/ghc-proposals>to explicitly refer to the
HF guidelines.

I don't want to write new guidelines!  I don't think we need to modify the
HF ones except to say (on our page) that we expect contributors (not just
committee members) to our GitHub to adhere to them.   Our GitHub is our
walled garden, and we can state requirements for participation.  (Is it
technically possible to prevent particular people posting on GitHub?)

Simon



On Wed, 24 Jul 2024 at 21:51, Jakob Brünker <jakob.bruenker at gmail.com>
wrote:

> > Curiously, I don't see a direct violation of any HF Guideline as I
> interpret them
>
> I think it does go against the " We strive to be scrupulously polite at
> all times." point, though of course that's somewhat subjective.
>
> But since the HF Guidelines don't actually pertain directly to the GHC
> proposal discussions, perhaps a good first step would be to actually create
> a code of conduct that is stated to apply to participants in these
> discussions, so that we have something concrete to point to. This could be
> more or less a copy of the HF guidelines. (Though I would prefer doing
> something more than just* referring to* the HF Guidelines; that would
> seem confusing since it specifically states that it applies to members of a
> Haskell commitee, rather than discussion participants.)
>
> On Tue, Jul 23, 2024 at 11:16 AM Sebastian Graf <sgraf1337 at gmail.com>
> wrote:
>
>> What I found quite derailing upon reading the very first comment was that
>> it raises two non-issues:
>>
>>    1. that the proposal should generalise to more keywords than just
>>    `type` (it does!)
>>    2. that the proposed change could somehow make typos valid programs
>>    (it does not; .type must be surrounded by parens (.type), and such a typo
>>    would likely trigger a syntax error *even if* -XOverloadedRecordDot was
>>    active)
>>
>> Reading such troll-ish posts (even if the author did not mean to troll)
>> often triggers a strong urge in me to reply to correct these perceived
>> misconceptions.
>> Soon I'm not the only one replying. The troll (by perceived function, not
>> by self-declaration) keeps on fueling the discussion with ever new
>> contentious material, at which point the discussion has been successfully
>> derailed.
>> Everyone participating in the discussion *feels* like they are helping,
>> but in reality they are sadly just providing more fuel.
>>
>> I do not know enough about moderation practices to emphatically suggest a
>> solution.
>> Of course it helps if the committee itself does not engage with trolls,
>> but there are many other people with a GitHub account who might still
>> engage (and they do!).
>> In the present case, the proposal author engaged with the troll as well.
>>
>> That highlights an important issue: *The proposal author is supposed to
>> defend their proposal against critique, and rebut any which is invalid.*
>> In other words: *it might seem like it is the job* of the proposal author
>> to engage with trolls.
>> (Of course, ultimately only critique from the committee needs addressing,
>> but I think it's "good practice" to rebut early.)
>> If I was a proposal author and the troll accepted a rebuttal as an
>> invitation for more inflammatory discussion that went un-moderated, I would
>> be upset about the experience.
>> I think that is what happened here. Curiously, I don't see a direct
>> violation of any HF Guideline as I interpret them, but to me it feels like
>> the whole discussion was started by the troll in bad faith.
>>
>> Am Di., 23. Juli 2024 um 09:36 Uhr schrieb Simon Peyton Jones <
>> simon.peytonjones at gmail.com>:
>>
>>> I'm curious what the other committee members think about this.
>>>
>>>
>>> I am very concerned when conversations stray outside the Haskell
>>> Foundation Guidelines for Respectful Communication.
>>> <https://haskell.foundation/guidelines-for-respectful-communication/>
>>> But I am often very unsure what to do about it.
>>>
>>> In this case, though, it doesn't look terrible.  Matt is clearly saying
>>> (albeit in rather intemperate language) that he feels unwelcome, but
>>> actually the thread does not look bad.   Some people supporting, some
>>> suggesting caution ("that might be dangerously close to a typo") and some
>>> (IMHO totally unjustified) sarcasm ("Oh, hang on ... is the date April 1st
>>> where you are?").
>>>
>>> How does it come over to all of you?   Any advice or suggestions?
>>>
>>> Anyway, I'll write to Mike.  Thanks for flagging it Moritz.
>>>
>>> Simon
>>>
>>>
>>>
>>> On Tue, 23 Jul 2024 at 08:24, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> Dear Committee members,
>>>>
>>>> I'd like to bring the following tweet (thread) from Matt to your
>>>> attention:
>>>> https://x.com/mattoflambda/status/1815536812376707224
>>>>
>>>> It concerns pull request: Allow reserved identifiers as fields in
>>>> `OverloadedRecordDot` by parsonsmatt · Pull Request #668 ·
>>>> ghc-proposals/ghc-proposals (github.com)
>>>> <https://github.com/ghc-proposals/ghc-proposals/pull/668>.
>>>>
>>>> We do not seem to be as welcoming as we could/should be?
>>>>
>>>> My stance in general around this is probably a bit old fashioned, and
>>>> what I learned on IRC back then: not to fuel and engage with negative
>>>> behavior.
>>>>
>>>> I'm curious what the other committee members think about this.
>>>>
>>>> Best,
>>>>  Moritz
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240725/caded93f/attachment-0001.html>