however they must file a ticket with the Council_'s https://pagure.io/CoC/issues[Code of Conduct issue tracker] to report the ban.

I'd be filing a ticket several times a week if I had to follow this rule. Please don't.
e.g. see recent logs: https://cloud.rhea.dev/s/Te8JEi4pjT9kfWo

...and that is but one community out of many, anyway. The numbers will only keep increasing with the growth. The above is our Discord with 2200 members, then there is also Reddit with nearly 20 000, etc etc...

(I think that these kinds of things should apply only to #fedora-* channels on Freenode.)

@rhea thanks for the feedback. That mirrors comments I've heard out-of-band as well. This is intended to apply beyond IRC (e.g. to mailing lists, Discourse, telegram, etc) but I think it makes sense to draw a distinction between "internal" channels and "external" channels. Do you have any suggestions for wording?

Also, is the Discord an official channel? If not, then this rule would not apply there anyway (though I suppose that needs to be clarified).

@bcotton said:

@rhea thanks for the feedback. That mirrors comments I've heard out-of-band as well. This is intended to apply beyond IRC (e.g. to mailing lists, Discourse, telegram, etc) but I think it makes sense to draw a distinction between "internal" channels and "external" channels. Do you have any suggestions for wording?

Say... "contributor channels" or something along those lines? Anything that a group of contributors use to communicate their work towards Fedora.

Also, is the Discord an official channel? If not, then this rule would not apply there anyway (though I suppose that needs to be clarified).

Discord is as official as Telegram ;)

This currently would not apply in the Telegram group, aiui, therefore it doesn't apply in Discord. Neither is official as I understand our project's definition.

A channel is made official by a team using it as their official communication method. Bot repeaters are treated like users in those channels, so, for example, if Discord bot repeats an official channel, then the Bot can be banned if the Discord admins won't take action to effect the required changes.

In the Community Blog post, @bcotton added this note:

To be clear, this is not intended for conduct that violates our Code of Conduct.

I think this context is important to make explicit. For example, a situation may occur where a new contributor faces targeted harassment by someone else in the community. The first impression might be that the harasser can only have action taken against them in the channel where the harassment happened and the harasser's participation in the Fedora community is otherwise unaffected. From what I have read, this is not the case, but I suggest making this explicit in the policy so it is not ambiguous.

I am happy with the suggested change for channel-specific bans, but I believe this policy is at risk of not being enforced in practice.

I think Fedora's current code of conduct is an incomplete implementation because there is no documented or transparent process of what happens to a code of conduct complaint. I am surprised to see new policy documents written that reference other policies that do not yet publicly exist. This is currently the face of Fedora's Code of Conduct process:

This repository is linked from the official Code of Conduct and the description around the reporting procedure is three sentences long. As much as I am aware, this is the only guidance available about how to file a CoC ticket. I filed CoC#243 over a month ago without any responses, which makes me hesitant to trust the current process as timely and responsive.

I believe like this is at risk of not being enforced in practice because there is a missing piece of the Fedora Code of Conduct implementation. This policy addition seems like starting to build the second floor of a building when the foundation is not finished.

My actionable suggestion is to invest more time into the existing CoC report process. I think spelling out the existing process at pagure.io/CoC is necessary for this policy change to be successful.

@jflory7 I appreciate your concerns regarding the "foundation" and the "second floor" - our foundation is in progress and is a long process. In the interim we have begun implementing the processes as much as we can in our current structure. This is giving us great data. Unfortunately, the nature of this work is that is, almost by definition, hidden. I hope you can assume good intent and accept that we are making progress.

In the interim we have begun implementing the processes as much as we can in our current structure. This is giving us great data. Unfortunately, the nature of this work is that is, almost by definition, hidden. I hope you can assume good intent and accept that we are making progress.

I agree the content of code of conduct reports and tickets is confidential and hidden, but the policy around how Code of Conduct reports are handled should, by nature, be public and documented (even if incomplete). I believe Fedora leadership needs to make this a more urgent priority to avoid painting existing diversity and inclusion efforts as tokenism.

Consider this evaluation of the Linux kernel CoC implementation: one of its key critiques is the lack of documentation around how reports are handled and whether they are taken seriously. Some issues raised in this evaluation of CoC implementation by the Linux Foundation sound familiar to Fedora's CoC implementation.

The ongoing work for the Fedora CoC has taken over two years since conversations at the D&I Team 2017 hackfest. Existing work to understand Fedora's contributor demographics is blocked with no progress because of pending work on the Code of Conduct. The work around the demographic survey, which was the majority of our focus at the 2017 hackfest, is not used and not implemented in 2019.

From this greater context, I see either one of two possibilities:

1. The responsibility of creating and implementing changes to the Fedora CoC is the responsibility of a single person who is already busy and responsible for several other things, or
2. Fedora leadership does not see the Code of Conduct as a high priority for the Fedora community.

I always assume good intent, but good intentions alone are not sufficient to demonstrate commitment and dedication to this important aspect of community management. More transparency is needed.

From the above context, I don't believe the policy change in this PR is meaningful until the CoC reporting process is documented with greater transparency about what a reporter should expect for a response once a ticket is opened.

@jflory7:

Fedora leadership does not see the Code of Conduct as a high priority for the Fedora community.

I can tell you that this is very important to us. We recognize that the existing code of conduct has weaknesses — particularly around enforcement — and we are frustrated that this is taking a long time, too. We're continuing to work to make progress on this.

From the above context, I don't believe the policy change in this PR is meaningful until the CoC reporting process is documented with greater transparency about what a reporter should expect for a response once a ticket is opened.

Understood, and agreed, but I don't see that there's any harm in addressing this while we get the underlying CoC improvements fixed.

May be sharing some timelines for the process can help build the trust here.

@jflory7

I agree the content of code of conduct reports and tickets is confidential and hidden, but the policy around how Code of Conduct reports are handled should, by nature, be public and documented (even if incomplete). I believe Fedora leadership needs to make this a more urgent priority to avoid painting existing diversity and inclusion efforts as tokenism.

I agree that the process needs to be more transparent and documented. I disagree that a failure to document the process means the only possible conclusion is tokenism.

The ongoing work for the Fedora CoC has taken over two years since conversations at the D&I Team 2017 hackfest. Existing work to understand Fedora's contributor demographics is blocked with no progress because of pending work on the Code of Conduct. The work around the demographic survey, which was the majority of our focus at the 2017 hackfest, is not used and not implemented in 2019.
From this greater context, I see either one of two possibilities:
I always assume good intent, but good intentions alone are not sufficient to demonstrate commitment and dedication to this important aspect of community management. More transparency is needed.

I suggest that those are not the only two conclusions that can be drawn. I encourage you to consider this third one (amongst others that may exist): Fedora is not a separate legal organization. It is legally part of a large multi-national company that needs to ensure that any policies and rules issued are harmonized across all jurisdictions and legal areas it operates in. Unlike, for example, packaging guidelines, Code of Conduct issues cross into employment law, and other interpersonal areas where there are legally challenging misalignments globally. This is not work which is fast or easy and it involves large teams of people.

From the above context, I don't believe the policy change in this PR is meaningful until the CoC reporting process is documented with greater transparency about what a reporter should expect for a response once a ticket is opened.

I think this is a bit out of place here. We are asking leaders in our project to trust other leaders in our project. If that trust isn't present we have a much larger problem than reporting channel bans. Especially as these are informational reports.

@amsharma

May be sharing some timelines for the process can help build the trust here.

Normally I would agree with you here. However, I believe halting all work to get iron-clad commitments from the teams assisting us is a step backwards. I'd rather have the work continuing subject to the other emergencies that arise. I also am hesitant to see us issue timelines without having reasonable belief we can achieve them without external blockage.

Thanks @bex for replying. I understand the situation here, however the huge delay here is leading to draw conclusions which are not intended.

For "however they must file a ticket with the Council_'s https://pagure.io/CoC/issues[Code of Conduct issue tracker] to report the ban."
Does that mean one has to first open the ticket then only ban can be executed? This is IMHO not going to work the perfect way. If someone starts abusing or using vulgar language, one can't wait to open the ticket to put a ban.
Please help me understand this if I am missing something here, thanks.

Does that mean one has to first open the ticket then only ban can be executed?

Nope, that's not what it means, and yes, that would be rather silly and counter productive.