[wp-meta] [Making WordPress.org] #7203: Update process for reporting unacceptable community behavior

Making WordPress.org noreply at wordpress.org
Fri Aug 11 19:36:04 UTC 2023

#7203: Update process for reporting unacceptable community behavior
 Reporter:  ironprogrammer  |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:
Component:  Handbooks       |   Keywords:
 The WordPress [https://make.wordpress.org/handbook/community-code-of-
 conduct/ Community Code of Conduct] page indicates that "Instances of
 abusive, harassing, or otherwise unacceptable behavior" in the community
 can be reported via email.

 Alternatively, reports can be sent via direct message (DM) to Slack admins
 and owners, where instances are handled like WordPress forum spam (as
 indicated in
 [https://wordpress.slack.com/archives/C02QB8GMM/p1691079747389869 a recent
 Slack thread] surrounding this question).

 Some drawbacks to these options include:
 - Lack of a reporting protocol or structure when reporting via email.
 Composing a report without guidelines may not work for many people, and
 could hinder reporting.
 - Finding an online Slack admin/owner might slow down or prevent the issue
 from being reported. For instance, this option isn't documented
 officially, so would first depend on inquiring directly or searching in
 - DMs to Slack admins/owners put the responsibility of investigation on a
 single person, or could result in the same report being sent to several

 == Could the reporting process be improved?

 It has been suggested] that a form would facilitate an easier reporting
 process, and improve the chances that an issue is actually reported. Form
 submissions might be more easily aggregated and searched by enforcement
 parties, and provide additional context during investigations.

 Some ideas:
 - The Community CoC could include a documented process and guidelines for
 submitting a report.
 - If a reporting form were implemented:
   - Categories of the type of infraction could be helpful to
 triage/prioritize incidents.
   - The ability to identify parties by name, WordPress.org ID, Slack
 username/ID, or other community contact points.
   - Reporter anonymity should be an option, at least for certain types of
 issues. (A disclaimer may be that some issues might necessitate sharing
 screenshots or personally identifying info.)
 - Given the cultural diversity within the project, updates to the process
 should still account for the possibility of "honest mistakes", and not
 necessarily assume mal-intent.

Ticket URL: <https://meta.trac.wordpress.org/ticket/7203>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org

More information about the wp-meta mailing list