Discord request form

[neural-loop]

📝 Pull Request Template

Demo

https://github.com/neural-loop/communications/issues/new?template=discord-request.yml

📌 Summary

• What is being added or changed?
  Added a new GitHub Issue Form (discord-request.yml) for handling Discord infrastructure requests (channels, categories, roles, bots, and integrations).
• Why is this needed?
  To standardize the process for community requests, prevent Discord channel bloat, and ensure all bots/integrations are audited for security and data privacy. It also codifies the Executive Committee's authority to archive inactive spaces and requires a "Champion" for every new channel to ensure sustained activity.

---

📂 Related Issues

• Related to #XXX (Discord Management/Bot Security Discussions)

---

🧾 Type of Change

• 📄 Content Update (e.g., blog post, social post draft, newsletter copy)
• 🧠 Planning or Documentation (e.g., meeting notes, strategy doc)
• 🧰 Tooling/Infra (e.g., script, automation)
• 🐛 Bug Fix
• ✨ Feature or Enhancement
• ♻️ Refactor or Code Cleanup
• Other: describe below

---

✅ Checklist

• I have reviewed my changes and ensured clarity
• All relevant files are included and formatted properly
• I have linked to any resources or references
• I have assigned reviewers if needed
• This PR is ready for review

---

📸 Screenshots / Attachments (if applicable)

The form will appear as a structured "Issue Form" in the GitHub UI, including:

1. Request Overview (Checkboxes for type of request).
2. Community Need (Detailed prompt to justify the new space).
3. Champions (Requirement for designated maintenance leads).
4. Bot Security Section (Links to Privacy URLs and Data Destinations).
5. Legally Binding Agreements (Mandatory checkboxes for CoC and Archival policies).

---

💬 Additional Notes

This template uses the YAML "Issue Form" format, providing a much cleaner user experience than traditional Markdown templates. It ensures that critical data (like bot security URLs) cannot be skipped during submission. Indentation has been strictly validated to prevent YAML parsing errors during deployment.

[aMarcireau]

This looks good! Can we add a mention of the EC's commitment to transparency to Archival & Governance policy? That is, in the event of a unilateral channel review / merge / archival, the EC would publicly describe its view of the situation and explain why it took action (perhaps as a GitHub issue / PR that the community could comment on?).

As an aside, I do not think that the same applies to individual message moderation (that is, we do not want to publicly describe or motivate isolated moderation decisions, because this would only give more publicity to troll messages or AI spam).

[neural-loop]

This looks good! Can we add a mention of the EC's commitment to transparency to Archival & Governance policy? That is, in the event of a unilateral channel review / merge / archival, the EC would publicly describe its view of the situation and explain why it took action (perhaps as a GitHub issue / PR that the community could comment on?).

Could you review the updated text:

Archival & Governance Policy: I understand that while ONM enthusiastically welcomes new community spaces, the Executive Committee (EC) retains ultimate jurisdiction over all server infrastructure. If a hosted channel or integration undergoes a significant change in scope, becomes inactive, or creates an undue administrative burden, the EC reserves the right to review, merge, or archive the space at its sole discretion. In the spirit of transparency, if unilateral action is taken on an active forum (activity within the last 90 days), the EC will publicly communicate its reasoning (e.g., via a GitHub issue or server announcement). For idle spaces (no activity within 90 days), reasoning will be provided upon request. Additional terms and conditions may apply to specific requests on a case-by-case basis.

As an aside, I do not think that the same applies to individual message moderation (that is, we do not want to publicly describe or motivate isolated moderation decisions, because this would only give more publicity to troll messages or AI spam).

Agreed, I think we can dig into this more as we bring on moderators and explore things like an appeals process or other approaches.