Create Slack and GitHub etiquette guidelines

[benjagm]

Work Summary

Creating a GitHub and Slack etiquette guide would be a great complement to the CoC, ensuring a good collaboration environment. More often, maintainers or reviewers are tagged in PRs, and communication is disrupted in Slack.

Example of Slack Community Etiquette:

• https://github.com/asyncapi/community/blob/master/slack-etiquette.md
• https://docs.squared.ai/open-source/community-support/slack-conduct?utm_source=chatgpt.com#multiwoven-slack-etiquette-guidelines

Some additional GitHub etiquette recommendations we'd like to include here:

• Avoid Unnecessary Mentions: Mention others only when necessary to respect their time and attention.
• Especially for first-time contributors, avoid starting working on an issue without making sure 1) the triage process has ended, and the issue is available for contributors to start working on it and, 2) the maintainer assigned the issue to you.

Other docs to connect with this guide:
#353 - How do I ask a good question?

Call to action?

Do you think this is a good idea? What other etiquette recommendations can we add here?

[aialok]

I think that for the triage process, when an issue or PR is created, we should comment with the PR/Issue guidelines, stating all the necessary details such as how the triage process works. If we are just creating simple documentation and storing it somewhere in our repository, most new contributors might not read this etiquette or guideline. It would be better to automatically add a comment with all the guidelines via GitHub Actions whenever an issue or PR is created.

https://json-schema.slack.com/archives/C05FQEMV8V6/p1734783048461039?thread_ts=1734771506.346999&cid=C05FQEMV8V6

[benjagm]

@Honyii thoughts on this?

[Honyii]

@benjagm great points about the etiquettes, what we can do is to create a list of these and;

• For slack - pin it to the general channel and also add it to the contributing guidelines.
• For Pr - I agree with @aialok 's comment. However, what happens when a pr isn't attended to for more than maybe 30/90 days ( or the max number of days a pr shouldn't be left open).
  Should we create an automation that reminds anyone that may be responsible to review the pr?

Lastly, I can start drafting the slack and github etiquettes once we finalize on this.

[aialok]

We do already have automation for PR to check whether it got stale or not after certain amount of time.

[benjagm]

@Honyii lets discuss this in our next 1:1.

[aryandhandhukiya]

Hi everyone,

I think creating a GitHub and Slack etiquette guide is a great initiative! Having clear guidelines will improve collaboration and help maintain a healthy communication environment for both contributors and maintainers. I’d like to propose a few additional recommendations that we can include in the guide.

Additional GitHub Etiquette Recommendations

• Use Clear & Descriptive Issue Titles – Avoid vague titles like "Bug in API" and instead use specific ones like "Validation Error in JSON Schema Draft-07 Parser".
• Avoid Duplicate Issues & PRs – Search existing issues before opening a new one to avoid redundancy.
• Provide Context in PRs & Issues – When submitting a PR, include a brief description of the changes, why they’re needed, and relevant references.
• Follow Up on Assigned Issues – If you're assigned an issue but can’t work on it anymore, unassign yourself or notify maintainers.
• Respect Maintainers' Time – Avoid tagging maintainers unnecessarily and give them enough time to review PRs.

Additional Slack Etiquette Recommendations

• Be Patient & Respectful – Not everyone is in the same time zone; allow time for responses.
• Use Threads for Discussions – This keeps conversations organized and prevents spamming the main channel.
• Avoid Excessive DMs – Prefer public discussions unless it's a private matter.
• Format Code Snippets Properly – Use triple backticks (```) for code blocks instead of sending unformatted text.

Connecting This Guide to Other Resources

I also support linking this guide with:

• #353 - How do I ask a good question? – Helps contributors frame their queries better.
• Existing Open Source Conduct Guidelines – e.g., AsyncAPI’s Slack Etiquette as a reference.

Would love to hear what others think! Looking forward to your feedback!