nhcarrigan/docs
2
0
Fork 0
generated from nhcarrigan/template
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: rewrite all documentation (#4)

Browse Source 
Closes #3

Reviewed-on: https://codeberg.org/nhcarrigan/docs/pulls/4
Co-authored-by: Naomi Carrigan <commits@nhcarrigan.com>
Co-committed-by: Naomi Carrigan <commits@nhcarrigan.com>
This commit is contained in:
Naomi Carrigan
2024-07-08 07:56:24 +00:00
committed by Naomi the Technomancer
parent a356ffb402
commit 77a888b6bd
36 changed files with 5713 additions and 839 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/community/appeal.md
View File

@ -1,19 +1,34 @@
# Appealing A Moderator Decision
# Appealing a Sanction
Our moderators do not take punitive action (such as kicks, bans, etc.) lightly. However, misunderstandings do happen and everyone makes mistakes.
**Effective 7 July 2024**
If you feel that you were restricted from our community unfairly, you can reach out to Naomi to discuss the decision.
Our moderators exercise careful discretion when implementing disciplinary measures (including but not limited to temporary suspensions, permanent bans, or other access restrictions). However, we acknowledge that misunderstandings or errors may occasionally occur.
## Preparing for Your Appeal
If you believe you have been unjustly restricted from participating in our community, you may initiate our formal appeal process as outlined below.
Before reaching out to us, be prepared with some information.
## 1. Preparing Your Appeal
- Have you read our rules and code of conduct?
- Do you agree to follow them?
- Why do you think a moderator took action against you?
- Why do you think this action was unfair?
- Why do you want to resume interaction with our community? What value do you feel you would add?
Prior to submitting an appeal, please ensure you have the following information ready:
If you are not prepared for your appeal, we will be less likely to approve it.
1. Confirmation that you have thoroughly reviewed and understood our Community Guidelines and Terms of Service.
2. An explicit statement of your commitment to adhere to all applicable rules and policies.
3. Your understanding of the specific sanction levied against you and the alleged violation(s) cited.
4. A clear and concise explanation of why you believe the moderation decision was erroneous or disproportionate.
5. A statement detailing your motivations for seeking reinstatement and the potential positive contributions you intend to make to our community.
[Appeal A Ban](https://airtable.com/appV1cYj57zUU1Af2/pagEeCCMdz5T6cHi9/form)
Please note that incomplete or inadequately prepared appeals may be summarily dismissed.
## 2. Appeal Submission Process
To submit your appeal, please complete the form available at the following link:
[Submit a Sanction Appeal](https://airtable.com/app4JjHyeaBqt4vVH/pagOIWG3ZBEGRD8oW/form)
## 3. Important Disclaimers
- Submission of an appeal does not guarantee its approval.
- The decision of the appeals review panel is final and binding.
- We reserve the right to deny or revoke access to our services at any time, for any reason, at our sole discretion.
- Repeated violations or abuse of the appeals process may result in permanent ineligibility for reinstatement.
By submitting an appeal, you acknowledge that you have read, understood, and agree to abide by the terms outlined in this document.

397
docs/community/guide.md
View File

@ -1,28 +1,131 @@
# Community Guidelines
> [!DANGER]
> Due to the heavy nature of topics discussed in our community, and to ensure the comfort of all of our members, participants must be 18 years or older to interact with us.
> Exceptions are made for the professional platforms listed on [our contact page](/contact)
**Effective 7 July 2024**
This page documents some helpful tips that will maximise the value you get from (and bring to) our community. The guidelines here are not strict rules or requirements, but are highly encouraged to keep our community safe and cosy for everyone.
## 1. Introduction
## Do not Argue with Staff
Welcome to our community. These guidelines are designed to foster a safe, respectful, and productive environment for all members. While not exhaustive or legally binding, adherence to these principles is strongly encouraged to maintain the integrity and value of our community.
Our staff team consists of members who have been trusted with tools to help keep the community safe. But they are still human! We all make mistakes.
### 1.1. Purpose
If you feel a staff decision was made in error or bad faith, do not argue directly with the team. Instead, fill out our [appeal form](/community/appeal) and we will review your case. Only Naomi has access to this form, and submissions will only be shared in the minimum capacity necessary to investigate and resolve the issue. Your name will not be associated with any revealed submission information.
The purpose of these Community Guidelines is to:
## Plural Systems
1. Promote positive interactions and meaningful discussions
1. Protect the well-being and rights of all community members
1. Maintain a welcoming atmosphere for diverse perspectives and backgrounds
Plural systems are more than welcome in our community. Please do not pressure someone to reveal information about one of their alters, or attempt to discover who used Melody's plural proxying.
### 1.2 Scope
Systems are welcome to disclose whatever information they want about their alters.
These guidelines apply to all forms of interaction within our community, including but not limited to:
## Tone Tags
- Forum discussions
- Comment sections
- Direct messaging
- Live events or webinars
- Social media interactions associated with our community
One of the biggest disadvantages of text-based communication is the loss of context that provides the tone of the message. To help with this, we use tone tags as needed when the tone of a message might be misinterpreted.
### 1.3 Encouragement to Participate
We encourage you to use these tags as needed.
We highly value your contributions and encourage you to:
1. Actively engage in discussions and share your knowledge
2. Provide constructive feedback and support to fellow members
3. Report any concerns or violations to the community moderators
4. Suggest improvements to enhance the community experience
### 1.4 Code of Conduct
While many aspects of our Community Guidelines are recommendations, our Code of Conduct establishes non-negotiable standards that ALL community members MUST adhere to in ALL interactions within our community spaces.
Nothing in this guide may supercede or overwrite the Code of Conduct.
## 2. Interacting with Staff
### 2.1 Respect for Authority
Our staff team consists of trusted members empowered with tools to maintain community safety and harmony. While they strive for fairness and consistency, it's important to recognize their human nature and the potential for occasional errors.
### 2.2 Dispute Resolution Process
If you believe a staff decision was made in error or in bad faith, we encourage you to follow these steps:
1. Refrain from direct argumentation or confrontation with staff members.
2. Document the incident, including relevant details and any supporting evidence.
3. Submit an appeal through our official [appeal form](/community/appeal).
### 2.3 Appeal Process
- Appeals are reviewed by Naomi, who has exclusive access to the submission form.
- All appeals will be treated confidentially and impartially.
- Information from submissions will only be shared on a need-to-know basis to investigate and resolve the issue.
- Your identity will be protected; any revealed submission information will not be associated with your name.
### 2.4 Staff Accountability
We are committed to maintaining high standards of conduct for our staff. Any substantiated claims of misconduct or abuse of power will be addressed promptly and appropriately.
### 2.5 Continuous Improvement
We value your feedback on our moderation processes. If you have suggestions for improving our systems or policies, please submit them through the appropriate channels.
## 3. Plural Systems
### 3.1 Understanding Plurality
Plural systems refer to individuals who experience the presence of two or more distinct identities or personality states, often called alters. Our community recognizes and respects the existence of plural systems.
### 3.2 Inclusivity and Respect
1. Plural systems are fully welcome and valued members of our community.
2. We are committed to providing a safe and supportive environment for all system members.
3. Discrimination or harassment based on plurality is strictly prohibited.
### 3.3 Privacy and Boundaries
1. Respect the privacy of plural systems and their individual alters.
2. Do not pressure or attempt to coerce any system or alter to reveal information they are not comfortable sharing.
3. Refrain from trying to identify which alter is fronting or using a platform's plural proxying service.
### 3.4 Self-Disclosure
1. Systems have the right to disclose information about their alters at their own discretion.
2. Members are encouraged to respect the level of disclosure each system or alter chooses.
3. Unsolicited advice or attempts to "help" without consent are not appropriate.
### 3.5 Communication Guidelines
1. Address alters by their preferred names and pronouns when known.
2. If unsure about how to address a system or alter, it's acceptable to politely ask for clarification.
3. Be mindful that switching between alters may result in a difference of communication styles or preferences.
### 3.6 Education and Awareness
1. We encourage community-wide education about plurality to foster understanding and inclusivity.
2. Questions about plurality should be directed to appropriate educational resources rather than to individual systems, unless they have explicitly welcomed such inquiries.
## 4. Tone Tags
### 4.1 Purpose of Tone Tags
In text-based communication, the nuances of tone and intention can often be lost, leading to potential misunderstandings. To address this limitation, we encourage the use of tone tags. These tags provide additional context to messages, helping to clarify the intended tone and reduce misinterpretations.
### 4.2 When to Use Tone Tags
Consider using tone tags in the following situations:
- When your message could be interpreted in multiple ways
- If you're using sarcasm, humor, or other tones that might not be immediately apparent
- When discussing sensitive topics where clarity of intention is crucial
- If you're communicating with someone who has expressed difficulty interpreting tone in text
### 4.3 How to Use Tone Tags
- Place the tone tag at the end of your message or the relevant section
- Use forward slashes to enclose the tag, e.g., /j for joking
- You can use multiple tags if needed, e.g., /s /lh for sarcastic and light-hearted
- If you're unsure about a tag's meaning, refer to our community glossary or ask for clarification
### 4.4 Commonly Used Tone Tags
| Tag | Meaning |
| ---------------------- | ------------------------------------ |
@ -78,8 +181,270 @@ We encourage you to use these tags as needed.
| `/t` | Teasing |
| `/tc`, `/ti` or `/tic` | Typing a tic |
## Pronouns
### 4.5 Respecting Tone Tags
You are encouraged to display your pronouns in your platform bio (or use the roles in our Discord community). Doing this not only helps others know how to refer to you, but also helps normalise the practice of sharing pronouns.
- When someone uses a tone tag, interpret their message accordingly
- If you're unsure about the meaning of a tag, ask politely for clarification
- Do not mock or belittle others for using tone tags
By normalising that practice, we fight against the assumption that only trans folk share their pronouns, which makes our community safer for trans folk to do so without implicitly outing themselves.
### 4.6 Accessibility Considerations
- Tone tags can be particularly helpful for neurodivergent individuals who may have difficulty interpreting tone in text
- Screen readers can often interpret tone tags, making them a useful tool for visually impaired users
### 4.7 Limitations of Tone Tags
- While helpful, tone tags are not a perfect solution and may not convey all nuances of communication
- They should be used as a supplement to clear writing, not a replacement for it
### 4.8 Community-Specific Tags
- Our community may develop additional tags specific to our discussions
- New tags will be added to our glossary after community consensus
## 5. Pronouns
### 5.1 Importance of Pronouns
Pronouns are an essential aspect of personal identity and respectful communication. Our community values and respects each individual's right to self-identify and be addressed correctly.
### 5.2 Displaying Pronouns
We strongly encourage all community members to display their pronouns:
- In your platform bio
- Using designated pronoun roles in our Discord community, or comparable feature on other platforms
- As part of your username or display name, if desired
### 5.3 Benefits of Sharing Pronouns
1. Clarity: Helps others address you correctly
2. Inclusivity: Creates a welcoming environment for all gender identities
3. Normalization: Reduces stigma around pronoun sharing
4. Education: Raises awareness about gender diversity
### 5.4 Normalizing Pronoun Sharing
By encouraging all members to share pronouns, regardless of gender identity or expression, we:
- Challenge the assumption that only transgender individuals share pronouns
- Create a safer space for transgender and non-binary individuals to share their pronouns without implicitly outing themselves
- Promote a culture of respect and understanding
### 5.5 Respecting Others' Pronouns
- Always use the pronouns a person has specified for themselves
- If you're unsure about someone's pronouns, it's appropriate to politely ask
- If you make a mistake, apologize briefly, correct yourself, and move on
### 5.6 Pronoun Options
While not exhaustive, common pronoun options include:
- She/her/hers
- He/him/his
- They/them/theirs
- Neopronouns (e.g., xe/xem/xyr, ze/zir/zirs)
- Any pronouns
- No pronouns (use name only)
### 5.7 Changing Pronouns
- Members are welcome to update their pronouns at any time
- Respect and use a person's current pronouns, even if you knew them by different pronouns previously
### 5.8 Pronoun Misuse
- Intentional misuse of pronouns (misgendering) is a form of harassment and violates our community guidelines
- Repeated accidental misuse, despite correction, may be addressed by moderation
### 5.9 Privacy Considerations
- While we encourage pronoun sharing, it is ultimately a personal choice
- Do not pressure others to share their pronouns if they are not comfortable doing so
## 6. Accessibility
Our community is committed to ensuring that all members, regardless of their needs, can fully participate and engage with our content. We encourage everyone to follow these accessibility guidelines to create a more inclusive environment.
### 6.1 Alt Text for Images
Alt text (alternative text) provides a textual description of images for those who use screen readers or cannot view images.
- Always include alt text when posting images.
- Describe the key elements of the image concisely.
- If the image contains text, include that text in the alt description.
Example: Instead of alt="meme", use alt="A cat wearing sunglasses with the text 'Deal with it' below"
### 6.2 Creating Accessible Content
#### 6.2.1 Descriptive Link Text
- Use descriptive link text that indicates where the link leads.
- Avoid using "click here" or "read more" as standalone link text.
Example: Instead of "Click here to read about our events", use "View our upcoming community events"
#### 6.2.2 Avoiding Flashing Content
- Do not post content that flashes more than three times per second.
- If you must share such content, provide a clear warning beforehand.
#### 6.2.3 Structuring Content
- Use headings to organize content hierarchically (H1, H2, H3, etc.).
- Break long paragraphs into shorter, more digestible sections.
- Use bullet points or numbered lists for easy scanning.
#### 6.2.4 Multimedia Content
- Provide captions for videos.
- Offer transcripts for audio content when possible.
### 6.3 Continuous Improvement
- We welcome feedback on how to improve our community's accessibility.
- Report any accessibility issues to the moderation team.
## 7. Content and Trigger Warnings
Our community is committed to creating a safe and respectful environment for all members. Content and trigger warnings play a crucial role in this effort by allowing individuals to make informed decisions about engaging with potentially distressing content.
### 7.1 Purpose of Content/Trigger Warnings
- To give members advance notice of potentially sensitive or disturbing content
- To allow individuals to prepare themselves emotionally or choose to avoid the content
- To promote a culture of empathy and consideration within our community
### 7.2 When to Use Warnings
Use content or trigger warnings when posting about:
- Graphic violence or gore
- Sexual content or explicit discussions of sexuality
- Abuse (physical, emotional, sexual)
- Self-harm or suicide
- Eating disorders or body image issues
- Substance abuse or addiction
- Mental health issues
- Phobias (e.g., spiders, heights, confined spaces)
- Political extremism or hate speech
- Natural disasters or traumatic events
- Flashing images or loud noises (for photosensitive epilepsy)
Remember, this list is not exhaustive. If you're unsure whether content needs a warning, err on the side of caution and provide one.
### 7.3 How to Use Content/Trigger Warnings
- Place the warning at the beginning of your post or message
- Use clear, specific language
- If possible, use spoiler tags or a "read more" cut to hide the sensitive content
Example formats:
"CW: Discussion of eating disorders"
"TW: Graphic description of violence"
"Content Warning: This post contains references to suicide"
### 7.4 Respecting Warnings
- Do not mock or belittle others for using or needing content warnings
- If someone asks for a warning on a specific topic, respect their request in future interactions
### 7.5 False Alarms and Overuse
While we encourage the use of content warnings, try to avoid overuse for mundane topics. This helps maintain their effectiveness for truly sensitive content.
### 7.6 Moderator Intervention
Moderators may add content warnings to posts if they deem it necessary. Repeated failure to use appropriate warnings may result in moderation action.
## 8. Conflict Resolution
Disagreements and conflicts can arise in any community. Our goal is to foster an environment where conflicts can be resolved respectfully and constructively. This section outlines the steps for resolving conflicts and when to involve moderators.
### 8.1 General Principles
- Treat all parties with respect, even in disagreement
- Assume good faith unless proven otherwise
- Focus on the issue, not personal attacks
- Be open to different perspectives and willing to compromise
### 8.2 Steps for Resolving Conflicts
#### 8.2.1 Direct Communication
- If you have an issue with another member, try to address it directly with them first.
- Use private messages to avoid public confrontations.
- Clearly and calmly explain your concerns, using "I" statements.
- Listen to their perspective without interrupting.
- Look for common ground and potential solutions.
#### 8.2.2 Cool-Down Period
If emotions are running high:
- Take a break from the discussion.
- Reflect on the issue and your role in the conflict.
- Return to the conversation when you can discuss it calmly.
#### 8.2.3 Seeking Mediation
If direct communication doesn't resolve the issue:
- Ask a neutral third party from the community to mediate.
- Both parties should agree on the mediator.
- The mediator should facilitate discussion, not take sides.
### 8.3 When to Involve Moderators
Involve moderators if:
- The conflict violates our Code of Conduct
- You feel unsafe or harassed
- The conflict is disrupting the broader community
- Previous attempts at resolution have failed
- You're unsure how to handle the situation
### 8.4 How to Involve Moderators
- Use the designated reporting system on the platform.
- Provide a clear, factual account of the issue.
- Include relevant screenshots or links if applicable.
- Explain steps you've already taken to resolve the conflict.
### 8.5 Moderator Actions
Moderators may:
- Facilitate discussion between parties
- Issue warnings or reminders about community guidelines
- Temporarily mute or suspend accounts
- Remove inflammatory content
- In severe cases, ban members who consistently create conflicts
### 8.6 Appealing Moderator Decisions
If you disagree with a moderator's decision:
- Wait 24 hours to ensure you can discuss it calmly
- Contact the moderation team through the appropriate channels
- Clearly explain why you think the decision should be reconsidered
- Be prepared to provide additional context or evidence
### 8.7 Conflict Prevention
To minimize conflicts:
- Re-read your posts before sending to ensure they're not unintentionally inflammatory
- Use tone indicators when your intent might be unclear
- Ask for clarification before assuming negative intent
- Be willing to apologize and correct mistakes
### 8.8 Learning from Conflicts
After a conflict is resolved:
- Reflect on what led to the disagreement
- Consider how it could have been prevented or handled better
- Apply these lessons in future interactions

12
docs/community/hall-of-fame.md Normal file
View File

@ -0,0 +1,12 @@
# Hall of Fame
**Effective 7 July 2024**
## 1. Purpose
This document recognises the folks who have reported security vulnerabilities in our Applications pursuant to our [security policy](/security).
## 2. Recognitions
We extend our thanks to the following people for their efforts in keeping our users secure:

92
docs/community/labels.md
View File

@ -1,92 +0,0 @@
# Labels
We use very specific labels to help categorise our issues. This page explains what each label means.
## Contribution Labels
These are the most important. These labels indicate who is encouraged to make a pull request to resolve the issue.
| Label | Explanation |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `good first issue` | An issue with this label is intended for contributors who are brand new to the project. These issues should not require prior knowledge of the codebase, and the conversation on the issue will include a detailed description of how to implement a resolution. |
| `help wanted` | These issues are open for contribution from anyone who is interested. The conversation may not include a detailed description, as these issues typically assume you have prior experience with the codebase. |
| `🔒 staff only` | These issues require specific access to the production infrastructure to test properly. These are restricted to project maintainers/staff for that reason. |
## Aspect Labels
These labels indicate the scope of the work required to resolve the issue.
| Label | Explanation |
| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `💻 aspect: code` | This is the most common. These issues require work on the project's code-base. |
| `🤖 aspect: dx` | These issues typically require changes to the project's tooling, such as automated tests, development dependencies, etc. |
| `🕹 aspect: interface` | These issues might require code changes, but these are specifically things that require changing the end-user's experience. This might be something like CSS changes, or replacing an image. |
| `📄 aspect: text` | These issues are related to a project's documentation. These don't require code changes, but might require markdown experience as most of our documentation is written in markdown. |
## Goal Labels
These labels indicate the goal of the issue. Our projects tend to follow a specific modular approach, and these labels help indicate the type of changes you might be making.
| Label | Explanation |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `⭐ goal: addition` | These issues add a new feature to the project. Typically, this means you're adding a new code file from scratch, following the project's style. |
| `🛠 goal: fix` | These issues fix a bug in the project. Typically, this means you're editing existing code within existing files. |
| `✨ goal: improvement` | These issues expand upon an existing feature. Typically, this means you're adding code to an existing file, but not necessarily adding new files. |
## Priority Labels
The priority labels indicate the importance we've assigned to a specific issue. The higher the priority, the more of a focus it is for our team.
| Label | Explanation |
| ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `🟥 priority: critical` | These issues are typically show-stoppers. This label is reserved for issues which need immediate attention because the project is **unusable** until they are resolved. |
| `🟧 priority: high` | This label applies to issues that aren't preventing the project from being _functional_, but are preventing further development until they're resolved. |
| `🟨 priority: medium` | Medium priority issues are things that we want resolved as soon as possible, but they aren't preventing other development from occurring. |
| `🟩 priority: low` | This is probably the most common label. This is for issues that we'd like resolved, but aren't considered as things we want done ASAP. |
| `🟪 priority: none` | This label indicates an issue that would be nice to have resolved, but isn't essential enough to dedicate maintainer time to fixing. |
## Status Labels
Status labels allow you to see where a ticket is at in the lifecycle of the project.
| Label | Explanation |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `🚦 status: awaiting triage` | This is the most common status label. This label is automatically applied to new issues, and indicates that the maintainer team has not reviewed and responded to the issue. You are still welcome to share your thoughts, but these issues have not received any maintainer attention. |
| `🚧 status: blocked` | This label is applied to issues that might have a planned resolution, but that resolution depends on a separate issue being resolved. These aren't ready for work **yet**, but will be soon. |
| `⛔️ status: discarded` | This label applies to an issue that we don't intend to resolve. Typically, this is on feature requests that aren't in line with the project's goals. |
| `🙅 status: discontinued` | We rarely use this label, but this applies to feature request issues on projects that are solely in maintenance mode - that is, projects we aren't adding new features to but are still supporting and providing bug fixes for. |
| `🏷 status: label work required` | This applies to an issue that might have some discussion on it, but hasn't been appropriately labelled and categorised. |
| `🏁 status: ready for dev` | These issues are ready for contribution. If a contributor is assigned, they have indicated interest in working on the issue and we encourage you to collaborate. This pairs with the Contribution Labels listed above. |
| `🧹 status: ticket work required` | This label indicates that the issue does not have enough information for proper triage. Typically, this pairs with the Conversation Labels listed below. |
## Conversation Labels
These labels indicate that the issue has received initial maintainer attention, but is waiting on more information from the author or the maintainer team.
| Label | Explanation |
| --------------------- | ---------------------------------------------------------------------------------------------------- |
| `💬 talk: discussion` | This issue is being actively discussed, but has not been accepted as something we intend to resolve. |
| `❓ talk: question` | These issues are waiting on additional information from the author in order to triage properly. |
## Special Labels
These labels are specifically used for unique events.
| Label | Explanation |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Hacktoberfest` | This issue is indicated as a valid contribution opportunity for Hacktoberfest. |
| `hacktoberfest-accepted` | This is used to label pull requests which are valid Hacktoberfest contributions, but might not be merged in time for the event. |
| `invalid` | This label is specifically used on pull requests which were made with the goal of spamming Hacktoberfest contributions, and were not made in good faith. |
## Pull Request Labels
We have automation that applies specific labels to our pull requests.
| Label | Explanation |
| --------------------------- | ---------------------------------------------------------------------------------------------------------- |
| `✅ pull: accepted` | This pull request has been merged into the code base. |
| `⚠️ pull: merge conflict` | This pull request has conflicts with the target branch. Those need to be resolved before we can review it. |
| `🔍 pull: ready for review` | This pull request is not in draft mode and is waiting for maintainer review. |
| `❌ pull: rejected` | This pull request was not accepted by maintainers and was closed. |
| `⏫ pull: requires update` | This pull request has had changes requested by the maintainer team. |
| `⚒️ pull: work in progress` | This pull request is in draft mode and is not ready for review. |

58
docs/community/melody.md
View File

@ -1,58 +0,0 @@
# Melody Iuvo
You may see Melody in our Discord, or responding to issues on GitHub. Melody is a bot, and she serves as our community assistant.
## GitHub
On GitHub, Melody handles the automatic invitation flow for new organisation members.
She also welcomes new contributors, and thanks contributors when a PR is merged.
## Discord
Melody is much more full featured on Discord. She has a number of commands that you can use to interact with the community.
### Assets
All of Naomi's assets can be accessed through Melody. These assets are provided as reference (for things like fan art or commissions).
> [!WARNING]
> Assets may not be repurposed or redistributed without prior permission from Naomi.
These commands are under `/assets`.
### Currency System
Melody manages our community's currency system. This system grants you NaomiCoin for sending messages and interacting with your fellow members. You can use these NaomiCoin to purchase special items, such as a custom colour role or the ability to set Naomi's avatar. You can also gamble for more coin through the slots!
These commands are under `/currency`.
### Frequently Asked Questions
For help with navigating our community, we created a FAQ system with common questions we see. Questions are mainly examples of "Where do I do X?" or "How do I do Y?".
Questions may be added and edited through [GitHub](https://github.com/naomis-novas/melody-iuvo/blob/main/src/config/Faq.ts).
These commands are under `/faq`.
### Fun Commands
There are a couple of commands related to Naomi, which are added just for fun. You can ask Naomi anonymous questions, or generate a quote image with her avatar.
These commands are under `/naomi`.
There is also a `/tarot` command, which allows you to get a daily tarot card reading, and a `/yokai` command, which allows you to get information about a random yokai.
### Plural Systems
Melody allows you to proxy your messages much like PluralKit or Tupperbox. You can set up identities for your alters, configure a prefix, and choose an avatar. You can also set up auto-proxying.
These commands are under `/plural`.
### Streams
Naomi streams on [Twitch](https://twitch.tv/naomilgbt), and Melody has a couple of commands to support this. The `/game` command allows you to fetch a random game from Naomi's library, and the `/queue` command allows you to see Naomi's planned list of games to play on stream.
### Ticket System
Melody also handles the private support ticket system. If you need to create a private discussion with our team, use the Open a Ticket button found in the `#our-work` channel.