generated from nhcarrigan/template
Compare commits
No commits in common. "b8650dfa734961eb767f7bf49d0e7f201ab2bd59" and "b87eb33492088844c343c968181739b34e20f9e1" have entirely different histories.
b8650dfa73
...
b87eb33492
34
.cspell.json
34
.cspell.json
@ -1,34 +0,0 @@
|
||||
{
|
||||
"language": "en-GB",
|
||||
"allowCompoundWords": true,
|
||||
"dictionaries": [
|
||||
"en-gb",
|
||||
"companies",
|
||||
"softwareTerms",
|
||||
"typescript",
|
||||
"node",
|
||||
"html",
|
||||
"css",
|
||||
"bash"
|
||||
],
|
||||
"ignoreRegExpList": [
|
||||
"```[\\s\\S]*?```", // Ignores multi-line code blocks in Markdown
|
||||
"`[^`\n]+`" // Ignores inline code blocks
|
||||
],
|
||||
"ignoreWords": [
|
||||
"nhcarrigan",
|
||||
"fiverr",
|
||||
"misgendering",
|
||||
"neurodiversity",
|
||||
"recused",
|
||||
"neurodivergent",
|
||||
"hyfetch",
|
||||
"technomancer",
|
||||
"Wofi",
|
||||
"Dunst",
|
||||
"SonarQube",
|
||||
"Grype",
|
||||
"Syft",
|
||||
"Ghostty"
|
||||
]
|
||||
}
|
||||
3
.gitattributes
vendored
3
.gitattributes
vendored
@ -5,5 +5,4 @@
|
||||
|
||||
# Ignore binary files >:(
|
||||
*.png binary
|
||||
*.jpg binary
|
||||
*.otf binary
|
||||
*.jpg binary
|
||||
27
.gitignore
vendored
27
.gitignore
vendored
@ -1,27 +0,0 @@
|
||||
# build output
|
||||
dist/
|
||||
# generated types
|
||||
.astro/
|
||||
|
||||
# dependencies
|
||||
node_modules/
|
||||
|
||||
# logs
|
||||
npm-debug.log*
|
||||
yarn-debug.log*
|
||||
yarn-error.log*
|
||||
pnpm-debug.log*
|
||||
|
||||
|
||||
# environment variables
|
||||
.env
|
||||
.env.production
|
||||
|
||||
# macOS-specific files
|
||||
.DS_Store
|
||||
|
||||
# jetbrains setting folder
|
||||
.idea/
|
||||
|
||||
# SonarCloud
|
||||
.scannerwork/
|
||||
@ -1,5 +0,0 @@
|
||||
{
|
||||
"line-length": false,
|
||||
"no-bare-urls": false,
|
||||
"no-blanks-blockquote": false
|
||||
}
|
||||
58
README.md
58
README.md
@ -1,47 +1,39 @@
|
||||
# Astro Starter Kit: Minimal
|
||||
# New Repository Template
|
||||
|
||||
```sh
|
||||
npm create astro@latest -- --template minimal
|
||||
```
|
||||
This template contains all of our basic files for a new GitHub repository. There is also a handy workflow that will create an issue on a new repository made from this template, with a checklist for the steps we usually take in setting up a new repository.
|
||||
|
||||
[](https://stackblitz.com/github/withastro/astro/tree/latest/examples/minimal)
|
||||
[](https://codesandbox.io/p/sandbox/github/withastro/astro/tree/latest/examples/minimal)
|
||||
[](https://codespaces.new/withastro/astro?devcontainer_path=.devcontainer/minimal/devcontainer.json)
|
||||
If you're starting a Node.JS project with TypeScript, we have a [specific template](https://github.com/naomi-lgbt/nodejs-typescript-template) for that purpose.
|
||||
|
||||
> 🧑🚀 **Seasoned astronaut?** Delete this file. Have fun!
|
||||
## Readme
|
||||
|
||||
## 🚀 Project Structure
|
||||
Delete all of the above text (including this line), and uncomment the below text to use our standard readme template.
|
||||
|
||||
Inside of your Astro project, you'll see the following folders and files:
|
||||
<!-- # Project Name
|
||||
|
||||
```text
|
||||
/
|
||||
├── public/
|
||||
├── src/
|
||||
│ └── pages/
|
||||
│ └── index.astro
|
||||
└── package.json
|
||||
```
|
||||
Project Description
|
||||
|
||||
Astro looks for `.astro` or `.md` files in the `src/pages/` directory. Each page is exposed as a route based on its file name.
|
||||
## Live Version
|
||||
|
||||
There's nothing special about `src/components/`, but that's where we like to put any Astro/React/Vue/Svelte/Preact components.
|
||||
This page is currently deployed. [View the live website.]
|
||||
|
||||
Any static assets, like images, can be placed in the `public/` directory.
|
||||
## Feedback and Bugs
|
||||
|
||||
## 🧞 Commands
|
||||
If you have feedback or a bug report, please feel free to open a GitHub issue!
|
||||
|
||||
All commands are run from the root of the project, from a terminal:
|
||||
## Contributing
|
||||
|
||||
| Command | Action |
|
||||
| :------------------------ | :----------------------------------------------- |
|
||||
| `npm install` | Installs dependencies |
|
||||
| `npm run dev` | Starts local dev server at `localhost:4321` |
|
||||
| `npm run build` | Build your production site to `./dist/` |
|
||||
| `npm run preview` | Preview your build locally, before deploying |
|
||||
| `npm run astro ...` | Run CLI commands like `astro add`, `astro check` |
|
||||
| `npm run astro -- --help` | Get help using the Astro CLI |
|
||||
If you would like to contribute to the project, you may create a Pull Request containing your proposed changes and we will review it as soon as we are able! Please review our [contributing guidelines](CONTRIBUTING.md) first.
|
||||
|
||||
## 👀 Want to learn more?
|
||||
## Code of Conduct
|
||||
|
||||
Feel free to check [our documentation](https://docs.astro.build) or jump into our [Discord server](https://astro.build/chat).
|
||||
Before interacting with our community, please read our [Code of Conduct](CODE_OF_CONDUCT.md).
|
||||
|
||||
## License
|
||||
|
||||
This software is licensed under our [global software license](https://docs.nhcarrigan.com/#/license).
|
||||
|
||||
Copyright held by Naomi Carrigan.
|
||||
|
||||
## Contact
|
||||
|
||||
We may be contacted through our [Chat Server](http://chat.nhcarrigan.com) or via email at `contact@nhcarrigan.com`. -->
|
||||
|
||||
@ -1,68 +0,0 @@
|
||||
import { defineConfig } from 'astro/config';
|
||||
import starlight from "@astrojs/starlight";
|
||||
|
||||
import { navigation } from "./src/components/navigation.ts";
|
||||
|
||||
export default defineConfig({
|
||||
site: "https://docs.nhcarrigan.com",
|
||||
integrations: [starlight({
|
||||
components: {
|
||||
Footer: "./src/components/Footer.astro",
|
||||
ThemeSelect: "./src/components/ThemeSelect.astro",
|
||||
ThemeProvider: "./src/components/ThemeProvider.astro",
|
||||
},
|
||||
title: "NHCarrigan Docs",
|
||||
sidebar: navigation,
|
||||
tableOfContents: { minHeadingLevel: 2, maxHeadingLevel: 4},
|
||||
description: "This site contains all of the documentation related to NHCarrigan, its Policies, and its Projects.",
|
||||
editLink: {
|
||||
baseUrl: "https://codeberg.org/nhcarrigan/docs/_edit/main/",
|
||||
label: "Edit this page on Codeberg"
|
||||
},
|
||||
lastUpdated: true,
|
||||
social: {
|
||||
codeberg: "https://codeberg.org/nhcarrigan",
|
||||
github: "https://github.com/nhcarrigan",
|
||||
discord: "https://chat.nhcarrigan.com"
|
||||
},
|
||||
head: [
|
||||
{
|
||||
tag: "script",
|
||||
attrs: {
|
||||
type: "text/javascript",
|
||||
id: "hs-script-loader",
|
||||
async: true,
|
||||
defer: true,
|
||||
src: "https://js.hs-scripts.com/47086586.js"
|
||||
}
|
||||
},
|
||||
{
|
||||
tag: "script",
|
||||
attrs: {
|
||||
type: "text/javascript",
|
||||
id: "analytics",
|
||||
src: "https://analytics.nhcarrigan.com/js/script.file-downloads.outbound-links.js",
|
||||
defer: true,
|
||||
"data-domain": "nhcarrigan.com"
|
||||
}
|
||||
},
|
||||
{
|
||||
tag: "script",
|
||||
content: "window.plausible = window.plausible || function() { (window.plausible.q = window.plausible.q || []).push(arguments) }"
|
||||
},
|
||||
{
|
||||
tag: "script",
|
||||
attrs: {
|
||||
type: "text/javascript",
|
||||
id: "trees",
|
||||
src: "https://widgets.tree-nation.com/js/widgets/v1/widgets.min.js?v=1.0",
|
||||
defer: true
|
||||
}
|
||||
}
|
||||
],
|
||||
customCss: [
|
||||
"./src/styles/style.css",
|
||||
"./src/fonts/font-face.css"
|
||||
],
|
||||
})]
|
||||
});
|
||||
23
package.json
23
package.json
@ -1,23 +0,0 @@
|
||||
{
|
||||
"name": "magical-metal",
|
||||
"type": "module",
|
||||
"version": "0.0.1",
|
||||
"scripts": {
|
||||
"dev": "astro dev",
|
||||
"start": "astro dev",
|
||||
"lint": "cspell src/content/docs",
|
||||
"build": "astro build",
|
||||
"preview": "astro preview",
|
||||
"astro": "astro",
|
||||
"scan": "SONAR_TOKEN='op://Environment Variables - Development/SonarCloud/docs' op run -- sonar-scanner -Dsonar.organization=nhcarrigan -Dsonar.projectKey=nhcarrigan_docs -Dsonar.sources=. -Dsonar.host.url=https://sonarcloud.io"
|
||||
},
|
||||
"dependencies": {
|
||||
"@astrojs/check": "^0.9.3",
|
||||
"@astrojs/starlight": "^0.26.1",
|
||||
"astro": "^4.14.5",
|
||||
"typescript": "^5.5.4"
|
||||
},
|
||||
"devDependencies": {
|
||||
"cspell": "8.17.0"
|
||||
}
|
||||
}
|
||||
5740
pnpm-lock.yaml
generated
5740
pnpm-lock.yaml
generated
File diff suppressed because it is too large
Load Diff
@ -1,9 +0,0 @@
|
||||
<svg xmlns="http://www.w3.org/2000/svg" fill="none" viewBox="0 0 128 128">
|
||||
<path d="M50.4 78.5a75.1 75.1 0 0 0-28.5 6.9l24.2-65.7c.7-2 1.9-3.2 3.4-3.2h29c1.5 0 2.7 1.2 3.4 3.2l24.2 65.7s-11.6-7-28.5-7L67 45.5c-.4-1.7-1.6-2.8-2.9-2.8-1.3 0-2.5 1.1-2.9 2.7L50.4 78.5Zm-1.1 28.2Zm-4.2-20.2c-2 6.6-.6 15.8 4.2 20.2a17.5 17.5 0 0 1 .2-.7 5.5 5.5 0 0 1 5.7-4.5c2.8.1 4.3 1.5 4.7 4.7.2 1.1.2 2.3.2 3.5v.4c0 2.7.7 5.2 2.2 7.4a13 13 0 0 0 5.7 4.9v-.3l-.2-.3c-1.8-5.6-.5-9.5 4.4-12.8l1.5-1a73 73 0 0 0 3.2-2.2 16 16 0 0 0 6.8-11.4c.3-2 .1-4-.6-6l-.8.6-1.6 1a37 37 0 0 1-22.4 2.7c-5-.7-9.7-2-13.2-6.2Z" />
|
||||
<style>
|
||||
path { fill: #000; }
|
||||
@media (prefers-color-scheme: dark) {
|
||||
path { fill: #FFF; }
|
||||
}
|
||||
</style>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 749 B |
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 164 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.9 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
@ -1,49 +0,0 @@
|
||||
---
|
||||
import LastUpdated from "@astrojs/starlight/components/LastUpdated.astro";
|
||||
import EditLink from "@astrojs/starlight/components/EditLink.astro";
|
||||
import Pagination from "@astrojs/starlight/components/Pagination.astro";
|
||||
---
|
||||
|
||||
<footer class="sl-flex">
|
||||
<div class="meta sl-flex">
|
||||
<EditLink {...Astro.props} />
|
||||
<LastUpdated {...Astro.props} />
|
||||
</div>
|
||||
<Pagination {...Astro.props} />
|
||||
<div id="tree-nation-offset-website"></div>
|
||||
<script>
|
||||
TreeNationOffsetWebsite({
|
||||
code: "a17464e0cd351220",
|
||||
lang: "en",
|
||||
theme: "dark",
|
||||
}).render("#tree-nation-offset-website");
|
||||
</script>
|
||||
<video
|
||||
autoplay={true}
|
||||
loop={true}
|
||||
muted={true}
|
||||
playsinline={true}
|
||||
src="https://cdn.nhcarrigan.com/overlay.webm"
|
||||
style={{ pointerEvents: "none", position: "fixed", top: 0, left: 0, opacity: 0.25, zIndex:100, width: "100vw", height: "100vh"}}></video>
|
||||
</footer>
|
||||
|
||||
<style>
|
||||
footer {
|
||||
flex-direction: column;
|
||||
gap: 1.5rem;
|
||||
}
|
||||
.meta {
|
||||
gap: 0.75rem 3rem;
|
||||
justify-content: space-between;
|
||||
flex-wrap: wrap;
|
||||
margin-top: 3rem;
|
||||
font-size: var(--sl-text-sm);
|
||||
color: var(--sl-color-gray-3);
|
||||
}
|
||||
.meta > :global(p:only-child) {
|
||||
margin-inline-start: auto;
|
||||
}
|
||||
#tree-nation-offset-website {
|
||||
margin: auto;
|
||||
}
|
||||
</style>
|
||||
@ -1,3 +0,0 @@
|
||||
<script is:inline>
|
||||
document.documentElement.dataset.theme = "light";
|
||||
</script>
|
||||
@ -1,157 +0,0 @@
|
||||
export const navigation = [
|
||||
{
|
||||
label: "About Us",
|
||||
items: [
|
||||
{
|
||||
label: "Mission Statement",
|
||||
link: "/about/mission"
|
||||
},
|
||||
{
|
||||
label: "Sustainability",
|
||||
link: "/about/sustainability"
|
||||
},
|
||||
{
|
||||
label: "Hire us!",
|
||||
link: "/about/hire"
|
||||
},
|
||||
{
|
||||
label: "Support Our Work 💜",
|
||||
link: "/about/donate"
|
||||
},
|
||||
{
|
||||
label: "Contact",
|
||||
link: "/about/contact"
|
||||
},
|
||||
{
|
||||
label: "Mentorship",
|
||||
link: "/about/mentorship"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: "Legal Information",
|
||||
items: [
|
||||
{
|
||||
label: "Terms of Service",
|
||||
link: "/legal/terms"
|
||||
},
|
||||
{
|
||||
label: "Privacy Policy",
|
||||
link: "/legal/privacy"
|
||||
},
|
||||
{
|
||||
label: "Software License",
|
||||
link: "/legal/license"
|
||||
},
|
||||
{
|
||||
label: "Security Policy",
|
||||
link: "/legal/security"
|
||||
},
|
||||
{
|
||||
label: "DMCA and Copyright",
|
||||
link: "/legal/dmca"
|
||||
},
|
||||
{
|
||||
label: "Subprocessors List",
|
||||
link: "/legal/subprocessors"
|
||||
},
|
||||
{
|
||||
label: "Government Actions",
|
||||
link: "/legal/government"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: "Community Policies",
|
||||
items: [
|
||||
{
|
||||
label: "Code of Conduct",
|
||||
link: "/community/coc"
|
||||
},
|
||||
{
|
||||
label: "Community Guidelines",
|
||||
link: "/community/guide"
|
||||
},
|
||||
{
|
||||
label: "Appeal a Sanction",
|
||||
link: "/community/appeal"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: "Development Documentation",
|
||||
items: [
|
||||
{
|
||||
label: "Contributing Guide",
|
||||
link: "/dev/contributing"
|
||||
},
|
||||
{
|
||||
label: "Contributor Covenant",
|
||||
link: "/dev/covenant"
|
||||
},
|
||||
{
|
||||
label: "Style Guide",
|
||||
link: "/dev/style"
|
||||
},
|
||||
{
|
||||
label: "Issue/PR Labels",
|
||||
link: "/dev/labels"
|
||||
},
|
||||
{
|
||||
label: "Development Environment",
|
||||
link: "/dev/environment"
|
||||
},
|
||||
{
|
||||
label: "Server Setup",
|
||||
link: "/dev/servers"
|
||||
},
|
||||
{
|
||||
label: "VTubing Setup",
|
||||
link: "/dev/vtubing"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
label: "Project Documentation",
|
||||
items: [
|
||||
{
|
||||
label: "ESLint Config",
|
||||
link: "/projects/eslint-config",
|
||||
badge: { text: "v5.1.0", variant: "tip"}
|
||||
},
|
||||
{
|
||||
label: "Task Bot",
|
||||
link: "/projects/task-bot",
|
||||
badge: { text: "v1.0.0", variant: "tip"}
|
||||
},
|
||||
{
|
||||
label: "Translation Bot",
|
||||
link: "/projects/translation-bot",
|
||||
badge: { text: "v1.0.0", variant: "tip"}
|
||||
},
|
||||
{
|
||||
label: "NaomiAI",
|
||||
link: "/projects/naomiai",
|
||||
badge: { text: "v1.0.0", variant: "tip"}
|
||||
},
|
||||
{
|
||||
label: "AltGenerator",
|
||||
link: "/projects/alt-gen",
|
||||
badge: { text: "v1.0.0", variant: "tip"}
|
||||
}
|
||||
].sort((a, b) => a.label.localeCompare(b.label))
|
||||
},
|
||||
{
|
||||
label: "Staff Guidelines",
|
||||
items: [
|
||||
{
|
||||
label: "Staff Handbook",
|
||||
link: "/staff/handbook"
|
||||
},
|
||||
{
|
||||
label: "Join our Team",
|
||||
link: "/staff/apply"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
@ -1,6 +0,0 @@
|
||||
import { defineCollection } from 'astro:content';
|
||||
import { docsSchema } from '@astrojs/starlight/schema';
|
||||
|
||||
export const collections = {
|
||||
docs: defineCollection({ schema: docsSchema() }),
|
||||
};
|
||||
@ -1,512 +0,0 @@
|
||||
---
|
||||
title: Contact Policy
|
||||
---
|
||||
|
||||
## 1. Support and Communication Channels
|
||||
|
||||
### 1.1 Public Support Channels
|
||||
|
||||
:::tip
|
||||
We have a ticket system within our Discord server which allows for private communication with the staff team.
|
||||
This is considered a public support platform and is not billed!
|
||||
:::
|
||||
|
||||
We offer FREE support through several PUBLIC channels, including:
|
||||
|
||||
- Community Forums
|
||||
- Public GitHub Issues
|
||||
- Open Discord Servers
|
||||
- Social Media Platforms
|
||||
|
||||
These channels are ideal for:
|
||||
|
||||
- General inquiries about our projects
|
||||
- Bug reports and feature requests
|
||||
- Community discussions and knowledge sharing
|
||||
- Open-source collaboration opportunities
|
||||
|
||||
### 1.2 Private Support Options
|
||||
|
||||
While we encourage the use of public channels, we understand that some situations may require private communication. Please note:
|
||||
|
||||
- Private support is a premium service and may be subject to fees.
|
||||
- We reserve the right to invoice you for private support services.
|
||||
- Billing is based on the anticipated workload for your query.
|
||||
- Responses to private queries will be provided only after invoice payment is confirmed.
|
||||
|
||||
To request private support, please contact us through `support@nhcarrigan.com`.
|
||||
|
||||
### 1.3 Engagement Opportunities
|
||||
|
||||
Our platforms offer various ways to engage with our projects and community:
|
||||
|
||||
- Request support for technical issues
|
||||
- Express interest in contributing to our open-source projects
|
||||
- Seek mentorship in software development
|
||||
- Participate in casual discussions with our team and community members
|
||||
|
||||
### 1.4 Platform Directory
|
||||
|
||||
Below, you'll find a comprehensive list of our official communication platforms. Each platform serves specific purposes and caters to different types of interactions. Please choose the most appropriate channel for your needs to ensure the fastest and most effective response.
|
||||
|
||||
## 2. Account Verification
|
||||
|
||||
### 2.1 List of Verified Accounts
|
||||
|
||||
We maintain a comprehensive list of all our verified accounts across different platforms. This list is regularly updated to reflect any changes or additions to our official online presence.
|
||||
|
||||
- View our verified accounts: https://cdn.nhcarrigan.com/socials.txt
|
||||
|
||||
### 2.2 GPG Key for Verification
|
||||
|
||||
To ensure the integrity of our verified accounts list, we use GPG (GNU Privacy Guard) encryption. You can download our public GPG key to verify the authenticity of the list.
|
||||
|
||||
- Download our GPG key: https://cdn.nhcarrigan.com/key.pgp
|
||||
|
||||
### 2.3 Verification Process
|
||||
|
||||
Follow these steps to verify the integrity of our verified accounts list:
|
||||
|
||||
- Download both the verified accounts list and our GPG key from the links provided above.
|
||||
- Open a terminal or command prompt on your system.
|
||||
- Navigate to the directory where you saved the files.
|
||||
- Run the following command:
|
||||
|
||||
```
|
||||
gpg -f /path/to/key --verify /path/to/socials
|
||||
```
|
||||
|
||||
Replace `/path/to/key` with the path to the downloaded GPG key file, and `/path/to/socials` with the path to the downloaded verified accounts list.
|
||||
|
||||
If the verification is successful, you'll see a message confirming the signature is valid.
|
||||
|
||||
### 2.4 Importance of Verification
|
||||
|
||||
Verifying our accounts helps you:
|
||||
|
||||
- Avoid impersonation attempts
|
||||
- Ensure you're interacting with official channels
|
||||
- Protect yourself from potential scams or misinformation
|
||||
|
||||
### 2.5 Reporting Suspicious Accounts
|
||||
|
||||
If you encounter an account claiming to represent us but not listed in our verified accounts:
|
||||
|
||||
- Do not engage with or share sensitive information with the account
|
||||
- Report the suspicious account to us immediately through one of our verified channels
|
||||
- If possible, report the account to the platform it's on for impersonation
|
||||
|
||||
### 2.6 Staying Updated
|
||||
|
||||
We recommend checking our verified accounts list periodically, as we may add new official accounts or remove outdated ones. Always use the verification process to ensure you have the most current and authentic list.
|
||||
|
||||
## 3. Real-Time Communication Platforms
|
||||
|
||||
### 3.1 Discord Server
|
||||
|
||||
Our Discord server is the primary and most active platform for real-time communication.
|
||||
|
||||
- Join Link: https://chat.naomi.lgbt
|
||||
- Features:
|
||||
- Fastest response times
|
||||
- Multiple topic-specific channels
|
||||
- Voice chat capabilities
|
||||
- Integration with our projects and bots
|
||||
- Best for: Quick support, community discussions, and live collaboration
|
||||
|
||||
### 3.2 Matrix Space
|
||||
|
||||
For those who prefer an open-source alternative to Discord, we maintain a Matrix space.
|
||||
|
||||
- Join Link: https://matrix.to/#/#naomis:matrix.org
|
||||
- Features:
|
||||
- Decentralized and open-source
|
||||
- End-to-end encryption for private messages
|
||||
- Cross-platform compatibility
|
||||
- Best for: Privacy-conscious users and those who prefer open protocols
|
||||
|
||||
### 3.3 IRC Channels
|
||||
|
||||
For users who prefer traditional IRC, we maintain channels on LiberaChat.
|
||||
|
||||
- Network: LiberaChat
|
||||
- Channels:
|
||||
- #nhcarrigan - Main support and discussion channel
|
||||
- #nhcarrigan-chat - Casual conversation and community chat
|
||||
- Connection Guide: LiberaChat Connection Guide
|
||||
- Features:
|
||||
- Lightweight and accessible from various clients
|
||||
- Suitable for users with limited bandwidth
|
||||
- Familiar interface for long-time internet users
|
||||
- Best for: Users comfortable with traditional IRC interfaces and those seeking a minimal, text-based chat experience
|
||||
|
||||
### 3.4 Platform Choice Guidelines
|
||||
|
||||
- Discord: Recommended for most users, especially those seeking quick responses or community interaction.
|
||||
- Matrix: Ideal for users prioritizing privacy and open-source solutions.
|
||||
- IRC: Best for those who prefer a classic, lightweight chat experience or are using older hardware.
|
||||
|
||||
### 3.5 Etiquette and Best Practices
|
||||
|
||||
- Please be respectful and follow the community guidelines on all platforms.
|
||||
- Use appropriate channels or rooms for your queries to ensure the fastest response.
|
||||
- Before asking a question, check if it has been answered in pinned messages or FAQs.
|
||||
- When seeking help, provide as much relevant information as possible.
|
||||
|
||||
## 4. Announcements and Updates
|
||||
|
||||
### 4.1 Reddit Board
|
||||
|
||||
Our Reddit board serves as the primary hub for official announcements and updates.
|
||||
|
||||
- URL: https://www.reddit.com/r/nhcarrigan/
|
||||
- Nature: This board is read-only.
|
||||
- Content:
|
||||
- Project updates and new releases
|
||||
- Important community announcements
|
||||
- Event notifications
|
||||
- Major policy changes
|
||||
- Best for: Comprehensive, detailed announcements and long-form updates
|
||||
|
||||
### 4.2 Social Media Platforms
|
||||
|
||||
For more frequent and concise updates, we cross-post select announcements to our social media accounts.
|
||||
|
||||
#### 4.2.1 Twitter
|
||||
|
||||
- Account: @naomi_lgbt
|
||||
- Content:
|
||||
- Brief announcements and updates
|
||||
- Quick tips and insights
|
||||
- Community engagement
|
||||
|
||||
#### 4.2.2 Mastodon
|
||||
|
||||
- Account: @naomi_lgbt@mastodon.social
|
||||
- Content:
|
||||
- Similar to Twitter
|
||||
- Greater focus on personal activities
|
||||
|
||||
### 4.3 Interacting with Announcements
|
||||
|
||||
- Reddit: The board is read-only. For questions or discussions about announcements, please use our Discord server or other interactive platforms.
|
||||
- Twitter and Mastodon: You can reply to posts or @mention us with questions or comments. We encourage community engagement on these platforms.
|
||||
|
||||
### 4.4 Best Practices for Staying Informed
|
||||
|
||||
- Subscribe to Multiple Channels: Each platform may have slightly different content. Following multiple channels ensures you don't miss any important updates.
|
||||
- Enable Notifications: Consider enabling notifications for critical updates on your preferred platform.
|
||||
- Regular Check-ins: If you prefer not to use notifications, we recommend checking these channels regularly, especially before starting work on or with our projects.
|
||||
- Cross-Reference: Major announcements will typically be posted across all platforms. If you see something important on one channel, you can cross-reference it on others for any additional details.
|
||||
|
||||
### 4.5 Emergency or Critical Updates
|
||||
|
||||
For time-sensitive or critical announcements:
|
||||
|
||||
- We will use all available channels to ensure maximum reach.
|
||||
- Such announcements will be clearly marked as urgent or critical.
|
||||
- We may use additional notification methods (e.g., email for registered users) for extremely critical updates.
|
||||
|
||||
### 4.6 Historical Announcements
|
||||
|
||||
- All announcements on our Reddit board are archived and remain accessible for future reference.
|
||||
- While social media posts may have limited visibility over time, all major announcements will be permanently available on Reddit.
|
||||
|
||||
## 5. Professional Engagement and Portfolio
|
||||
|
||||
### 5.1 LinkedIn Profile
|
||||
|
||||
LinkedIn serves as our primary professional networking platform.
|
||||
|
||||
- Profile URL: https://linkedin.com/in/naomi-lgbt
|
||||
- Purpose:
|
||||
- Professional networking
|
||||
- Career history and accomplishments
|
||||
- Skills endorsements and recommendations
|
||||
- Best for:
|
||||
- Potential employers or clients
|
||||
- Professional collaborators
|
||||
- Industry peers
|
||||
|
||||
#### 5.1.1 Connecting on LinkedIn
|
||||
|
||||
When sending a connection request, please include a brief message explaining your interest. We typically respond to LinkedIn messages within 2-3 business days.
|
||||
|
||||
### 5.2 Peerlist Profile
|
||||
|
||||
As an alternative to LinkedIn, we maintain a presence on Peerlist, a platform focused on tech professionals.
|
||||
|
||||
- Profile URL: https://peerlist.io/naomi_lgbt
|
||||
- Purpose:
|
||||
- Showcase technical projects and contributions
|
||||
- Highlight specific skills and technologies
|
||||
- Connect with other tech professionals
|
||||
- Best for:
|
||||
- Tech-focused recruiters and companies
|
||||
- Fellow developers and engineers
|
||||
- Open-source collaborators
|
||||
|
||||
#### 5.2.1 Engaging on Peerlist
|
||||
|
||||
Feel free to explore our projects and contributions on Peerlist. You can leave comments or questions on specific items in our portfolio.
|
||||
|
||||
### 5.3 Professional Inquiries
|
||||
|
||||
When reaching out for professional reasons, please consider the following:
|
||||
|
||||
- Clear Purpose: State the reason for your contact (e.g., job opportunity, collaboration, consultation).
|
||||
- Relevant Background: Provide brief context about yourself or your company.
|
||||
- Specific Questions: If you have particular queries, include them in your initial message.
|
||||
|
||||
### 5.4 Services
|
||||
|
||||
For details about our services and past work, visit our portfolio: https://nhcarrigan.com
|
||||
|
||||
### 5.5 Speaking Engagements and Events
|
||||
|
||||
If you're interested in having us speak at your event or contribute to your publication:
|
||||
|
||||
- Check our LinkedIn or Peerlist profiles for recent talks or articles.
|
||||
- Reach out with specific details about your event or publication.
|
||||
- Provide information about the audience, topic, and any other relevant details.
|
||||
|
||||
### 5.6 Keeping Professional Connections Updated
|
||||
|
||||
We regularly update our professional profiles with new projects, skills, and achievements. Follow us on these platforms to stay informed about our professional journey and potential opportunities for collaboration.
|
||||
|
||||
## 6. One-on-One Sessions
|
||||
|
||||
We offer personalized, one-on-one sessions to cater to various needs, from casual conversations to in-depth consultations. Book your session through our Topmate profile.
|
||||
|
||||
### 6.1 Coffee Chat
|
||||
|
||||
A casual, informal conversation to connect and share ideas.
|
||||
|
||||
- Duration: 15 minutes
|
||||
- Purpose:
|
||||
- Get to know Naomi
|
||||
- Discuss general topics in tech
|
||||
- Share experiences and insights
|
||||
- Best for:
|
||||
- Students looking for career advice
|
||||
- Professionals seeking to expand their network
|
||||
- Anyone interested in a friendly chat about tech and open source
|
||||
|
||||
### 6.2 Consulting Session
|
||||
|
||||
A focused, one-on-one session to discuss potential new projects and align our services with your needs.
|
||||
|
||||
- Duration: 30 minutes
|
||||
- Purpose:
|
||||
- Explore your project requirements in detail
|
||||
- Discuss how our services can meet your needs
|
||||
- Provide estimated quotes for the proposed work
|
||||
- Best for:
|
||||
- Developers stuck on a particular problem
|
||||
- Project managers seeking technical guidance
|
||||
- Startups needing expert input on their tech stack
|
||||
|
||||
### 6.3 Mentorship Session
|
||||
|
||||
An in-depth, personalized session focused on long-term professional growth and skill development.
|
||||
|
||||
- Duration: 1 hour
|
||||
- Purpose:
|
||||
- Provide career guidance and development strategies
|
||||
- Offer personalized learning plans and resources
|
||||
- Review and provide feedback on code or projects
|
||||
- Best for:
|
||||
- Early-career developers seeking guidance
|
||||
- Professionals looking to transition into tech
|
||||
- Anyone seeking structured, long-term professional development
|
||||
|
||||
### 6.4 How to Book a Session:
|
||||
|
||||
- Visit one of:
|
||||
- Our Topmate profile: https://topmate.io/nhcarrigan
|
||||
- Our Fiverr profile: https://www.fiverr.com/nhcarrigan
|
||||
- Select the type of session you need (Coffee Chat, Consulting, or Mentorship)
|
||||
- Select an available time slot
|
||||
- Complete the booking process and payment
|
||||
|
||||
### 6.5 Preparing for Your Session:
|
||||
|
||||
- Coffee Chat: Come with topics you'd like to discuss or questions about the industry
|
||||
- Consulting: Prepare a clear description of your problem or project, and any relevant code or documentation
|
||||
- Mentorship: Outline your career goals and areas where you'd like to improve
|
||||
|
||||
### 6.6 Additional Information:
|
||||
|
||||
- All sessions are conducted virtually via a video call in our Discord server.
|
||||
- Payment is required at the time of booking
|
||||
- Rescheduling is possible with at least 24 hours notice
|
||||
|
||||
For any questions about these sessions or to discuss a different type of engagement, please reach out through our preferred contact methods listed in previous sections.
|
||||
|
||||
## 7. Email Communication
|
||||
|
||||
:::caution
|
||||
Email communication is considered a paid service and will be invoiced at $25 per email we receive.
|
||||
:::
|
||||
|
||||
We offer several email addresses for specific types of inquiries. Please use the appropriate email address to ensure your message reaches the right team and receives the most efficient response.
|
||||
|
||||
### 7.1 General Inquiries
|
||||
|
||||
- Email: contact@nhcarrigan.com
|
||||
- Use for:
|
||||
- General questions about our services or projects
|
||||
- Partnership or collaboration proposals
|
||||
- Media or press inquiries
|
||||
- Any queries that don't fit other categories
|
||||
|
||||
### 7.2 Billing and Financial Matters
|
||||
|
||||
- Email: billing@nhcarrigan.com
|
||||
- Use for:
|
||||
- Questions about payments or invoices
|
||||
- Inquiries about outstanding balances
|
||||
- Refund requests
|
||||
- Updating billing information
|
||||
|
||||
### 7.3 Technical Support
|
||||
|
||||
- Email: support@nhcarrigan.com
|
||||
- Use for:
|
||||
- Assistance with using our software or services
|
||||
- Reporting bugs or technical issues
|
||||
- Documentation clarifications
|
||||
|
||||
### 7.4 Privacy Concerns
|
||||
|
||||
- Email: privacy@nhcarrigan.com
|
||||
- Use for:
|
||||
- Questions about our privacy policy
|
||||
- Requests for data access or deletion
|
||||
- Reporting potential privacy breaches
|
||||
- Opting out of data collection (where applicable)
|
||||
|
||||
### 7.5 Security Matters
|
||||
|
||||
- Email: security@nhcarrigan.com
|
||||
- Use for:
|
||||
- Reporting security vulnerabilities
|
||||
- Questions about our security practices
|
||||
- Concerns about potential security breaches
|
||||
|
||||
### 7.6 Legal Inquiries
|
||||
|
||||
- Email: legal@nhcarrigan.com
|
||||
- Use for:
|
||||
- Legal questions or concerns
|
||||
- Copyright or trademark issues
|
||||
- Requests for legal documentation
|
||||
- Formal notices or communications
|
||||
|
||||
### 7.7 Feedback and Suggestions
|
||||
|
||||
- Email: feedback@nhcarrigan.com
|
||||
- Use for:
|
||||
- Providing feedback on our work or projects
|
||||
- Suggesting improvements or new features
|
||||
- Sharing your experience with our services
|
||||
- Offering ideas for future developments
|
||||
|
||||
### 7.8 Email Communication Guidelines
|
||||
|
||||
- Subject Line: Please use a clear, concise subject line that summarizes your inquiry.
|
||||
- Content: Provide all relevant details in your initial email to expedite the response process.
|
||||
- Attachments: If sending attachments, please mention them in the email body and ensure they are in common file formats.
|
||||
- Response Time: We aim to respond to all emails within 2 business days. Complex inquiries may require additional time.
|
||||
- Follow-ups: If you haven't received a response after 3 business days, feel free to send a polite follow-up.
|
||||
|
||||
### 7.9 Email Privacy and Security
|
||||
|
||||
All email communications are treated as confidential.
|
||||
|
||||
We do not share your email address or the content of your messages with third parties unless:
|
||||
- Required by law; OR
|
||||
- As part of a public warning related to a violation of our Code of Conduct
|
||||
|
||||
### 7.10 Spam and Unsolicited Emails
|
||||
|
||||
We have a strict no-spam policy. If you receive any unsolicited emails claiming to be from us, please report them to security@nhcarrigan.com.
|
||||
|
||||
By using the appropriate email address for your inquiry, you help us provide you with the most efficient and accurate response possible. If you're unsure which email to use, feel free to send your inquiry to contact@nhcarrigan.com, and we'll direct it to the appropriate team.
|
||||
|
||||
### 7.11 Acceptable Use and Consequences
|
||||
|
||||
We are committed to maintaining a respectful and productive communication environment. To ensure this:
|
||||
|
||||
- All email communications should be professional and respectful.
|
||||
- Harassment, threats, or abusive language will not be tolerated.
|
||||
- Spam or excessive unsolicited emails are prohibited.
|
||||
- Attempting to use our email system for malicious purposes (e.g., phishing, spreading malware) is strictly forbidden.
|
||||
|
||||
:::danger[Attention!]
|
||||
Abuse of our email system or violation of these guidelines will result in your email address being blocked from sending communications to any of our addresses. This block may be temporary or permanent, depending on the severity and frequency of the abuse.
|
||||
:::
|
||||
|
||||
If you believe your email has been blocked in error, please contact us through an alternative method listed in this document to request a review of the situation.
|
||||
|
||||
We reserve the right to report serious abuses to relevant authorities if necessary.
|
||||
|
||||
By communicating with us via email, you agree to adhere to these guidelines and understand the consequences of misuse.
|
||||
|
||||
## 8. Direct Messages
|
||||
|
||||
:::caution
|
||||
Direct messages (DMs) are considered a paid service and will be invoiced at $25 per message we receive.
|
||||
:::
|
||||
|
||||
### 8.1 Direct Message Policy
|
||||
|
||||
We offer direct messaging as a premium, personalized communication channel. However, to manage our time effectively and ensure the highest quality of service, we have implemented the following policy for direct messages:
|
||||
|
||||
- Each direct message received will be invoiced at $25.
|
||||
- This applies to all platforms where direct messaging is available, including but not limited to:
|
||||
- Discord
|
||||
- Twitter
|
||||
- LinkedIn
|
||||
- Any other social media or communication platforms
|
||||
|
||||
### 8.2 Purpose and Use
|
||||
|
||||
Direct messages should be used for:
|
||||
- Urgent matters that cannot be addressed through public channels
|
||||
- Sensitive information that shouldn't be shared publicly
|
||||
- Personalized support or consultation requests
|
||||
|
||||
### 8.3 Invoicing and Payment
|
||||
|
||||
- An invoice will be generated for each direct message received.
|
||||
- Payment is required before a response will be provided.
|
||||
- Invoices will be sent to you via the direct message channel on the platform where the direct message was received.
|
||||
|
||||
### 8.4 Response Time
|
||||
|
||||
- Once payment is received, we aim to respond to direct messages within 1-2 business days.
|
||||
- Complex inquiries may require additional time, which will be communicated to you.
|
||||
|
||||
### 8.5 Refund Policy
|
||||
|
||||
- Due to the immediate nature of the service, refunds for direct messages are not typically offered.
|
||||
- In exceptional circumstances, refund requests will be considered on a case-by-case basis.
|
||||
|
||||
### 8.6 Appropriate Use
|
||||
|
||||
- Direct messages should be used responsibly and for legitimate purposes only.
|
||||
- Abusive, harassing, or spam messages will not be tolerated and may result in blocking or reporting to the platform.
|
||||
|
||||
### 8.7 Alternatives
|
||||
|
||||
We encourage users to consider the following alternatives before sending a direct message:
|
||||
- Use our public support channels for general inquiries (see Section 1.1)
|
||||
- Check our FAQ or documentation for commonly asked questions
|
||||
- Post in our community forums for non-urgent matters
|
||||
|
||||
### 8.8 Consent and Acknowledgment
|
||||
|
||||
By sending a direct message, you acknowledge that you have read and agreed to this policy, including the fee structure and invoicing process.
|
||||
|
||||
Remember, while we value direct communication, we encourage the use of our public channels whenever possible to foster community engagement and shared learning.
|
||||
@ -1,66 +0,0 @@
|
||||
---
|
||||
title: Support Our Work 💜
|
||||
---
|
||||
|
||||
We are passionate about creating and maintaining free-to-use projects and providing guidance in various programming communities. Your support helps us continue this mission and expand our efforts.
|
||||
|
||||
## 1. Why Support Us?
|
||||
|
||||
- **Free Resources**: We offer numerous projects that are free for everyone to use and learn from.
|
||||
- **Community Guidance**: We actively participate in programming communities, offering help and mentorship.
|
||||
- **Open Source Contributions**: Your support enables us to dedicate more time to open source development.
|
||||
- **Continuous Improvement**: Donations help us improve existing projects and create new ones.
|
||||
|
||||
## 2. How Your Support Helps
|
||||
|
||||
- Covers hosting and infrastructure costs
|
||||
- Allows us to dedicate more time to project development and community support
|
||||
- Enables us to invest in better tools and resources
|
||||
- Supports our ongoing education and skill development
|
||||
|
||||
## 3. Ways to Support
|
||||
|
||||
We offer several platforms for monthly donations, allowing you to choose the one that works best for you:
|
||||
|
||||
### 3.1 Discord
|
||||
- Join our community and support us directly
|
||||
- Link: [https://chat.naomi.lgbt](https://chat.naomi.lgbt)
|
||||
|
||||
### 3.2 Ko-Fi
|
||||
- Perfect for one-time or recurring donations
|
||||
- Link: [https://ko-fi.com/nhcarrigan](https://ko-fi.com/nhcarrigan)
|
||||
|
||||
### 3.3 Patreon
|
||||
- For those who prefer tier-based support
|
||||
- Link: [https://www.patreon.com/nhcarrigan](https://www.patreon.com/nhcarrigan)
|
||||
|
||||
### 3.4 GitHub Sponsors
|
||||
- Support us directly on the platform where we contribute
|
||||
- Link: [https://github.com/sponsors/naomi-lgbt](https://github.com/sponsors/naomi-lgbt)
|
||||
|
||||
### 3.5 Topmate
|
||||
- One-off donations through our meeting booking platform
|
||||
- Link: [https://topmate.io/nhcarrigan/1294986](https://topmate.io/nhcarrigan/1294986)
|
||||
|
||||
### 3.6 Gumroad
|
||||
- Subscription access directly through a booking platform
|
||||
- Link: [https://nhcarrigan.gumroad.com/l/donate](https://nhcarrigan.gumroad.com/l/donate)
|
||||
|
||||
## 4. Other Ways to Help
|
||||
|
||||
- **Spread the Word**: Share our projects and resources with others who might benefit.
|
||||
- **Contribute**: If you have skills to offer, consider contributing to our open source projects.
|
||||
- **Provide Feedback**: Your input helps us improve and refine our work.
|
||||
|
||||
## 5. Thank You!
|
||||
|
||||
Every contribution, no matter the size, makes a significant impact. We deeply appreciate your support and are committed to using it to benefit the wider programming community.
|
||||
|
||||
For any questions about donations or to discuss other support options, please contact us at donors@nhcarrigan.com.
|
||||
|
||||
## 6. Perks
|
||||
|
||||
Once you have donated, make sure to join our [Discord community](https://chat.nhcarrigan.com)! In there, you can open a ticket where we'll confirm you are the user who made the donation. Upon confirmation, you'll receive:
|
||||
|
||||
- A permanent special role recognising your support
|
||||
- Access to our [private development notes](https://notes.nhcarrigan.com), which gives you a sneak peek into our roadmap and future plans
|
||||
@ -1,67 +0,0 @@
|
||||
---
|
||||
title: Hire us!
|
||||
---
|
||||
|
||||
We're excited about the opportunity to collaborate with you and contribute to the success of your goals. Our team brings a wealth of experience and a passion for delivering high-quality solutions tailored to your specific needs.
|
||||
|
||||
|
||||
|
||||
## 1. Our Services
|
||||
|
||||
- **Discord Bot Development**: Custom bots to enhance your server's functionality
|
||||
- **Web Development**: From simple websites to complex web applications
|
||||
- **Community Management**: Strategies to grow and maintain thriving online communities
|
||||
- **Technical Consulting**: Expert advice on your tech-related projects and decisions
|
||||
|
||||
## 2. Engagement Options
|
||||
|
||||
We offer flexible ways to work together, catering to projects of all sizes and complexities:
|
||||
|
||||
### 2.1. Quick Sync (15 minutes)
|
||||
|
||||
For those with a well-defined product idea or seeking a quick review of their community plan, book a quick sync.
|
||||
|
||||
- Ideal for: Initial project discussions, quick advice, or community plan reviews
|
||||
- Duration: 15 minutes
|
||||
- Outcome: Rapid insights and direction for your project
|
||||
|
||||
Book via [Topmate](https://topmate.io/nhcarrigan/913917), [Gumroad](https://nhcarrigan.gumroad.com/l/chat), [Fiverr](https://www.fiverr.com/nhcarrigan/schedule-a-30-minute-one-on-one-with-you-to-discuss-your-consulting-needs), [Patreon](https://www.patreon.com/nhcarrigan/shop/quick-sync-622924), [Ko-fi](https://ko-fi.com/s/8ff29882b1), or directly through [Discord](https://discord.com/channels/1146133490933436476/shop/1303095252995014767).
|
||||
|
||||
### 2.2. In-Depth Consultation (30 minutes)
|
||||
|
||||
For more complex, long-term, or in-depth projects, we recommend booking an in-depth consultation.
|
||||
|
||||
- Ideal for: Detailed project planning, technical strategy discussions, or exploring long-term collaborations
|
||||
- Duration: 30 minutes
|
||||
- Outcome: Comprehensive project assessment and tailored recommendations
|
||||
|
||||
Book via [Topmate](https://topmate.io/nhcarrigan/913920), [Gumroad](https://nhcarrigan.gumroad.com/l/consulting), [Fiverr](https://www.fiverr.com/nhcarrigan/schedule-a-30-minute-one-on-one-with-you-to-discuss-your-consulting-needs), [Patreon](https://www.patreon.com/nhcarrigan/shop/consulting-session-622928), [Ko-fi](https://ko-fi.com/s/542dedd6e4), or directly through [Discord](https://discord.com/channels/1146133490933436476/shop/1235463041613824040).
|
||||
|
||||
### 2.3. Mentorship Session (60 minutes)
|
||||
|
||||
:::tip
|
||||
Individual mentorship sessions are made available for those who might need one-off guidance, but the best value is actually through our [Mentorship programme](/about/mentorship).
|
||||
:::
|
||||
|
||||
For those seeking personalized guidance and skill development, we offer a full mentorship session.
|
||||
|
||||
- Ideal for: Individuals looking to enhance their skills in development, community management, or related areas
|
||||
- Duration: 60 minutes
|
||||
- Outcome: Personalized learning path, hands-on projects, and ongoing support
|
||||
|
||||
Book via [Topmate](https://topmate.io/nhcarrigan/913921), [Gumroad](https://nhcarrigan.gumroad.com/l/mentorship), [Fiverr](https://www.fiverr.com/nhcarrigan/schedule-a-30-minute-one-on-one-with-you-to-discuss-your-consulting-needs), [Patreon](https://www.patreon.com/nhcarrigan/shop/mentorship-session-622930), [Ko-fi](https://ko-fi.com/s/4c6c4d3e0d), or directly through [Discord](https://discord.com/channels/1146133490933436476/shop/1303095415935209583)
|
||||
|
||||
## 3. Why Choose Us?
|
||||
|
||||
- **Expertise**: Years of experience in development and community management
|
||||
- **Flexibility**: Multiple engagement options to suit your needs and preferences
|
||||
- **Personalized Approach**: Tailored solutions for your unique challenges
|
||||
- **Commitment to Quality**: Delivering high-value insights and solutions in every interaction
|
||||
|
||||
## 4. Ready to Get Started?
|
||||
|
||||
1. For a quick discussion: [Book a 15-minute sync](https://topmate.io/nhcarrigan/913917)
|
||||
2. For in-depth consultations: [Schedule a 30-minute slot](https://topmate.io/nhcarrigan/913920)
|
||||
3. For ongoing mentorship: [Explore our mentorship package](https://topmate.io/nhcarrigan/913932)
|
||||
|
||||
Not sure which option is right for you? Feel free to contact us with any questions. We're excited to explore how we can help bring your ideas to life and contribute to your success!
|
||||
@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Mentorship Programme Terms and Conditions
|
||||
---
|
||||
|
||||
Here at NHCarrigan, we are dedicated to lowering the barriers of entry into tech and helping underprivileged/under-represented classes reach their goals. As part of this mission, we offer a mentorship programme ("Programme").
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
These Terms and Conditions (“Terms”) outline the Programme provided by NHCarrigan (“Company”) and apply to all participants enrolled in the Programme. By enrolling, you (the "Mentee") agree to abide by these Terms. The Programme cost is $200 USD per month.
|
||||
|
||||
### 1.1. Enrolment
|
||||
|
||||
You may enrol in the Programme via one of the following platforms:
|
||||
|
||||
- [Gumroad](https://nhcarrigan.gumroad.com/l/programme)
|
||||
- [Topmate](https://topmate.io/nhcarrigan/958795)
|
||||
- [Fiverr](https://www.fiverr.com/nhcarrigan/grant-you-access-to-our-mentorship-programme)
|
||||
- [Discord](https://chat.nhcarrigan.com)
|
||||
- [Patreon](https://patreon.com/nhcarrigan)
|
||||
- [Ko-fi](https://ko-fi.com/nhcarrigan)
|
||||
|
||||
## 2. Programme Services
|
||||
|
||||
Upon successful enrolment, the Mentee receives the following benefits:
|
||||
|
||||
### 2.1 Monthly 1:1 Sessions
|
||||
|
||||
Participants are entitled to one monthly 1:1 session with a mentor to discuss progress, set goals, and address any questions. Scheduling of these sessions is subject to mutual agreement and the mentor’s availability.
|
||||
|
||||
### 2.2 Private Discord Channel
|
||||
|
||||
Participants will have access to a private Discord channel exclusively for Mentees. This channel offers priority response times from the NHCarrigan team. All participants must adhere to the Discord Code of Conduct found [here](https://docs.nhcarrigan.com).
|
||||
|
||||
### 2.3 Group Meetings
|
||||
|
||||
If the Programme enrols five (5) or more participants within a given month, all Mentees will be invited to a monthly group meeting. This meeting will provide opportunities for group discussions, shared experiences, and networking.
|
||||
|
||||
### 2.4 Maintainer-Level Access to Open Source Projects
|
||||
|
||||
Participants will gain maintainer-level access to NHCarrigan’s open-source projects for hands-on work experience. This access is a privilege and requires adherence to project guidelines, which can be reviewed [here](https://docs.nhcarrigan.com).
|
||||
|
||||
### 2.5 Internship and Resume Building
|
||||
|
||||
Participants will have the opportunity to build their resumes through an internship with NHCarrigan. This includes eligibility for project contributions and collaboration with the NHCarrigan team.
|
||||
|
||||
### 2.6 Ongoing Support and Resources
|
||||
|
||||
Mentees will receive continuous resume reviews, personalized learning roadmaps, and dedicated guidance for the duration of their membership. Additional resources and Programme updates will be provided as part of this lifetime membership support.
|
||||
|
||||
## 3. Payment Terms
|
||||
|
||||
The Programme fee of $200 USD is due at the start of each month to retain membership. Failure to make payments may result in suspension or termination of services.
|
||||
|
||||
## 4. Code of Conduct
|
||||
|
||||
Participants agree to uphold the Company’s Code of Conduct and other policies, as outlined in the [NHCarrigan Documentation](https://docs.nhcarrigan.com/commnuity/coc.md).
|
||||
|
||||
## 5. Programme Modifications
|
||||
|
||||
NHCarrigan reserves the right to modify Programme features, benefits, and terms at any time. Notification of such changes will be provided to participants with as much advance notice as possible.
|
||||
|
||||
## 6. Termination and Cancellation
|
||||
|
||||
Participants may cancel their membership at any time, effective at the end of the current billing cycle. Refunds will not be issued for partial months. NHCarrigan reserves the right to terminate membership if a participant violates any of these Terms.
|
||||
|
||||
## 7. Contact Information
|
||||
|
||||
For questions or further information, please contact the NHCarrigan team through the official support channels listed in the [documentation](https://docs.nhcarrigan.com/about/contact).
|
||||
@ -1,71 +0,0 @@
|
||||
---
|
||||
title: Mission Statement
|
||||
---
|
||||
|
||||
This Mission Statement ("Statement") articulates the core values and guiding principles of [Company Name] in its efforts to build inclusive, ethical, and sustainable technology solutions.
|
||||
|
||||
## 1. Core Values
|
||||
|
||||
### 1.1. Commitment to Inclusivity
|
||||
|
||||
The Company shall actively work to dismantle barriers and promote diversity in all areas of its operations. We seek to create spaces where all individuals, particularly from marginalized communities, feel supported and valued.
|
||||
|
||||
### 1.2. Sustainability as a Priority
|
||||
|
||||
Environmental sustainability is integral to the Company's mission. We shall consistently minimize our carbon footprint, use eco-friendly technologies, and ensure that every project aligns with our environmental goals.
|
||||
|
||||
### 1.3. Ethical Responsibility
|
||||
|
||||
The Company adheres to a strict ethical code that guides our technological developments. This includes ensuring that our technologies respect user privacy, do no harm, and contribute positively to society.
|
||||
|
||||
### 1.4. Transparency and Integrity
|
||||
|
||||
We are dedicated to maintaining transparency with our stakeholders, whether clients, users, or community members. Clear communication and honesty are at the forefront of our interactions and decision-making.
|
||||
|
||||
### 1.5. Community-Driven Innovation
|
||||
|
||||
Our projects are community-centric, encouraging collaboration and input from diverse voices. We believe in technology as a tool to uplift, empower, and serve communities through innovative solutions that address real-world challenges.
|
||||
|
||||
### 1.6. Breaking Down Barriers in Tech
|
||||
|
||||
The Company is committed to tearing down the systemic and social barriers that exist in the tech industry. We actively work to make the field more accessible to individuals from all backgrounds, particularly those who have historically been excluded.
|
||||
|
||||
### 1.7. Challenging Toxic Behaviors
|
||||
|
||||
We recognize that toxic behaviors and exclusionary practices harm communities. The Company shall take a proactive stance in challenging these behaviors within our industry and within the tech communities we interact with, fostering spaces where collaboration, respect, and growth thrive.
|
||||
|
||||
### 1.8. Mentorship and Support for New Developers
|
||||
|
||||
The Company is dedicated to providing mentorship and support to new developers, particularly those from underrepresented groups. Through guided mentorship, educational resources, and hands-on support, we help individuals break into the industry, equipping them with the skills and confidence to succeed.
|
||||
|
||||
## 2. Strategic Goals
|
||||
|
||||
### 2.1. Elevating Marginalized Voices
|
||||
|
||||
The Company is committed to using its platform to elevate the voices and contributions of individuals from underrepresented communities in tech and beyond.
|
||||
|
||||
### 2.2. Long-Term Sustainability
|
||||
|
||||
All Company projects and partnerships will be evaluated against their long-term environmental impact, with a focus on contributing to a sustainable future.
|
||||
|
||||
### 2.3. Development of Ethical Technologies
|
||||
|
||||
We shall continue to develop and support open-source projects that align with our ethical standards, ensuring they are accessible, secure, and beneficial to society.
|
||||
|
||||
### 2.4. Continuous Growth and Learning
|
||||
|
||||
The Company is committed to evolving its practices and technologies in line with industry advancements, social justice movements, and environmental research.
|
||||
|
||||
### 2.5. Supporting the Next Generation of Developers
|
||||
|
||||
We will continue to build and expand initiatives aimed at mentoring and supporting new developers, ensuring that they have the knowledge and resources to thrive within the industry.
|
||||
|
||||
## 3. Amendments and Updates
|
||||
|
||||
### 3.1. Right to Amend
|
||||
|
||||
The Company reserves the right to amend this Statement as necessary to reflect evolving best practices and organizational goals.
|
||||
|
||||
### 3.2. Notification of Changes
|
||||
|
||||
Significant amendments to this Statement will be communicated through the Company’s official channels.
|
||||
@ -1,85 +0,0 @@
|
||||
---
|
||||
title: Environmental Impact Commitment
|
||||
---
|
||||
|
||||
This Environmental Impact Commitment ("Commitment") outlines the principles and obligations that [Company Name] upholds to minimize its environmental impact and contribute to global sustainability efforts.
|
||||
|
||||
## 1. Definitions
|
||||
|
||||
### 1.1. Environmental Impact
|
||||
|
||||
The measurable effect of the Company’s activities, operations, and technologies on the environment, including but not limited to carbon emissions, energy consumption, and waste production.
|
||||
|
||||
### 1.2. Carbon Footprint
|
||||
|
||||
The total greenhouse gas emissions caused directly or indirectly by the Company’s activities, measured in units of carbon dioxide equivalent.
|
||||
|
||||
### 1.3. Tree-Nation
|
||||
|
||||
A reforestation and carbon offset platform used by the Company to compensate for emissions by planting trees for specific activities, including but not limited to website operations.
|
||||
|
||||
### 1.4. Net-Negative Impact
|
||||
|
||||
A situation where the environmental harm caused by a project or activity exceeds any positive environmental contributions or mitigation efforts.
|
||||
|
||||
## 2. General Principles
|
||||
|
||||
### 2.1. Commitment to Sustainability
|
||||
|
||||
The Company is committed to sustainability at all levels of its operations, actively seeking to minimize its environmental impact and promote long-term environmental health.
|
||||
|
||||
### 2.2. Prioritization of Environmental Impact
|
||||
|
||||
Environmental considerations, including carbon footprint and resource consumption, shall be a key factor in the selection and use of technologies, tools, and resources by the Company.
|
||||
|
||||
### 2.3. Responsible Technology Use
|
||||
|
||||
The Company shall only utilize technologies that align with its environmental goals, ensuring minimal energy consumption and environmental degradation.
|
||||
|
||||
## 3. Carbon Offsetting
|
||||
|
||||
### 3.1. Partnership with Tree-Nation
|
||||
|
||||
The Company shall actively offset its carbon emissions through its partnership with Tree-Nation, which will involve automatically planting trees for specific online activities, such as website operations.
|
||||
|
||||
### 3.2. Scope of Offsetting
|
||||
|
||||
Carbon offsetting efforts shall include, but are not limited to, emissions generated by:
|
||||
|
||||
- Website hosting and maintenance
|
||||
- Digital services provided by the Company
|
||||
- Any other relevant activities contributing to the Company’s carbon footprint
|
||||
|
||||
## 4. Environmental Due Diligence
|
||||
|
||||
### 4.1. Project Assessment
|
||||
|
||||
Before taking on any project, the Company shall conduct an environmental impact assessment to ensure that the project does not introduce a net-negative impact on the environment.
|
||||
|
||||
### 4.2. Refusal of Net-Negative Work
|
||||
|
||||
The Company reserves the right to refuse any project or contract that it determines would result in a net-negative environmental impact.
|
||||
|
||||
### 4.3. Continuous Monitoring
|
||||
|
||||
The Company shall continuously monitor the environmental impact of its ongoing operations and projects, making adjustments as necessary to remain aligned with its sustainability goals.
|
||||
|
||||
## 5. Legal and Ethical Compliance
|
||||
|
||||
### 5.1. Compliance with Environmental Laws
|
||||
|
||||
The Company shall ensure that all its operations, projects, and partnerships comply with applicable environmental laws and regulations.
|
||||
|
||||
### 5.2. Ethical Responsibility
|
||||
|
||||
Beyond legal compliance, the Company acknowledges its ethical responsibility to proactively mitigate environmental harm and contribute to a sustainable future.
|
||||
|
||||
## 6. Amendments and Updates
|
||||
|
||||
### 6.1. Right to Amend
|
||||
|
||||
The Company reserves the right to amend this Commitment as necessary to reflect evolving best practices and environmental standards.
|
||||
|
||||
### 6.2. Notification of Changes
|
||||
|
||||
Significant amendments to this Commitment will be communicated through the Company’s official channels.
|
||||
@ -1,38 +0,0 @@
|
||||
---
|
||||
title: Appealing a Sanction
|
||||
---
|
||||
|
||||
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.
|
||||
|
||||
If you believe you have been unjustly restricted from participating in our community, you may initiate our formal appeal process as outlined below.
|
||||
|
||||
:::caution[Warning!]
|
||||
Submitting multiple appeals for the same sanction will result in our appeals team automatically denying your request.
|
||||
:::
|
||||
|
||||
## 1. Preparing Your Appeal
|
||||
|
||||
Prior to submitting an appeal, please ensure you have the following information ready:
|
||||
|
||||
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.
|
||||
|
||||
Please note that incomplete or inadequately prepared appeals may be summarily dismissed. You can [find your sanction in our logs](https://logs.nhcarrigan.com) to review.
|
||||
|
||||
## 2. Appeal Submission Process
|
||||
|
||||
To submit your appeal, please complete the form available at the following link:
|
||||
|
||||
[Submit a Sanction Appeal](https://nhcarrigan.com/appeal)
|
||||
|
||||
## 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.
|
||||
@ -1,495 +0,0 @@
|
||||
---
|
||||
title: Code of Conduct
|
||||
---
|
||||
|
||||
## 1. Definitions
|
||||
|
||||
### 1.1. "Our Community"
|
||||
|
||||
Encompasses all platforms and spaces, both digital and physical, where members interact under our organization's auspices. This includes, but is not limited to:
|
||||
|
||||
- Our official Discord server
|
||||
- Our code repositories and associated accounts
|
||||
- Our official social media accounts and pages
|
||||
- Any other online forums or platforms we officially endorse or manage
|
||||
- In-person events organized or sponsored by our organization
|
||||
|
||||
### 1.2. "Community Members"
|
||||
|
||||
Refers to all individuals who participate in Our Community, regardless of their role or level of engagement. This includes casual users, regular contributors, and community leaders.
|
||||
|
||||
### 1.3. "Community Leaders"
|
||||
|
||||
Refers to individuals with official responsibilities within Our Community, including but not limited to:
|
||||
|
||||
- Moderators
|
||||
- Developers
|
||||
- Support staff
|
||||
- Administrators
|
||||
- Project managers
|
||||
- Event organizers
|
||||
|
||||
### 1.4. "Code of Conduct" or "CoC"
|
||||
|
||||
Refers to this document in its entirety, including all sections, subsections, and any future amendments.
|
||||
|
||||
### 1.5. "Violating the Code of Conduct"
|
||||
|
||||
Means engaging in behavior that contradicts the guidelines, rules, and principles outlined in this document.
|
||||
|
||||
### 1.6. "Reporting"
|
||||
|
||||
Refers to the act of bringing a potential Code of Conduct violation to the attention of Community Leaders through officially designated channels.
|
||||
|
||||
### 1.7. "Sanctions"
|
||||
|
||||
Refers to the consequences imposed on community members who violate the Code of Conduct, as determined by Community Leaders.
|
||||
|
||||
### 1.8. "Platforms"
|
||||
|
||||
Refers to any digital or physical space where Our Community interacts, as listed in section 1.1.
|
||||
|
||||
## 2. Scope
|
||||
|
||||
### 2.1. Applicability
|
||||
|
||||
This Code of Conduct applies to all interactions within Our Community, including but not limited to:
|
||||
|
||||
- Public channels and forums
|
||||
- Private channels and direct messages
|
||||
- Online and offline community spaces
|
||||
- Community-organized events and meetups
|
||||
- Any form of communication using our official platforms or branding
|
||||
|
||||
### 2.2. Extended Scope
|
||||
|
||||
The Code of Conduct may also apply to interactions outside Our Community when:
|
||||
|
||||
- A Community Member is involved in an incident affecting another Community Member
|
||||
- The incident has a substantial impact on the well-being or participation of Community Members
|
||||
- The behavior significantly affects the reputation or integrity of Our Community
|
||||
|
||||
### 2.3. Temporal Scope
|
||||
|
||||
This Code of Conduct applies to:
|
||||
|
||||
- Current interactions within Our Community
|
||||
- Past behavior of Community Members, including actions prior to joining Our Community
|
||||
- Ongoing patterns of behavior that may have started before joining Our Community
|
||||
|
||||
### 2.4. Reporting
|
||||
|
||||
We encourage reporting of any violations of this Code of Conduct, including:
|
||||
|
||||
- Harassment by Community Members, especially Community Leaders
|
||||
- Incidents that occur outside Our Community spaces
|
||||
- Past incidents, regardless of when they took place
|
||||
|
||||
### 2.5. Commitment to Action
|
||||
|
||||
Community Leaders commit to:
|
||||
|
||||
- Take all good-faith reports seriously
|
||||
- Respect the privacy and security of reporters
|
||||
- Conduct fair and thorough investigations of reported incidents
|
||||
- Take appropriate action based on the findings of investigations
|
||||
|
||||
### 2.6. Exclusion Rights
|
||||
|
||||
Community Leaders reserve the right to exclude individuals from Our Community based on:
|
||||
|
||||
- Violations of this Code of Conduct
|
||||
- Past behavior, including actions outside Our Community spaces
|
||||
- Behavior towards individuals who are not members of Our Community
|
||||
- Any conduct deemed detrimental to the safety, well-being, or positive environment of Our Community
|
||||
|
||||
### 2.7. Scope of Authority
|
||||
|
||||
While this Code of Conduct primarily governs behavior within Our Community, we recognize that actions outside our spaces can significantly impact our environment. Therefore, Community Leaders may consider external behaviors when making decisions about community participation.
|
||||
|
||||
### 2.8. Amendments
|
||||
|
||||
The scope of this Code of Conduct may be amended as necessary to address emerging concerns or changing circumstances within Our Community. Any changes will be clearly communicated to all Community Members.
|
||||
|
||||
## 3. Rules and Prohibited Conduct
|
||||
|
||||
### 3.1. General Conduct
|
||||
|
||||
- No trolling, insulting, or derogatory comments.
|
||||
- No harassment, whether public or private (see section 3.2 for detailed definition).
|
||||
- No incitement of violence towards any individual, including encouraging suicide or self-harm.
|
||||
- No deliberate "outing" of any aspect of a person's identity without their consent, except to protect vulnerable individuals from intentional abuse.
|
||||
- No publication of non-harassing private communication without explicit consent from all parties involved.
|
||||
- No advocating for members to be banned, except in direct messages to or private discussions with community leaders.
|
||||
- No spam or excessive self-promotion.
|
||||
|
||||
### 3.2. Harassment
|
||||
|
||||
Harassment includes, but is not limited to:
|
||||
|
||||
- Deliberate misgendering or use of rejected names
|
||||
- Unwanted physical contact or simulated physical contact without consent
|
||||
- Threats of violence or intimidation
|
||||
- Stalking or following
|
||||
- Unwanted photography or recording, including logging online activity for harassment purposes
|
||||
- Unwelcome sexual attention
|
||||
- Pattern of inappropriate social contact, such as requesting/assuming inappropriate levels of intimacy
|
||||
- Continued one-on-one communication after requests to cease
|
||||
- Targeted and deliberate aggression
|
||||
- Sustained disruption of discussion or community events
|
||||
|
||||
### 3.3. Respect for Identity and Diversity
|
||||
|
||||
- No questioning or challenging someone's stated self-identity or chosen labels.
|
||||
- No unwelcome comments regarding a person's lifestyle choices and practices, including those related to food, health, parenting, relationships, drugs, and employment.
|
||||
- No offensive comments related to gender, gender identity and expression, sexual orientation, disability, mental illness, neurodiversity, physical appearance, body size, age, race, national origin, ethnic origin, nationality, immigration status, language, religion or lack thereof, or other identity markers.
|
||||
- No use or promotion of "reverse"-isms, including "reverse racism," "reverse sexism," and "cisphobia" against marginalized members.
|
||||
- No debating the rights and lived experiences of marginalized people in the community.
|
||||
- No racist, sexist, cissexist, ableist, or otherwise oppressive behavior, whether casual or explicit.
|
||||
|
||||
### 3.4. Oppression and Neutrality
|
||||
|
||||
:::caution
|
||||
Neutrality in the face of oppression is to choose the side of the oppressor.
|
||||
:::
|
||||
|
||||
We understand that not everyone may be aware of the struggles that underprivileged classes face. Asking questions to inform yourself is good.
|
||||
|
||||
But attempting to "bow out" of a discussion, or to claim you are remaining neutral when an under-represented person shares their experiences with oppression and anti-* legislation, is just as bad as siding against those underprivileged classes.
|
||||
|
||||
As such, behaviour like this is considered a violation of our Code of Conduct and will be actioned accordingly.
|
||||
|
||||
### 3.5. Content and Communication
|
||||
|
||||
- No explicit sexual images or behavior.
|
||||
- No use of slurs or hateful terminology.
|
||||
- Content warnings should be used when discussing potentially triggering topics.
|
||||
|
||||
### 3.6. Intellectual Property and Privacy
|
||||
|
||||
- Respect copyright and intellectual property rights.
|
||||
- Do not share personal information of others without their explicit consent.
|
||||
|
||||
### 3.7. Community Discussions and Debates
|
||||
|
||||
- Engage in respectful and constructive dialogue.
|
||||
- Be open to learning from others' perspectives.
|
||||
- Avoid derailing discussions or intentionally inflaming tensions.
|
||||
|
||||
### 3.8. Reporting and Enforcement
|
||||
|
||||
- Report violations of this Code of Conduct to community leaders promptly.
|
||||
- Cooperate with community leaders during investigations of reported incidents.
|
||||
- Respect the privacy of individuals involved in reports and investigations.
|
||||
|
||||
### 3.9. Compliance with Platform-Specific Rules
|
||||
|
||||
- Adhere to the terms of service and community guidelines of any platforms used by Our Community.
|
||||
- Be aware that certain behaviors may violate platform rules even if not explicitly mentioned in this Code of Conduct.
|
||||
|
||||
### 3.10. Amendments and Interpretations
|
||||
|
||||
- These rules may be amended or expanded as necessary to address emerging issues.
|
||||
- Community leaders reserve the right to interpret these rules and make decisions in cases where the application of rules may be unclear.
|
||||
|
||||
## 4. Reporting and Response Procedures
|
||||
|
||||
### 4.1. Reporting Methods
|
||||
|
||||
- In Discord: Type @Moderator in any channel to alert community leaders.
|
||||
- Direct Message: Contact a community leader directly via private message.
|
||||
- Email: contact@nhcarrigan.com
|
||||
|
||||
### 4.2. Information to Include in Reports
|
||||
|
||||
- Your contact information (unless reporting anonymously)
|
||||
- Names or descriptions of individuals involved
|
||||
- Description of the incident, including date, time, and location (online or physical)
|
||||
- Any relevant screenshots, chat logs, or other evidence
|
||||
- Any additional context you believe is important
|
||||
|
||||
### 4.3. Handling of Reports
|
||||
|
||||
- We will respond to all reports as promptly as possible.
|
||||
- If a reported violator is on our staff team, they will be immediately recused from handling the incident.
|
||||
- All reports will be handled with discretion and confidentiality to the extent possible.
|
||||
|
||||
### 4.4. Confidentiality and Privacy
|
||||
|
||||
- We will respect confidentiality requests, especially to protect victims of abuse.
|
||||
- Anonymous reporting options are available, though they may limit our ability to investigate.
|
||||
|
||||
### 4.5. Public Statements and Warnings
|
||||
|
||||
- At our discretion, we may publicly name a person about whom we've received harassment complaints.
|
||||
- We may privately warn third parties about individuals if we believe it will increase community safety.
|
||||
- We will not name harassment victims without their explicit, affirmative consent.
|
||||
|
||||
### 4.6. False Reports and Abuse of Process
|
||||
|
||||
- We reserve the right to reject reports we believe to have been made in bad faith.
|
||||
- Reports intended to silence legitimate criticism may be dismissed without response.
|
||||
- Deliberately false reporting is a violation of this Code of Conduct and may result in sanctions.
|
||||
|
||||
### 4.7. Protection of Reporters and Victims
|
||||
|
||||
- We will take all reasonable steps to protect reporters and victims from retaliation.
|
||||
- Retaliation against reporters or victims is a serious violation of this Code of Conduct.
|
||||
|
||||
### 4.8. Investigation Process
|
||||
|
||||
- We will conduct a thorough and impartial investigation of all reports.
|
||||
- Investigations will be conducted as quickly as possible while ensuring thoroughness.
|
||||
- All parties involved will be given an opportunity to present their perspective.
|
||||
|
||||
### 4.9. Outcomes and Appeals
|
||||
|
||||
- After investigation, we will determine appropriate actions based on the evidence.
|
||||
- We will communicate outcomes to involved parties as appropriate, respecting privacy concerns.
|
||||
- An appeals process will be available for individuals who believe a decision was made in error.
|
||||
|
||||
### 4.10. Continuous Improvement
|
||||
|
||||
- We will regularly review our reporting and response procedures to ensure their effectiveness.
|
||||
- Feedback on these procedures is welcome and will be considered for future improvements.
|
||||
|
||||
### 4.11. Support for Community Leaders
|
||||
|
||||
- We recognize the potential for burnout among our volunteer moderators and leaders.
|
||||
- We will provide support and resources to our community leaders to help them manage their responsibilities effectively.
|
||||
|
||||
## 5. Sanctions and Enforcement
|
||||
|
||||
### 5.1. General Principles
|
||||
|
||||
- Participants must immediately comply when asked to stop any harmful behavior.
|
||||
- Community leaders may take any appropriate action in response to harmful behavior.
|
||||
- All sanctions will be applied fairly, consistently, and proportionally to the violation.
|
||||
|
||||
### 5.2. Authority of Community Leaders
|
||||
|
||||
- Community leaders have the right and responsibility to remove, edit, or reject contributions not aligned with this Code of Conduct.
|
||||
- Leaders commit to applying these principles fairly and consistently in all aspects of community management.
|
||||
- Leaders who fail to follow or enforce the Code of Conduct may be permanently removed from their position.
|
||||
|
||||
### 5.3 Sanction Criteria
|
||||
|
||||
The following list outlines the criteria used when determining if a sanction should be issued.
|
||||
|
||||
- Behaviour which violates this Code of Conduct, our Community Guidelines, or our other public policies.
|
||||
- Behaviour which our staff feel is not in the spirit of the policy, even if it is not violating the letter of the policy.
|
||||
- Repeated behaviour that has been previously sanctioned, as outlined in our escalation policy.
|
||||
- Attempts to circumvent sanctions, such as ban evasion.
|
||||
|
||||
### 5.4. Privacy and Security
|
||||
|
||||
- All community leaders are obligated to respect the privacy and security of incident reporters.
|
||||
- Information about sanctions will be shared on a need-to-know basis.
|
||||
|
||||
### 5.5. Gradated Sanction System
|
||||
|
||||
Community leaders will follow these Community Impact Guidelines in determining consequences:
|
||||
|
||||
#### 5.5.1. Level 1: Reminder
|
||||
|
||||
- Example Behavior: Use of inappropriate language or other behavior deemed unprofessional or unwelcome.
|
||||
- Consequences:
|
||||
- A public, written reminder from community leaders
|
||||
- Clarification of the violation and why the behavior was inappropriate
|
||||
- A public apology may be requested
|
||||
|
||||
#### 5.5.2. Level 2: Warning
|
||||
|
||||
- Example Behavior: A violation through a single incident or series of actions.
|
||||
- Consequences:
|
||||
- A formal warning
|
||||
- Clear communication of consequences for continued behavior
|
||||
- Incident is logged for future reference
|
||||
|
||||
#### 5.5.3. Level 3: Temporary Removal
|
||||
|
||||
- Example Behavior: A serious violation of community standards or sustained inappropriate behavior.
|
||||
- Consequences:
|
||||
- Temporary removal from community platforms (e.g., Discord kick)
|
||||
- Clear conditions for return, including a cooling-off period
|
||||
- Requirement to re-read and acknowledge the Code of Conduct before rejoining
|
||||
|
||||
#### 5.5.4. Level 4: Permanent Ban
|
||||
|
||||
- Example Behavior: Pattern of violations, sustained inappropriate behavior, harassment, or aggression towards individuals or groups.
|
||||
- Consequences:
|
||||
- Permanent ban from all community platforms
|
||||
- Public statement may be made, if deemed necessary for community safety
|
||||
|
||||
### 5.6. Additional Sanction Considerations
|
||||
|
||||
- Repeated violations will generally result in escalating sanctions.
|
||||
- The severity of the violation may warrant skipping levels in the sanction system.
|
||||
- Community leaders may impose additional requirements, such as public apologies or community service, as conditions for continued participation.
|
||||
|
||||
### 5.7. Appeals Process
|
||||
|
||||
- Individuals may appeal sanctions by [completing the form](/community/appeal)
|
||||
- Appeals will be reviewed by leaders not involved in the original decision.
|
||||
- During the appeal, the original sanction remains in effect.
|
||||
|
||||
### 5.8. Documentation and Transparency
|
||||
|
||||
- All formal sanctions will be publicised for review and consistency. Sanctions can be viewed at https://logs.nhcarrigan.com.
|
||||
- Aggregate data on Code of Conduct violations and sanctions may be published periodically to ensure transparency.
|
||||
|
||||
### 5.9. Rehabilitation and Education
|
||||
|
||||
- Where appropriate, we will provide resources and support for individuals to learn from their mistakes and improve their behavior.
|
||||
- For less severe violations, completion of educational programs may be offered as an alternative or supplement to other sanctions.
|
||||
|
||||
### 5.10. Legal Implications
|
||||
|
||||
- In cases of illegal activity, appropriate legal authorities may be notified.
|
||||
- Our sanctions do not preclude or replace any legal action that may be warranted.
|
||||
|
||||
### 5.11. Regular Review
|
||||
|
||||
- This sanction system will be reviewed periodically to ensure its effectiveness and fairness.
|
||||
- Community feedback on the sanction system is welcome and will be considered in reviews.
|
||||
|
||||
## 6. Moderation Logs and Transparency
|
||||
|
||||
### 6.1. Purpose of Moderation Logs
|
||||
|
||||
- To ensure transparency in moderation sanctions
|
||||
- To maintain accountability of the moderation team to community members
|
||||
- To provide a clear record of enforcement of the Code of Conduct
|
||||
|
||||
### 6.2. Scope of Logged Actions
|
||||
|
||||
- All moderation sanctions across all community platforms will be logged
|
||||
- This includes, but is not limited to:
|
||||
- Warnings issued
|
||||
- Temporary removals or suspensions
|
||||
- Permanent bans
|
||||
- Appeals and their outcomes
|
||||
|
||||
### 6.3. Location of Moderation Logs
|
||||
|
||||
- All moderation sanctions will be publicly logged at https://logs.nhcarrigan.com
|
||||
- The log will be accessible to all community members
|
||||
|
||||
### 6.4. Information Included in Logs
|
||||
|
||||
- Date and time of the action
|
||||
- Type of action taken
|
||||
- Reason for the action
|
||||
- Platform where the violation occurred
|
||||
- Identifier of the user who received the action
|
||||
- Identifier of the leader who performed the action
|
||||
- Any relevant evidence
|
||||
|
||||
### 6.5. Privacy Considerations
|
||||
|
||||
- In cases where privacy is crucial (e.g., harassment reports), certain details may be omitted or generalized
|
||||
|
||||
### 6.6. Accessibility of Logs
|
||||
|
||||
- The moderation log channel will be read-only for regular community members
|
||||
- Community members can request clarification on logged sanctions through appropriate channels
|
||||
|
||||
### 6.7. Retention of Logs
|
||||
|
||||
- Moderation logs will be retained for a period of no less than 1 year.
|
||||
- After this period, logs may be archived or summarized for long-term record-keeping
|
||||
|
||||
### 6.8. Audit and Review
|
||||
|
||||
- Moderation logs will be periodically reviewed by community leadership to ensure consistency and fairness in enforcement
|
||||
- Annual reports summarizing moderation actions may be published to the community
|
||||
|
||||
### 6.9. Dispute Resolution
|
||||
|
||||
- If a community member believes a moderation action was taken in error, they can refer to the logs and follow the appeals process outlined in the Sanctions section
|
||||
|
||||
### 6.10. Moderator Accountability
|
||||
|
||||
- Patterns of biased or inconsistent moderation will be addressed by community leadership
|
||||
- Moderators who consistently fail to log their actions may have their privileges revoked
|
||||
|
||||
### 6.11. Feedback and Improvement
|
||||
|
||||
- Community members are encouraged to provide feedback on the moderation log system
|
||||
- The logging process will be reviewed periodically and may be adjusted to better serve the community's needs
|
||||
|
||||
## 7. Advertising and Promotion
|
||||
|
||||
### 7.1. General Prohibition
|
||||
|
||||
- Advertising and self-promotion are generally not permitted within our community spaces.
|
||||
- This includes, but is not limited to, unsolicited promotion of products, services, websites, social media accounts, or other communities.
|
||||
|
||||
### 7.2. Exceptions
|
||||
|
||||
- Links or information expressly requested by our team for support or moderation purposes.
|
||||
- Sharing of resources directly relevant to ongoing discussions, when done in good faith and not for commercial gain.
|
||||
- Official announcements or promotions approved by community leadership.
|
||||
|
||||
### 7.3. Support and Moderation Contexts
|
||||
|
||||
- Community members may be asked to provide links or information to assist with support inquiries or moderation investigations.
|
||||
- In these cases, sharing such information is permitted and encouraged.
|
||||
|
||||
### 7.4. Relevance and Context
|
||||
|
||||
- Any shared links or information must be directly relevant to the current discussion or inquiry.
|
||||
- The relevance and appropriateness of shared content will be at the discretion of community leaders.
|
||||
|
||||
### 7.5. Disclosure of Affiliations
|
||||
|
||||
- If sharing information about a product or service with which you have a personal or professional affiliation, this affiliation must be clearly disclosed.
|
||||
|
||||
### 7.6. Consequences of Violation
|
||||
|
||||
- Violations of this policy will be treated as a breach of the Code of Conduct.
|
||||
- Consequences may range from content removal to temporary or permanent bans, depending on the severity and frequency of violations.
|
||||
|
||||
### 7.7. Appeals and Clarifications
|
||||
|
||||
- If you are unsure whether specific content would be considered advertising, consult with a community leader before posting.
|
||||
- If your content is removed under this policy, you may appeal the decision through the established channels outlined in the Sanctions section.
|
||||
|
||||
## 8. Languages
|
||||
|
||||
### 8.1. Official Language
|
||||
|
||||
- The official language of our community is English.
|
||||
- All community interactions, discussions, and contributions should be in English.
|
||||
|
||||
### 8.2. Scope of English-Only Policy
|
||||
|
||||
- This policy applies to all community spaces, including but not limited to:
|
||||
- Discord channels
|
||||
- GitHub discussions and issues
|
||||
- Documentation
|
||||
- Official communication channels
|
||||
|
||||
### 8.3. Multilingual Applications
|
||||
|
||||
- Even if our applications or services are offered in multiple languages, community discussions about them must be conducted in English.
|
||||
|
||||
### 8.4. Rationale
|
||||
|
||||
- To ensure clear communication among all community members.
|
||||
- To facilitate effective moderation and support.
|
||||
- To maintain consistency across all community platforms.
|
||||
|
||||
### 8.5. Exceptions
|
||||
|
||||
- Specific channels or sections designated for other languages, if explicitly created and approved by community leadership.
|
||||
- Brief translations to assist non-native English speakers, when immediately followed by an English translation.
|
||||
|
||||
### 8.6. Support for Non-Native Speakers
|
||||
|
||||
- We encourage patience and understanding towards non-native English speakers.
|
||||
- Community members are encouraged to help clarify or rephrase messages if there's a language barrier, while maintaining English as the primary language.
|
||||
|
||||
### 8.7. Translation Tools
|
||||
|
||||
- While automatic translation tools may be used personally, the original English content should be included in all community interactions.
|
||||
@ -1,497 +0,0 @@
|
||||
---
|
||||
title: Community Guidelines
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
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.
|
||||
|
||||
### 1.1. Purpose
|
||||
|
||||
The purpose of these Community Guidelines is to:
|
||||
|
||||
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
|
||||
|
||||
### 1.2 Scope
|
||||
|
||||
These guidelines apply to all forms of interaction within our community, including but not limited to:
|
||||
|
||||
- Forum discussions
|
||||
- Comment sections
|
||||
- Direct messaging
|
||||
- Live events or webinars
|
||||
- Social media interactions associated with our community
|
||||
|
||||
### 1.3 Encouragement to Participate
|
||||
|
||||
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
|
||||
|
||||
Please remember that our staff members generously volunteer their time to help our community remain safe and welcoming. Above all else, be kind to them - moderating online spaces is *hard*, and we don't need to make it harder on them!
|
||||
|
||||
### 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.
|
||||
|
||||
### 2.6 Responding to Sanctions
|
||||
|
||||
If you receive a sanction, here are tips on how to avoid further moderation action:
|
||||
|
||||
- Do not continue the behaviour
|
||||
- Do not attempt to continue the behaviour in a slightly modified way, such as to avoid a specific component of our policies
|
||||
- Do not make passive-aggressive comments about our policies, staff, or your sanction
|
||||
- Do not try to justify your behaviour by comparing it to another user's that was not sanctioned
|
||||
- Do try to learn from the sanction and improve your interactions
|
||||
- Do keep an open mind and try to learn
|
||||
- Do be the kindest you can be
|
||||
|
||||
## 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, humour, 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 /b` for sarcastic and bitter
|
||||
- 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 |
|
||||
| ---------------------- | ------------------------------------ |
|
||||
| `/aff` | Affectionate |
|
||||
| `/apa` | Apathetic |
|
||||
| `/b` | Bitter |
|
||||
| `/cel` | Celebratory |
|
||||
| `/ci` | Caring Intent |
|
||||
| `/cj` | Coping Joke |
|
||||
| `/co` or `/cf` | Comforting |
|
||||
| `/ex` | Exaggeration |
|
||||
| `/f` | fake |
|
||||
| `/fam` | Familial |
|
||||
| `/fex` | for example |
|
||||
| `/gen` or `/g` | Genuine |
|
||||
| `/genq` or `/gq` | Genuine Question |
|
||||
| `/gens` or `/gs` | Genuine Suggestion |
|
||||
| `/hj` | Half Joking |
|
||||
| `/hyp` | Hyperbole |
|
||||
| `/ij` | Inside Joke |
|
||||
| `/info` | Information |
|
||||
| `/j` | Joking |
|
||||
| `/jov` | Jokingly Overreacting |
|
||||
| `/l`, `/ly` or `/lyr` | Lyrics |
|
||||
| `/lh` | Lighthearted |
|
||||
| `/li` or `/lit` | Literally |
|
||||
| `/lu` | Little Upset |
|
||||
| `/m` | Metaphorically |
|
||||
| `/md` | Melodramatic |
|
||||
| `/nav` | Not A Vent |
|
||||
| `/nay` | Not At You |
|
||||
| `/nbh` | Nobody Here (for vague venting only) |
|
||||
| `/nbr` | Not Being Rude |
|
||||
| `/nc` or `/neg` | Negative connotation |
|
||||
| `/ncm` | Not Comparing |
|
||||
| `/neu` | Neutral connotation |
|
||||
| `/nf` | Not Forced |
|
||||
| `/nm` | Not Mad (or upset) |
|
||||
| `/np` | No Pressure |
|
||||
| `/npa` | Not Passive Aggressive |
|
||||
| `/nsx` or `/nx` | Non Sexual Intent |
|
||||
| `/ny` | Not Yelling |
|
||||
| `/op` | Optional |
|
||||
| `/ot` | Off Topic |
|
||||
| `/p` or `/plat` | Platonic |
|
||||
| `/pc` or `/pos` | Positive connotation |
|
||||
| `/q` | Quote |
|
||||
| `/ref` | Reference |
|
||||
| `/rh`, `/rt` or `/rhq` | Rhetorical Question |
|
||||
| `/s` or `/sar` | Sarcastic |
|
||||
| `/srs` | Serious |
|
||||
| `/sym` | Sympathetic |
|
||||
| `/t` | Teasing |
|
||||
| `/tc`, `/ti` or `/tic` | Typing a tic |
|
||||
|
||||
### 4.5 Respecting Tone Tags
|
||||
|
||||
- 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
|
||||
|
||||
### 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
|
||||
<!-- cSpell:disable-next-line -->
|
||||
- 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
|
||||
|
||||
:::caution[Warning!]
|
||||
Content/Trigger warnings are **mandatory** in all of our community spaces. Repeated patterns of failure to properly label your content will result in sanctions. "I forgot" is not an acceptable excuse.
|
||||
:::
|
||||
|
||||
Use content or trigger warnings when posting about:
|
||||
|
||||
- Graphic violence or gore
|
||||
- Sexual content or explicit discussions of sexuality (except within our clearly-indicated adult-only areas)
|
||||
- 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
|
||||
|
||||
## 9. This Should Be Fun!
|
||||
|
||||
It is important to remember that engaging with our community should be a fun process. If you aren't enjoying your time, please consider some of these options:
|
||||
|
||||
### 9.1. Take a Break
|
||||
|
||||
It's okay if you need some time away from our community! We'll be here when you get back, so don't hesitate to step away for a while and decompress. Let yourself come back refreshed so you have the best experience possible.
|
||||
|
||||
### 9.2. Evaluate Your Engagement
|
||||
|
||||
Our community spaces are intended to be fun, relaxed, and wholesome environments. If you find that you aren't meshing with our vibe in the way that you want, consider taking a look at the type of interactions you are creating. It may be that you aren't using our community in the best way.
|
||||
|
||||
### 9.3. Temporary Bans
|
||||
|
||||
If you need a break and you find yourself unable to step away, or you keep coming back to check on things when you really do not want to, please reach out to our staff. We are more than willing to issue temporary bans to help you preserve the space you need.
|
||||
|
||||
## 10. Mini-modding
|
||||
|
||||
"Mini-modding" is a term often used to describe behaviour in which a non-staff user instructs another user to amend their behaviour as if they were a member of staff.
|
||||
|
||||
Our community does not prohibit mini-modding, provided:
|
||||
|
||||
- You gently encourage and support members in properly integrating with our community
|
||||
- You do not represent yourself as a member of NHCarrigan's team
|
||||
- You do not belittle, call out, or antagonise a user who is violating our policies
|
||||
|
||||
Remember that the best way to correct someone's behaviour is to lead by example. If that fails, do not escalate - instead, report the behaviour to our team.
|
||||
@ -1,606 +0,0 @@
|
||||
---
|
||||
title: Contributing Documentation
|
||||
---
|
||||
|
||||
## 1. Scope and General Contribution Guidelines
|
||||
|
||||
### 1.1 Overview
|
||||
|
||||
This document outlines the general guidelines for contributing to our projects. It serves as a high-level framework for all contributors, whether you're submitting code, documentation, or other forms of contribution.
|
||||
|
||||
### 1.2 Project-Specific Instructions
|
||||
|
||||
While these guidelines apply broadly, individual projects may have unique requirements or processes. Always refer to the specific project's documentation for:
|
||||
|
||||
- Supplemental instructions
|
||||
- Project-specific workflows
|
||||
- Coding standards
|
||||
- Testing requirements
|
||||
- Other relevant information
|
||||
|
||||
In case of any discrepancy between this document and project-specific guidelines, the project-specific instructions take precedence.
|
||||
|
||||
### 1.3 Commit Signing Requirements
|
||||
|
||||
All commits must be cryptographically signed using either GPG or SSH. This requirement serves to verify the authenticity and integrity of your contributions.
|
||||
|
||||
- For GPG signing, ensure your GPG key is associated with your GitHub or Codeberg account.
|
||||
- For SSH signing, use a key linked to your GitHub or Codeberg account.
|
||||
|
||||
By signing your commit, you are certifying that:
|
||||
|
||||
- The commit adheres to our [Contributor Covenant](/covenant.md)
|
||||
- You have the right to submit the contribution under our project license.
|
||||
- You understand and agree to our contribution terms.
|
||||
|
||||
### 1.4 Contributor Covenant
|
||||
|
||||
All contributors are expected to adhere to our Contributor Covenant. The full text of the Contributor Covenant can be found in [its own document](/covenant.md).
|
||||
|
||||
### 1.5 Licensing of Contributions
|
||||
|
||||
All contributions to our projects, including but not limited to code, documentation, artwork, and other materials, will be licensed under our global software license. By submitting a contribution, you are agreeing to license your work under the terms of this license.
|
||||
|
||||
- Our global software license: Naomi's Public License
|
||||
- Full text of the license: https://docs.nhcarrigan.com/#/license
|
||||
|
||||
### 1.6 Intellectual Property
|
||||
|
||||
By contributing to our projects, you affirm that:
|
||||
|
||||
- You own the copyright to your contribution or have authorization from the copyright owner to submit it under our license.
|
||||
- Your contribution does not infringe on any third-party intellectual property rights.
|
||||
- You grant us a perpetual, worldwide, non-exclusive, royalty-free license to use, modify, and distribute your contribution.
|
||||
|
||||
### 1.7 Legal Compliance
|
||||
|
||||
Ensure all contributions comply with relevant laws and regulations, including export controls and data protection laws.
|
||||
|
||||
### 1.8 Acceptance of Contributions
|
||||
|
||||
While we appreciate all contributions, we reserve the right to reject any contribution that doesn't meet our standards or align with our project goals. The project maintainers have final say on the inclusion of any contribution.
|
||||
|
||||
## 2. Secrets Management
|
||||
|
||||
### 2.1 Overview
|
||||
|
||||
Proper management of secrets is crucial for maintaining the security and integrity of our projects. We use 1Password as our centralized secrets management solution. This section outlines our policies and procedures for handling secrets.
|
||||
|
||||
### 2.2 General Policy
|
||||
|
||||
- Plain-text secrets should never be stored on personal machines, development environments, or our servers.
|
||||
- All secrets should be stored and managed through 1Password.
|
||||
|
||||
### 2.3 1Password Setup and Usage
|
||||
|
||||
To work with secrets locally, you must set up the 1Password CLI (Command Line Interface) and integrate it with your 1Password desktop application.
|
||||
|
||||
#### 2.3.1 Setup Instructions
|
||||
|
||||
- Install the 1Password desktop application if you haven't already.
|
||||
- Install the 1Password CLI. Instructions can be found at: https://developer.1password.com/docs/cli/get-started/
|
||||
- Authenticate the CLI with your 1Password account.
|
||||
- Configure your development environment to use the 1Password CLI for secret retrieval. https://developer.1password.com/docs/cli/secrets-environment-variables/
|
||||
|
||||
#### 2.3.2 Best Practices
|
||||
|
||||
- Use environment variables to store secrets retrieved from 1Password during runtime.
|
||||
- Never log or display secrets in any form.
|
||||
- Rotate secrets regularly.
|
||||
|
||||
### 2.4 Handling Secrets in Code
|
||||
|
||||
- Development environment variables should be set in `dev.env` - changes to this file should generally be excluded from your contributions.
|
||||
- Use 1Password references instead of actual secret values in configuration files.
|
||||
|
||||
## 3. Setting Up Your Development Environment
|
||||
|
||||
### 3.1 Forking the Repository
|
||||
|
||||
1. Navigate to the original repository on Codeberg.
|
||||
2. Click the "Fork" button in the upper right corner of the page.
|
||||
3. Select your account as the destination for the fork.
|
||||
4. Wait for Codeberg to create a copy of the repository in your account.
|
||||
|
||||
### 3.2 Cloning Your Fork
|
||||
|
||||
1. Go to your forked repository on Codeberg.
|
||||
2. Click the "Code" button and copy the URL (HTTPS or SSH, depending on your setup).
|
||||
3. Open your terminal or command prompt.
|
||||
4. Navigate to the directory where you want to store the project.
|
||||
5. Run the following command, replacing `<url>` with the URL you copied:
|
||||
|
||||
```
|
||||
git clone <url>
|
||||
```
|
||||
|
||||
6. Enter your GitHub credentials if prompted.
|
||||
|
||||
### 3.3 Setting Up the Upstream Remote
|
||||
|
||||
Adding the original repository as an upstream remote allows you to easily keep your fork up-to-date.
|
||||
|
||||
1. Change into the project directory:
|
||||
|
||||
```
|
||||
cd <project-name>
|
||||
```
|
||||
|
||||
2. Add the upstream remote:
|
||||
|
||||
```
|
||||
git remote add upstream <original-repository-url>
|
||||
```
|
||||
|
||||
Replace `<original-repository-url>` with the **git** URL of the original repository.
|
||||
|
||||
3. Verify the new remote:
|
||||
|
||||
```
|
||||
git remote -v
|
||||
```
|
||||
|
||||
You should see entries for both `origin` (your fork) and `upstream`.
|
||||
|
||||
### 3.4 Keeping Your Fork Up-to-Date
|
||||
|
||||
Regularly update your fork to incorporate changes from the upstream repository:
|
||||
|
||||
1. Fetch the branches and commits from the upstream repository:
|
||||
|
||||
```
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
2. Check out your fork's local main branch:
|
||||
|
||||
```
|
||||
git checkout main
|
||||
```
|
||||
|
||||
3. Merge changes from upstream/main into your local main branch:
|
||||
|
||||
```
|
||||
git merge upstream/main
|
||||
```
|
||||
|
||||
### 3.5 Troubleshooting
|
||||
|
||||
If you encounter any issues during setup:
|
||||
|
||||
1. Check the project's FAQ or troubleshooting guide (if available).
|
||||
2. Search for similar issues in the project's issue tracker.
|
||||
3. If the problem persists, open a new issue with detailed information about the problem and steps to reproduce it.
|
||||
|
||||
You can also reach out to us in our Discord server: https://chat.nhcarrigan.com
|
||||
|
||||
## 4. Claiming an Issue
|
||||
|
||||
### 4.1 Finding an Issue
|
||||
|
||||
1. Navigate to the project's issue tracker.
|
||||
2. Browse open issues or use filters to find tasks that interest you.
|
||||
3. Read the issue description thoroughly to understand the requirements and context.
|
||||
|
||||
### 4.2 Expressing Interest
|
||||
|
||||
1. If you find an issue you'd like to work on, comment on the issue expressing your interest.
|
||||
2. Example comment: "I'm interested in working on this issue. May I be assigned to it?"
|
||||
3. Wait for a project maintainer to respond and potentially assign the issue to you.
|
||||
|
||||
### 4.3 Issue Assignment
|
||||
|
||||
- Project maintainers will assign issues based on the order of interest and the contributor's experience level.
|
||||
- Once assigned, you'll see your username in the "Assignees" section of the issue.
|
||||
|
||||
### 4.4 Already Assigned Issues
|
||||
|
||||
If an issue is already assigned:
|
||||
|
||||
1. Check the assignee and the last activity date.
|
||||
2. If you're still interested in contributing, you can:
|
||||
a. Comment on the issue expressing your interest to collaborate.
|
||||
b. Reach out to the assigned person to offer assistance or discuss collaboration.
|
||||
|
||||
We encourage collaboration and pair programming on complex issues!
|
||||
|
||||
### 4.5 Working on the Issue
|
||||
|
||||
1. Once assigned, create a new branch in your fork for this specific issue.
|
||||
2. Use a descriptive branch name, e.g., `fix/issue-123-button-alignment`.
|
||||
3. Make your changes, committing regularly with clear, concise commit messages.
|
||||
4. Push your changes to your fork.
|
||||
5. Open a pull request when ready for review (see Pull Request Guidelines in section [X]).
|
||||
|
||||
### 4.6 Keeping the Community Updated
|
||||
|
||||
1. Provide regular updates on your progress in the issue comments.
|
||||
2. If you encounter obstacles, don't hesitate to ask for help in the issue thread.
|
||||
3. If you need to step away from an issue, please let us know so it can be reassigned if necessary.
|
||||
|
||||
### 4.7 Time Management
|
||||
|
||||
- Try to start working on the issue within a few days of assignment.
|
||||
- If you haven't made progress within a week, the issue may be unassigned to keep the project moving forward.
|
||||
- If you need more time, communicate this in the issue comments.
|
||||
|
||||
### 4.8 Multiple Issues
|
||||
|
||||
- We encourage focusing on one issue at a time to ensure quality and timely completion.
|
||||
- If you want to work on multiple issues, please complete one before requesting assignment to another.
|
||||
|
||||
### 4.9 Issue Labels
|
||||
|
||||
Pay attention to issue labels for additional context:
|
||||
|
||||
- `good first issue`: Suitable for newcomers to the project or open source.
|
||||
- `help wanted`: Issues where we're actively seeking community help.
|
||||
- `staff only`: Issue that will require staff attention.
|
||||
|
||||
### 4.10 Respectful Communication
|
||||
|
||||
- Always be courteous and professional in issue discussions.
|
||||
- Respect the decisions of project maintainers regarding issue assignments and priorities.
|
||||
- If you disagree with something, express your thoughts constructively and be open to feedback.
|
||||
|
||||
## 5. Working on Your Issue
|
||||
|
||||
### 5.1 Updating Your Fork
|
||||
|
||||
Before starting work, ensure your forked version is up to date with the original repository. If you've set up the `upstream` remote as mentioned in Section 3, follow these steps:
|
||||
|
||||
1. Open your terminal and navigate to your project's root directory.
|
||||
2. Run the following commands:
|
||||
|
||||
```bash
|
||||
git fetch upstream
|
||||
git merge upstream/main
|
||||
```
|
||||
|
||||
### 5.2 Creating a New Branch
|
||||
|
||||
Always create a new branch for your work:
|
||||
|
||||
1. Create and switch to a new branch:
|
||||
|
||||
```bash
|
||||
git checkout -b <branchname>
|
||||
```
|
||||
|
||||
2. Follow the branch naming convention: `type/description`
|
||||
|
||||
- `type`: Indicates the nature of the changes (e.g., `feat`, `fix`, `docs`, `refactor`)
|
||||
- `description`: A brief, hyphenated description of the changes
|
||||
|
||||
Examples:
|
||||
|
||||
- `feat/add-login-page`
|
||||
- `fix/resolve-memory-leak`
|
||||
- `docs/update-api-endpoints`
|
||||
|
||||
### 5.3 Making Changes
|
||||
|
||||
1. Make your code changes, following the project's coding standards and guidelines.
|
||||
2. Regularly commit your changes with clear, concise messages.
|
||||
3. Push your changes to your fork periodically:
|
||||
|
||||
```bash
|
||||
git push origin <branchname>
|
||||
```
|
||||
|
||||
### 5.4 Committing Changes
|
||||
|
||||
When you're ready to commit your changes:
|
||||
|
||||
1. Stage your changes:
|
||||
|
||||
```bash
|
||||
git add .
|
||||
```
|
||||
|
||||
Or stage specific files:
|
||||
|
||||
```bash
|
||||
git add <file1> <file2>
|
||||
```
|
||||
|
||||
2. Commit:
|
||||
|
||||
```bash
|
||||
git commit
|
||||
```
|
||||
|
||||
### 5.5 Commit Message Guidelines
|
||||
|
||||
- Follow Conventional Commit standards: `type(scope): description` such as `docs: update contributing guidelines`.
|
||||
- Use the present tense ("Add feature" not "Added feature")
|
||||
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
|
||||
- Limit the first line to 50 characters or less
|
||||
- Additional information can be included in the body
|
||||
- Do NOT reference issues/PRs in your commit
|
||||
|
||||
Example:
|
||||
|
||||
```
|
||||
feat: add user authentication system
|
||||
|
||||
Implement JWT-based authentication for API endpoints.
|
||||
```
|
||||
|
||||
### 5.7 Testing Your Changes
|
||||
|
||||
- Run the linter to ensure your code complies with [our style guidelines](/dev/style).
|
||||
|
||||
```bash
|
||||
pnpm lint # or the appropriate lint command for your project
|
||||
```
|
||||
|
||||
- Run any existing tests to ensure your changes haven't broken anything:
|
||||
|
||||
```bash
|
||||
pnpm test # or the appropriate test command for your project
|
||||
```
|
||||
|
||||
- Add new tests for your changes if applicable.
|
||||
|
||||
### 5.8 Documentation
|
||||
|
||||
- Update relevant documentation to reflect your changes.
|
||||
- If you've added new features, include appropriate documentation.
|
||||
|
||||
### 5.9 Preparing for Pull Request
|
||||
|
||||
Before submitting a pull request:
|
||||
|
||||
1. Check that your code adheres to the project's style guidelines - the linters should pass.
|
||||
1. Ensure the build succeeds.
|
||||
1. Ensure all tests pass.
|
||||
1. Review your changes and commit history.
|
||||
|
||||
If you're unsure about any part of the process or need help, don't hesitate to ask in our [chat server](https://chat.nhcarrigan.com). Our community is here to support you!
|
||||
|
||||
## 6. Submitting a Pull Request
|
||||
|
||||
### 6.1 Pushing Your Changes
|
||||
|
||||
1. Push your changes to your forked repository:
|
||||
|
||||
```bash
|
||||
git push -u origin <branchname>
|
||||
```
|
||||
|
||||
- `-u` sets the upstream, linking your local branch to the remote branch
|
||||
- `origin` specifies your forked repository as the destination
|
||||
- `<branchname>` is the name of your local branch
|
||||
|
||||
2. Ensure the push is successful and your changes appear in your forked repository on Codeberg.
|
||||
|
||||
### 6.2 Creating the Pull Request
|
||||
|
||||
1. Navigate to your forked repository on Codeberg.
|
||||
2. You should see a prompt to create a pull request for your recently pushed branch. If not, click on the "Pull requests" tab and then the "New pull request" button.
|
||||
3. Ensure the base repository is the original project repository and the base branch is `main`.
|
||||
4. Select your fork as the head repository and your recently pushed branch as the compare branch.
|
||||
|
||||
### 6.3 Filling Out the Pull Request
|
||||
|
||||
1. Change the title of your pull request to be a conventional commit message summarising all changes in that PR
|
||||
2. Fill out the pull request description with as much information as possible. This typically includes:
|
||||
- A clear description of the changes
|
||||
- The issue number(s) your pull request addresses
|
||||
- Any additional context or explanations
|
||||
3. Fill out the rest of the pull request form *completely*.
|
||||
4. If your changes include visual elements, consider adding screenshots or GIFs to illustrate the modifications.
|
||||
|
||||
### 6.4 Pull Request Best Practices
|
||||
|
||||
- Ensure your PR addresses only one issue or adds one feature. If you have made multiple unrelated changes, consider breaking them into separate pull requests.
|
||||
- Double-check that all tests pass and there are no conflicts with the base branch.
|
||||
- If your PR is a work in progress, mark it as a draft pull request.
|
||||
|
||||
### 6.5 After Submitting
|
||||
|
||||
- Keep an eye on your pull request for any comments, requests for changes, or approval.
|
||||
- Be prepared to make additional commits to your branch if changes are requested.
|
||||
|
||||
### 6.6 Updating Your Pull Request
|
||||
|
||||
If you need to make changes to your pull request:
|
||||
|
||||
1. Make the required changes in your local branch.
|
||||
2. Commit the changes.
|
||||
3. Push the new commits to your fork:
|
||||
|
||||
```bash
|
||||
git push origin <branchname>
|
||||
```
|
||||
|
||||
4. The pull request will automatically update with your new commits.
|
||||
|
||||
### 6.7 Pull Request Etiquette
|
||||
|
||||
- Be patient. Maintainers are often managing multiple priorities.
|
||||
- Be open to feedback and willing to make changes.
|
||||
- Respond promptly to any questions or requests from reviewers.
|
||||
- If there's a delay in your ability to respond or make requested changes, leave a comment explaining the situation.
|
||||
|
||||
### 6.8 Merging and Closing
|
||||
|
||||
- Once your pull request is approved, a maintainer will merge it into the main project.
|
||||
- After merging, you can delete your branch from your fork if you won't be using it anymore.
|
||||
- Celebrate your contribution to the project!
|
||||
|
||||
## 7. Pull Request Reviews
|
||||
|
||||
### 7.1 Review Process Overview
|
||||
|
||||
- All pull requests require at least one approved review before merging.
|
||||
- Reviews are primarily conducted by Naomi, but some projects may have additional reviewers.
|
||||
- The review process helps maintain code quality, consistency, and project standards.
|
||||
|
||||
### 7.2 What Reviewers Look For
|
||||
|
||||
Reviewers typically assess the following aspects:
|
||||
|
||||
1. Code quality and style adherence
|
||||
2. Functionality and correctness of the implementation
|
||||
3. Test coverage and passing status
|
||||
4. Documentation updates (if applicable)
|
||||
5. Adherence to project-specific guidelines
|
||||
6. Potential impact on existing features or performance
|
||||
|
||||
### 7.3 Types of Review Outcomes
|
||||
|
||||
1. **Approved**: Your pull request is ready to be merged.
|
||||
2. **Changes Requested**: Modifications or additional information is needed before approval.
|
||||
3. **Commented**: The reviewer has provided feedback but hasn't explicitly approved or requested changes.
|
||||
|
||||
### 7.4 Responding to Review Feedback
|
||||
|
||||
If changes are requested:
|
||||
|
||||
1. Read all comments carefully to understand the requested modifications.
|
||||
2. Ask for clarification if any feedback is unclear.
|
||||
3. Make the necessary changes in your local branch.
|
||||
4. Commit and push the changes to update your pull request.
|
||||
5. Respond to each comment, explaining how you addressed the feedback or why you chose a different approach.
|
||||
|
||||
### 7.5 Best Practices for Handling Reviews
|
||||
|
||||
- Respond promptly to review comments (ideally within a few days).
|
||||
- Be open to constructive criticism and willing to make changes.
|
||||
- If you disagree with a suggestion, explain your reasoning politely and be open to discussion.
|
||||
- Use the review process as a learning opportunity to improve your coding skills.
|
||||
|
||||
### 7.6 Timelines and Expectations
|
||||
|
||||
- We strive to review pull requests as quickly as possible, typically within a week.
|
||||
- If your pull request requires changes, please address them promptly.
|
||||
- Pull requests with outstanding change requests and no activity for a week may be closed as stale.
|
||||
- If you need more time to address changes, communicate this in the pull request comments to prevent your contribution from being closed.
|
||||
|
||||
### 7.7 Multiple Iterations
|
||||
|
||||
- Complex changes may require multiple rounds of reviews and revisions.
|
||||
- Stay engaged throughout the process and be patient if additional iterations are needed.
|
||||
|
||||
### 7.8 Learning from the Review Process
|
||||
|
||||
- Take note of common feedback to improve future contributions.
|
||||
- Consider reviewing other pull requests to gain insights into the project's standards and practices.
|
||||
|
||||
### 7.9 After Approval
|
||||
|
||||
Once your pull request is approved:
|
||||
|
||||
1. It will be merged into the main branch by a project maintainer.
|
||||
2. Depending on the project's deployment pipeline, your changes may be deployed immediately or as part of the next release cycle.
|
||||
|
||||
Thank you for providing that section. I'll expand and improve it to make it more comprehensive and encourage a wider range of contributions. Here's an enhanced version:
|
||||
|
||||
## 8. Other Contributions
|
||||
|
||||
We value all types of contributions, not just code. There are many ways to contribute to our project, regardless of your technical experience or comfort level with the codebase. Here are several ways you can make a meaningful impact:
|
||||
|
||||
### 8.1 Documentation Updates
|
||||
|
||||
Clear and accurate documentation is crucial for any project. You can help by:
|
||||
|
||||
- Fixing typos, grammatical errors, or unclear phrasing
|
||||
- Adding examples or clarifying existing explanations
|
||||
- Creating new documentation for undocumented features
|
||||
- Improving README files, API documentation, or user guides
|
||||
|
||||
### 8.2 Feature Requests
|
||||
|
||||
Your ideas can help shape the future of the project. To suggest a new feature:
|
||||
|
||||
1. Check existing issues to ensure your idea hasn't been proposed
|
||||
1. Clearly describe the feature and its potential benefits
|
||||
1. If possible, outline how the feature might be implemented
|
||||
|
||||
:::tip[Before you start:]
|
||||
Consider discussing your idea in our community chat before creating an issue to gather initial feedback.
|
||||
:::
|
||||
|
||||
### 8.3 Bug Reports
|
||||
|
||||
Identifying and reporting bugs is a valuable contribution. When reporting a bug:
|
||||
|
||||
1. Search existing issues to avoid duplicates
|
||||
1. Provide a clear, concise description of the problem
|
||||
1. Include steps to reproduce the bug
|
||||
1. Describe the expected behavior and what actually happened
|
||||
1. If possible, include screenshots, error messages, or code samples
|
||||
|
||||
### 8.4 User Support
|
||||
|
||||
Helping other users is a great way to contribute to the community:
|
||||
|
||||
- Answer questions in our Discord server or other community platforms
|
||||
- Share your knowledge and experiences with the project
|
||||
- Guide new users through common issues or setup processes
|
||||
- Create tutorials or blog posts about using the project
|
||||
|
||||
### 8.5 Design Contributions
|
||||
|
||||
If you have design skills, you can contribute by:
|
||||
|
||||
- Creating or improving project logos or icons
|
||||
- Designing user interface mockups for new features
|
||||
- Improving the overall user experience and accessibility
|
||||
- Creating infographics or visual aids for documentation
|
||||
|
||||
### 8.6 Testing and Quality Assurance
|
||||
|
||||
Help improve the project's stability by:
|
||||
|
||||
- Testing new features or bug fixes
|
||||
- Performing usability testing and providing feedback
|
||||
- Writing or improving automated tests
|
||||
- Identifying edge cases or potential security issues
|
||||
|
||||
### 8.7 Community Building
|
||||
|
||||
Foster a welcoming and inclusive community by:
|
||||
|
||||
- Welcoming new contributors and helping them get started
|
||||
- Organizing or participating in community events or meetups
|
||||
- Promoting the project on social media or relevant forums
|
||||
- Helping to moderate community discussions
|
||||
|
||||
### 8.8 Internationalization and Localization
|
||||
|
||||
Make the project accessible to a global audience:
|
||||
|
||||
- Translate user interfaces
|
||||
- Provide localized documentation
|
||||
- Ensure the project supports multiple languages and cultures
|
||||
|
||||
### 8.9 Code Reviews
|
||||
|
||||
Even if you're not comfortable making code changes, you can:
|
||||
|
||||
- Review pull requests for documentation or small changes
|
||||
- Provide feedback on proposed features or bug fixes
|
||||
- Help ensure code style and convention consistency
|
||||
|
||||
### 8.10 Fundraising and Sponsorship
|
||||
|
||||
If you have connections or experience in this area:
|
||||
|
||||
- Help identify potential sponsors or grants
|
||||
- Assist with writing grant applications
|
||||
- Organize fundraising events or campaigns
|
||||
|
||||
Or even make a donation yourself!
|
||||
|
||||
### 8.11 Mentoring
|
||||
|
||||
Share your knowledge and experience:
|
||||
|
||||
- Mentor new contributors
|
||||
- Create learning resources for the project
|
||||
- Participate in or organize coding workshops related to the project
|
||||
|
||||
Remember, all contributions, big or small, are valuable to the project. Don't hesitate to get involved in any way you feel comfortable. If you have any questions about how to contribute or need help getting started, please reach out to us in our Discord server or through the project's communication channels.
|
||||
@ -1,42 +0,0 @@
|
||||
---
|
||||
title: nhcarrigan Contributor Covenant
|
||||
---
|
||||
|
||||
Copyright (C) 2024 nhcarrigan and its contributors.
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies of this
|
||||
license document, but changing it is not allowed.
|
||||
|
||||
## nhcarrigan Contributor Covenant 1.0
|
||||
|
||||
By making a contribution to this project I certify that:
|
||||
|
||||
<ol type="a">
|
||||
<li>
|
||||
I have read, understood, and agree to abide by the project's Code of Conduct in its entirety.
|
||||
</li>
|
||||
<li>
|
||||
My contribution and participation align with the principles outlined in the Code of Conduct, including respect for all community members regardless of their identity or background.
|
||||
</li>
|
||||
<li>
|
||||
I have the right to submit any code, documentation, or other content under the project's designated license.
|
||||
</li>
|
||||
<li>
|
||||
If my contribution is based on previous work covered under an open source license, I have the right to submit that work with modifications under the project's license.
|
||||
</li>
|
||||
<li>
|
||||
Any contribution provided to me by another person for submission to this project has been done so with certification of points <code>a</code> through <code>d</code>, and I have not modified it.
|
||||
</li>
|
||||
<li>
|
||||
I understand that my contributions may be logged publicly, and that moderation actions taken in response to Code of Conduct violations may be recorded in the community's public moderation log.
|
||||
</li>
|
||||
<li>
|
||||
I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.
|
||||
</li>
|
||||
<li>
|
||||
I acknowledge that community leaders have the right and responsibility to remove, edit, or reject my contributions if they do not align with this certificate or the project's Code of Conduct.
|
||||
</li>
|
||||
<li>
|
||||
I agree to release my contribution to nhcarrigan pursuant to the Terms of Service.
|
||||
</li>
|
||||
</ol>
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,10 +0,0 @@
|
||||
---
|
||||
title: Security Hall of Fame
|
||||
---
|
||||
|
||||
## 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:
|
||||
@ -1,448 +0,0 @@
|
||||
---
|
||||
title: Labels
|
||||
---
|
||||
|
||||
We use very specific labels to help categorise our issues. This page explains what each label means.
|
||||
|
||||
## 1. Contribution Labels
|
||||
|
||||
These are the most important. These labels indicate who is encouraged to make a pull request to resolve the issue.
|
||||
|
||||
### 1.1. `good first issue`
|
||||
|
||||
#### 1.1.1. Purpose
|
||||
|
||||
Identifies issues suitable for contributors who are new to the project.
|
||||
|
||||
#### 1.1.2. Characteristics
|
||||
|
||||
Does not require prior knowledge of the codebase. Issues with this label should include a detailed description of the implementation process.
|
||||
|
||||
#### 1.1.3. Expectations
|
||||
|
||||
Contributors are responsible for ensuring their work complies with the project's licensing terms and contribution guidelines.
|
||||
|
||||
### 1.2. `help wanted`
|
||||
|
||||
#### 1.2.1. Purpose
|
||||
|
||||
Indicates issues open for contribution from any interested party.
|
||||
|
||||
#### 1.2.2. Characteristics
|
||||
|
||||
Typically assumes prior experience with the codebase. As such, issues may not include a detailed implementation description.
|
||||
|
||||
#### 1.2.3. Expectations
|
||||
|
||||
Contributors should review and adhere to the project's contribution guidelines and code of conduct before submitting work on these issues.
|
||||
|
||||
### 1.3. `🔒 staff only`
|
||||
|
||||
#### 1.3.1. Purpose
|
||||
|
||||
Designates issues restricted to project maintainers or staff due to specific access requirements.
|
||||
|
||||
#### 1.3.2. Characteristics
|
||||
|
||||
Requires access to production infrastructure for proper testing and implementation. As such, limited to authorised project maintainers and staff.
|
||||
|
||||
#### 1.3.3. Expectations
|
||||
|
||||
Staff members working on these issues must adhere to all relevant confidentiality agreements, data protection policies, and internal security protocols.
|
||||
|
||||
### 1.4 Disclaimer
|
||||
|
||||
Labels are assigned based on the project maintainers' best judgment but may not guarantee the exact level of difficulty or access requirements for every contributor. Contributors should use their discretion and communicate with project maintainers if they have any doubts about their ability to address an issue or comply with any associated legal requirements.
|
||||
|
||||
## 2. Aspect Labels
|
||||
|
||||
These labels indicate the scope of the work required to resolve the issue.
|
||||
|
||||
### 2.1. `💻 aspect: code`
|
||||
|
||||
#### 2.1.1. Purpose
|
||||
|
||||
Identifies issues requiring changes to the project's codebase.
|
||||
|
||||
#### 2.1.2. Characteristics
|
||||
|
||||
Involves direct modification to the project's source code. Familiarity with the languages and libraries used is expected.
|
||||
|
||||
#### 2.1.3. Expectations
|
||||
|
||||
Contributors must ensure their code changes comply with the project's coding standards, license terms, and any applicable software patents or copyrights.
|
||||
|
||||
### 2.2. `🤖 aspect: dx`
|
||||
|
||||
#### 2.2.1. Purpose
|
||||
|
||||
Indicates issues related to improving the project's tooling and development workflow.
|
||||
|
||||
#### 2.2.2. Characteristics
|
||||
|
||||
May include changes to automated tests, development dependencies, build processes, etc. Understanding of the development workflows is expected.
|
||||
|
||||
#### 2.2.3. Expectations
|
||||
|
||||
Changes to tooling or dependencies must be compatible with the project's overall licensing strategy and not introduce conflicts with existing terms.
|
||||
|
||||
### 2.3. `🕹 aspect: interface`
|
||||
|
||||
#### 2.3.1. Purpose
|
||||
|
||||
Designates issues that affect the end-user's experience with the project.
|
||||
|
||||
#### 2.3.2. Characteristics
|
||||
|
||||
May require changes in the code, particularly in front-end components. Can include visual modifications like CSS changes or image updates. Understanding of the end-user experience expected.
|
||||
|
||||
#### 2.3.3. Expectations
|
||||
|
||||
Contributors must ensure they have the necessary rights to any visual assets introduced or modified. Changes should comply with accessibility standards and regulations where applicable.
|
||||
|
||||
### 2.4. `📄 aspect: text`
|
||||
|
||||
#### 2.4.1. Purpose
|
||||
|
||||
Identifies issues related to the project's documentation.
|
||||
|
||||
#### 2.4.2. Characteristics
|
||||
|
||||
Typically does not require code changes. Proficiency in technical writing is a must.
|
||||
|
||||
#### 2.4.3. Expectations
|
||||
|
||||
Contributors must ensure the accuracy of the information provided in documentation updates. Documentation changes should adhere to any applicable style guides and licensing terms.
|
||||
|
||||
### 2.5 Disclaimer
|
||||
|
||||
Aspect labels are assigned based on the primary focus of the issue but may not encompass all potential areas of impact. Contributors are encouraged to consider potential cross-aspect effects of their work and discuss these with project maintainers when in doubt. The project maintainers reserve the right to reassign aspect labels or request additional changes if the submitted work does not align with the intended scope of the issue.
|
||||
|
||||
## 3. Goal Labels
|
||||
|
||||
These labels indicate the primary objective of the issue, reflecting our project's modular approach. They help contributors understand the nature and scope of the changes they'll be making.
|
||||
|
||||
### 3.1. `⭐ goal: addition`
|
||||
|
||||
#### 3.1.1. Purpose
|
||||
|
||||
Identifies issues that involve adding a new feature to the project.
|
||||
|
||||
#### 3.1.2. Characteristics
|
||||
|
||||
Typically involves creating new code files. Understanding of how different modules in the project integrate with each other is expected.
|
||||
|
||||
#### 3.1.3. Expectations
|
||||
|
||||
Contributors must ensure that new features do not infringe on existing patents or copyrights. New code should be compatible with the project's existing license. If introducing third-party libraries or dependencies, their licenses must be compatible with the project's license.
|
||||
|
||||
### 3.2. `🛠 goal: fix`
|
||||
|
||||
#### 3.2.1. Purpose
|
||||
|
||||
Designates issues aimed at fixing bugs in the project.
|
||||
|
||||
#### 3.2.2. Characteristics
|
||||
|
||||
Typically involves editing code within existing files. Scope should be kept to the specific bug - separate contributions should be made for unrelated bugs.
|
||||
|
||||
#### 3.2.3. Expectations
|
||||
|
||||
Bug fixes should not introduce new legal issues or licensing conflicts. Contributors should document the nature of the bug and the fix for future reference and potential legal compliance (e.g., security vulnerabilities).
|
||||
|
||||
### 3.3. `✨ goal: improvement`
|
||||
|
||||
#### 3.3.1. Purpose
|
||||
|
||||
Indicates issues that expand upon or enhance existing features.
|
||||
|
||||
#### 3.3.2. Characteristics
|
||||
|
||||
Usually involves adding code to existing files. Scope should be kept to the existing feature.
|
||||
|
||||
#### 3.3.3. Expectations
|
||||
|
||||
Improvements should maintain compatibility with existing licenses and legal obligations. If the improvement significantly changes the functionality, consider if additional legal reviews or updates to user agreements are necessary.
|
||||
|
||||
### 3.4. Disclaimer
|
||||
|
||||
While goal labels provide guidance on the nature of the task, the actual work required may vary or expand beyond the initial scope. Contributors are encouraged to communicate with project maintainers if they believe a different approach or additional changes are necessary to achieve the goal. The project maintainers reserve the right to request modifications or additional work to ensure that contributions align with the project's goals, standards, and legal requirements.
|
||||
|
||||
## 4. Priority Labels
|
||||
|
||||
Priority labels indicate the importance assigned to specific issues by the project maintainers. These labels help guide resource allocation and set expectations for resolution timeframes.
|
||||
|
||||
### 4.1. `🟥 priority: critical`
|
||||
|
||||
#### 4.1.1. Purpose
|
||||
|
||||
Identifies issues requiring immediate attention due to their severe impact on project usability.
|
||||
|
||||
#### 4.1.2. Characteristics
|
||||
|
||||
Require urgent resolution to restore project functionality. Experience with the project is a must, to avoid delays from long review processes.
|
||||
|
||||
#### 4.1.3. Expectations
|
||||
|
||||
May involve security vulnerabilities or critical bugs that could lead to legal liabilities if not addressed promptly. Resolution of these issues may need to be reported to relevant stakeholders or authorities in certain cases (e.g., data protection regulators for security breaches).
|
||||
|
||||
### 4.2. `🟧 priority: high`
|
||||
|
||||
#### 4.2.1. Purpose
|
||||
|
||||
Designates important issues that, while not preventing basic functionality, are impeding further development.
|
||||
|
||||
#### 4.2.2. Characteristics
|
||||
|
||||
Not critical for current project operation but blocking future progress. Require prompt attention to unblock development efforts.
|
||||
|
||||
#### 4.2.3. Expectations
|
||||
|
||||
May involve compliance deadlines or contractual obligations that need to be met. Could impact project timelines, potentially affecting agreements with stakeholders or clients.
|
||||
|
||||
### 4.3. `🟨 priority: medium`
|
||||
|
||||
#### 4.3.1. Purpose
|
||||
|
||||
Indicates issues that need resolution as soon as possible but are not blocking other development.
|
||||
|
||||
#### 4.3.2. Characteristics
|
||||
|
||||
Important for project improvement but not critical for current functionality. Should be addressed in a timely manner but with less urgency than high-priority issues.
|
||||
|
||||
#### 4.3.3. Expectations
|
||||
|
||||
May involve improvements to user experience or accessibility, which could have legal implications if neglected long-term. Could relate to optimizations that affect performance guarantees or service level agreements.
|
||||
|
||||
### 4.4. `🟩 priority: low`
|
||||
|
||||
#### 4.4.1. Purpose
|
||||
|
||||
Represents issues that should be resolved but are not considered urgent.
|
||||
|
||||
#### 4.4.2. Characteristics
|
||||
|
||||
Desirable improvements or minor issues that don't significantly impact project functionality.
|
||||
|
||||
#### 4.4.3. Expectations
|
||||
|
||||
While not urgent, neglecting these issues over time could lead to technical debt or gradual degradation of project quality, potentially affecting long-term compliance or user satisfaction.
|
||||
|
||||
### 4.5. `🟪 priority: none`
|
||||
|
||||
#### 4.5.1. Purpose
|
||||
|
||||
Identifies "nice-to-have" issues that are not essential for project functionality or immediate development goals.
|
||||
|
||||
#### 4.5.2. Characteristics
|
||||
|
||||
Not critical enough to dedicate maintainer time for resolution. Often left for community contributors or future consideration.
|
||||
|
||||
#### 4.5.3. Expectations
|
||||
|
||||
While not prioritized, maintainers should periodically review these issues to ensure they haven't become more significant over time, potentially accruing legal or compliance risks.
|
||||
|
||||
### 4.6 Disclaimer
|
||||
|
||||
Priority labels reflect the project maintainers' current assessment and may be subject to change. The presence of a lower-priority label does not diminish the importance of the issue or the value of contributions addressing it. Contributors should communicate with maintainers if they believe an issue's priority should be reassessed due to new information or changing circumstances.
|
||||
|
||||
## 5. Status Labels
|
||||
|
||||
Status labels indicate the current stage of an issue in the project lifecycle. These labels help manage workflow and set expectations for contributors and users.
|
||||
|
||||
### 5.1. `🚦 status: awaiting triage`
|
||||
|
||||
#### 5.1.1. Purpose
|
||||
|
||||
Identifies newly created issues that have not yet been reviewed by the maintainer team.
|
||||
|
||||
#### 5.1.2. Characteristics
|
||||
|
||||
Should be applied to issues when they are opened.
|
||||
|
||||
#### 5.1.3. Expectations
|
||||
|
||||
Contributors should be aware that engaging with these issues is at their own discretion, as the project team has not yet evaluated them. Maintainers should establish a reasonable timeframe for initial triage to manage expectations and potential liability.
|
||||
|
||||
### 5.2. `🚧 status: blocked`
|
||||
|
||||
#### 5.2.1. Purpose
|
||||
|
||||
Indicates issues with a planned resolution that depend on the completion of another issue.
|
||||
|
||||
#### 5.2.2. Characteristics
|
||||
|
||||
Not yet ready for work but expected to be addressed in the future.
|
||||
#### 5.2.3. Expectations
|
||||
|
||||
Maintainers should clearly document dependencies to avoid potential conflicts or misunderstandings. Regular review of blocked issues is advisable to prevent indefinite delays that could impact project timelines or contractual obligations.
|
||||
|
||||
### 5.3. `⛔️ status: discarded`
|
||||
|
||||
#### 5.3.1. Purpose
|
||||
|
||||
Designates issues that the project team does not intend to resolve.
|
||||
|
||||
#### 5.3.2. Characteristics
|
||||
|
||||
Typically applied to feature requests that don't align with project goals.
|
||||
|
||||
#### 5.3.3. Expectations
|
||||
|
||||
Clearly communicate the rationale for discarding issues to manage user expectations and maintain transparency. Ensure that discarded issues don't conflict with any promised features or contractual obligations.
|
||||
|
||||
### 5.4. `🙅 status: discontinued`
|
||||
|
||||
#### 5.4.1. Purpose
|
||||
|
||||
Applies to feature requests for projects in maintenance mode.
|
||||
|
||||
#### 5.4.2. Characteristics
|
||||
|
||||
Indicates no new features will be added, but bug fixes and support continue.
|
||||
|
||||
#### 5.4.3. Expectations
|
||||
|
||||
Clearly communicate the project's maintenance status to manage user expectations and potential liability. Ensure that discontinuation doesn't breach any ongoing support agreements or licenses.
|
||||
|
||||
### 5.5. `🏷 status: label work required`
|
||||
|
||||
#### 5.5.1. Purpose
|
||||
|
||||
Indicates issues that need proper labeling and categorization.
|
||||
|
||||
#### 5.5.2. Characteristics
|
||||
|
||||
May have ongoing discussions but lack appropriate classification.
|
||||
|
||||
#### 5.5.3. Expectations
|
||||
|
||||
Proper labeling is crucial for efficient project management and may have implications for compliance tracking and reporting. Establish clear guidelines for labeling to ensure consistency and avoid potential misunderstandings.
|
||||
|
||||
### 5.6. `🏁 status: ready for dev`
|
||||
|
||||
#### 5.6.1. Purpose
|
||||
|
||||
Signifies issues that are ready for contribution.
|
||||
|
||||
#### 5.6.2. Characteristics
|
||||
|
||||
May have an assigned contributor who has expressed interest.
|
||||
|
||||
#### 5.6.3. Expectations
|
||||
|
||||
Clearly communicate contribution guidelines and any legal requirements (e.g., Contributor Covenant) to potential contributors. Ensure that collaborative efforts are managed in compliance with project licenses and contributor agreements.
|
||||
|
||||
### 5.7. `🧹 status: ticket work required`
|
||||
|
||||
#### 5.7.1. Purpose
|
||||
|
||||
Indicates issues lacking sufficient information for proper triage.
|
||||
|
||||
#### 5.7.2. Characteristics
|
||||
|
||||
Often paired with Conversation Labels for further clarification.
|
||||
|
||||
#### 5.7.3. Expectations
|
||||
|
||||
Establish clear guidelines for required information to avoid potential misunderstandings or misdirected efforts. Be mindful of data privacy when requesting additional information from issue reporters.
|
||||
|
||||
### 5.8. Disclaimer
|
||||
|
||||
Status labels reflect the current assessment of the project team and may change as circumstances evolve. While the project team strives to maintain accurate status labels, contributors and users should communicate with maintainers if they notice any discrepancies or have questions about an issue's status.
|
||||
|
||||
## 6. Conversation Labels
|
||||
|
||||
Conversation labels indicate that an issue has received initial maintainer attention but requires further discussion or information before proceeding. These labels help manage communication and ensure all necessary information is gathered before taking action.
|
||||
|
||||
### 6.1. `💬 talk: discussion`
|
||||
|
||||
#### 6.1.1. Purpose
|
||||
|
||||
Identifies issues that are under active discussion but have not yet been accepted for resolution.
|
||||
|
||||
#### 6.1.2. Characteristics
|
||||
|
||||
Ongoing dialogue between maintainers, contributors, and/or users. May involve debates about feature requests, implementation strategies, or project direction.
|
||||
|
||||
#### 6.1.3. Expectations
|
||||
|
||||
Ensure discussions remain constructive and adhere to the project's code of conduct. Be cautious about making commitments or promises during discussions that could create legal obligations. Document key decisions and rationales to maintain transparency and provide a record for future reference.
|
||||
|
||||
### 6.2. `❓ talk: question`
|
||||
|
||||
#### 6.2.1. Purpose
|
||||
|
||||
Indicates issues waiting on additional information from the author for proper triage.
|
||||
|
||||
#### 6.2.2. Characteristics
|
||||
|
||||
Requires clarification or more details from the issue creator. Cannot proceed with triage or resolution until the requested information is provided.
|
||||
|
||||
#### 6.2.3. Expectations
|
||||
|
||||
Clearly communicate what information is needed and why it's necessary. Be mindful of data privacy when requesting additional information. Establish and communicate timeframes for expected responses to manage the issue lifecycle efficiently.
|
||||
|
||||
### 6.3. Disclaimer
|
||||
|
||||
Conversation labels indicate ongoing dialogue and do not guarantee that an issue will be implemented or resolved in a specific manner. Participants should understand that project priorities and decisions may change based on new information or project direction.
|
||||
|
||||
## 7. Pull Request Labels
|
||||
|
||||
Pull Request (PR) labels are used to indicate the current status of pull requests and guide contributors through the review and merge process.
|
||||
|
||||
### 7.1. `⚠️ pull: merge conflict`
|
||||
|
||||
#### 7.1.1. Purpose
|
||||
|
||||
Indicates that the pull request has conflicts with the target branch.
|
||||
|
||||
#### 7.1.2. Characteristics
|
||||
|
||||
Conflicts need to be resolved before the PR can be reviewed or merged. May require action from the original contributor or project maintainers.
|
||||
|
||||
#### 7.1.3. Expectations
|
||||
|
||||
Clearly communicate the responsibility for resolving conflicts (e.g., whether it's the contributor's or maintainer's role). Ensure that conflict resolution doesn't introduce unintended changes or legal issues (e.g., license conflicts).
|
||||
|
||||
### 7.2. `🔍 pull: ready for review`
|
||||
|
||||
#### 7.2.1. Purpose
|
||||
|
||||
Signifies that the pull request is not in draft mode and is awaiting maintainer review.
|
||||
|
||||
#### 7.2.2. Characteristics
|
||||
|
||||
PR has been submitted as complete and ready for evaluation. Maintainers should prioritize reviewing these PRs.
|
||||
|
||||
#### 7.2.3. Expectations
|
||||
|
||||
Ensure contributors understand that "ready for review" doesn't guarantee acceptance or merging. Maintain clear review criteria and communicate them to contributors.
|
||||
|
||||
### 7.3. `⏫ pull: requires update`
|
||||
|
||||
#### 7.3.1. Purpose
|
||||
|
||||
Indicates that the maintainer team has requested changes to the pull request.
|
||||
|
||||
#### 7.3.2. Characteristics
|
||||
|
||||
Feedback has been provided, and updates are needed before further review or merging. Requires action from the contributor to address the requested changes.
|
||||
|
||||
#### 7.3.3. Expectations
|
||||
|
||||
Clearly document requested changes to maintain transparency and avoid misunderstandings. Consider setting timeframes for updates to manage the PR lifecycle effectively.
|
||||
|
||||
### 7.4. Disclaimer
|
||||
|
||||
The presence of these labels does not guarantee that a pull request will be merged. All contributions must still meet the project's quality standards, guidelines, and legal requirements.
|
||||
|
||||
## 8. Continuous Improvement
|
||||
|
||||
We encourage all project participants to provide feedback on our labeling system. If you have suggestions for improvements or notice any inconsistencies, please reach out to us in our [chat server](https://chat.nhcarrigan.com).
|
||||
|
||||
## 9. Legal Notice
|
||||
|
||||
This labels documentation is provided for informational purposes and to facilitate project management. It does not constitute a legal agreement. All contributions to the project must comply with the project's license, contributor agreement (if applicable), and relevant laws and regulations.
|
||||
|
||||
By using these labels and participating in the project, you agree to abide by the project's code of conduct and contribution guidelines.
|
||||
@ -1,355 +0,0 @@
|
||||
---
|
||||
title: Server Setup
|
||||
---
|
||||
|
||||
This document outlines how we set up our remote servers for running projects.
|
||||
|
||||
## 1. Provision a Server
|
||||
|
||||
We use DigitalOcean as our provider. Regardless of your choice, provision a new VPS using the **latest Ubuntu LTS version**. Add your `ssh` key AND Naomi's `ssh` key in the setup process.
|
||||
|
||||
## 2. Set Up User
|
||||
|
||||
You should never run applications on root. SSH into the new VPS to prepare your user.
|
||||
|
||||
### 2.1. Creating the User
|
||||
|
||||
You'll need to set a password for the `root` account first.
|
||||
|
||||
```bash
|
||||
passwd
|
||||
```
|
||||
|
||||
Once you have set a password, ensure that you have provided it to Naomi to store in the vault.
|
||||
|
||||
Create an `nhcarrigan` user for our organisation.
|
||||
|
||||
```bash
|
||||
adduser nhcarrigan
|
||||
```
|
||||
|
||||
Set a **different** password, and provide that to Naomi as well. For all of the user information, use the default blank values.
|
||||
|
||||
Add the new user to the sudoers file.
|
||||
|
||||
```bash
|
||||
usermod -aG sudo nhcarrigan
|
||||
```
|
||||
|
||||
Then sync the SSH keys so we can authenticate as that user.
|
||||
|
||||
```bash
|
||||
rsync --archive --chown=nhcarrigan:nhcarrigan ~/.ssh /home/nhcarrigan
|
||||
```
|
||||
|
||||
While you are there, set the timezone for the server to our business' local timezone.
|
||||
|
||||
```bash
|
||||
sudo timedatectl set-timezone America/Los_Angeles
|
||||
```
|
||||
|
||||
## 3. Preparing For Web Requests
|
||||
|
||||
To prepare the server to receive web requests, you'll need to follow a few steps.
|
||||
|
||||
### 3.1. SSL Certificate
|
||||
|
||||
:::note
|
||||
If the Firewall has been set up, you'll need to temporarily allow port 80 for the certificate to generate.
|
||||
:::
|
||||
|
||||
We use LetsEncrypt to provision our SSL certificates. If it is not installed, install it with:
|
||||
|
||||
```bash
|
||||
sudo snap install --classic certbot
|
||||
```
|
||||
|
||||
Then link the snap to our `usr` directory.
|
||||
|
||||
```bash
|
||||
sudo ln -s /snap/bin/certbot /usr/bin/certbot
|
||||
```
|
||||
|
||||
Generate a certificate with:
|
||||
|
||||
```bash
|
||||
sudo certbot certonly --standalone
|
||||
```
|
||||
|
||||
And allow applications to read it:
|
||||
|
||||
```bash
|
||||
sudo chmod -R a+rwx /etc/letsencrypt
|
||||
```
|
||||
|
||||
When you need to renew the certificate:
|
||||
|
||||
```bash
|
||||
sudo certbot renew
|
||||
```
|
||||
|
||||
### 3.2. NGINX
|
||||
|
||||
All requests should be routed through NGINX. At no point should an application run directly on ports 80 or 443.
|
||||
|
||||
Install NGINX:
|
||||
|
||||
```bash
|
||||
sudo apt-get install nginx
|
||||
```
|
||||
|
||||
Edit the configuration file:
|
||||
|
||||
```bash
|
||||
sudo emacs /etc/nginx/conf.d/server.conf
|
||||
```
|
||||
|
||||
Use this template to set up a reverse proxy on the standard HTTPS port 443:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name subdomain.domain.tld;
|
||||
ssl_certificate /etc/letsencrypt/live/subdomain.domain.tld/fullchain.pem;
|
||||
ssl_certificate_key /etc/letsencrypt/live/subdomain.domain.tld/privkey.pem;
|
||||
|
||||
location / {
|
||||
proxy_set_header Host $host;
|
||||
proxy_pass https://127.0.0.1:port;
|
||||
proxy_redirect off;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Validate that the config is correct with:
|
||||
|
||||
```bash
|
||||
sudo nginx -t
|
||||
```
|
||||
|
||||
If so, restart NGINX to apply the changes:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart nginx
|
||||
```
|
||||
|
||||
## 4. Securing the Server
|
||||
|
||||
We have a minimum level of security that is required on ALL of our servers. This section should not be treated as the best effort, but as the minimal requirements to comply with our policies.
|
||||
|
||||
### 4.1. Firewall
|
||||
|
||||
We use `ufw` as our firewall. First, enable the SSH port.
|
||||
|
||||
```bash
|
||||
sudo ufw allow "OpenSSH"
|
||||
```
|
||||
|
||||
Then, allow the standard HTTPS port and **deny** the standard HTTP port.
|
||||
|
||||
```bash
|
||||
sudo ufw deny http
|
||||
sudo ufw allow https
|
||||
```
|
||||
|
||||
Enable the firewall. You may get dropped from the SSH connection.
|
||||
|
||||
```bash
|
||||
sudo ufw enable
|
||||
```
|
||||
|
||||
### 4.2. Fail2Ban
|
||||
|
||||
We also use Fail2Ban to block IP addresses which fail to make requests too often.
|
||||
|
||||
Install the tool:
|
||||
|
||||
```bash
|
||||
sudo apt-get install fail2ban
|
||||
```
|
||||
|
||||
Configure the NGINX jail in `/etc/fail2ban/jail.d/nginx-auth.conf`:
|
||||
|
||||
```ini
|
||||
[nginx-auth]
|
||||
enabled = true
|
||||
filter = nginx-auth
|
||||
logpath = /var/log/nginx/access.log
|
||||
maxretry = 3
|
||||
findtime = 86400
|
||||
bantime = 86400
|
||||
```
|
||||
|
||||
Configure the NGINX filter in `/etc/fail2ban/filter.d/nginx-auth.conf`:
|
||||
|
||||
```ini
|
||||
[Definition]
|
||||
failregex = ^<HOST> - .* \[.*\] ".*" (4\d{2}) .*$
|
||||
```
|
||||
|
||||
Because we use Cloudflare, you'll need to grab the original IP for all requests. Start by creating a file to store Cloudflare's IPs.
|
||||
|
||||
```bash
|
||||
sudo touch /etc/nginx/cloudflare_ips.conf
|
||||
```
|
||||
|
||||
Then create your script:
|
||||
|
||||
```bash
|
||||
nano ~/update_cf_ips.sh
|
||||
```
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Create a temporary file
|
||||
temp_file=$(mktemp)
|
||||
|
||||
# Download IPv4 ranges and format each line
|
||||
curl -s https://www.cloudflare.com/ips-v4 | while read ip; do
|
||||
echo "set_real_ip_from $ip;" >> "$temp_file"
|
||||
done
|
||||
|
||||
# Download IPv6 ranges and format each line
|
||||
curl -s https://www.cloudflare.com/ips-v6 | while read ip; do
|
||||
echo "set_real_ip_from $ip;" >> "$temp_file"
|
||||
done
|
||||
|
||||
# Add the real_ip_header directive
|
||||
echo "real_ip_header CF-Connecting-IP;" >> "$temp_file"
|
||||
|
||||
# Replace the old file with the new one
|
||||
sudo mv "$temp_file" /etc/nginx/cloudflare_ips.conf
|
||||
|
||||
# Test Nginx configuration
|
||||
sudo nginx -t
|
||||
|
||||
# If the test is successful, reload Nginx
|
||||
if [ $? -eq 0 ]; then
|
||||
sudo systemctl reload nginx
|
||||
echo "Nginx configuration updated and reloaded successfully."
|
||||
else
|
||||
echo "Nginx configuration test failed. Please check your configuration."
|
||||
fi
|
||||
```
|
||||
|
||||
Make it executable and run it:
|
||||
|
||||
```bash
|
||||
sudo chmod +x update_cf_ips.sh
|
||||
sudo ./update_cf_ips.sh
|
||||
```
|
||||
|
||||
If it runs as expected, set it up to run on a CRON.
|
||||
|
||||
```bash
|
||||
sudo crontab -e
|
||||
```
|
||||
|
||||
```bash
|
||||
0 3 * * 1 ~/update_cf_ips.sh
|
||||
```
|
||||
|
||||
Then, update the `/etc/nginx/nginx.conf` to use all of this new logic. This goes at the end of your `http` directive block.
|
||||
|
||||
```nginx
|
||||
# Look at the real IP, not the cloudflare IP.
|
||||
include /etc/nginx/cloudflare_ips.conf;
|
||||
|
||||
log_format custom_format '$remote_addr - $remote_user [$time_local] '
|
||||
'"$request" $status $body_bytes_sent '
|
||||
'"$http_referer" "$http_user_agent" '
|
||||
'"$http_x_forwarded_for"';
|
||||
|
||||
access_log /var/log/nginx/access.log custom_format;
|
||||
```
|
||||
|
||||
Confirm the NGINX configuration is correct:
|
||||
|
||||
```bash
|
||||
sudo nginx -t
|
||||
```
|
||||
|
||||
Then restart everything.
|
||||
|
||||
```bash
|
||||
sudo systemctl restart nginx
|
||||
sudo systemctl restart fail2ban
|
||||
```
|
||||
|
||||
To view banned IPs:
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client status nginx-auth
|
||||
```
|
||||
|
||||
And to unban them:
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client set nginx-auth unbanip <ip>
|
||||
```
|
||||
|
||||
## 5. Uploading a Project
|
||||
|
||||
To upload a project, you should **not** use `git` to clone the project to the machine. Instead, start by cloning the project to your local environment and navigating to the directory:
|
||||
|
||||
```bash
|
||||
git clone <url>
|
||||
cd /path/to/project
|
||||
```
|
||||
|
||||
Then sync the project up to the machine, ignoring any installed packages.
|
||||
|
||||
```bash
|
||||
rsync -av --exclude='node_modules' ./ <server name>:/home/nhcarrigan/<project directory>
|
||||
```
|
||||
|
||||
## 6. Running a Project
|
||||
|
||||
Now you are ready to start running the project.
|
||||
|
||||
### 6.1. Node.js
|
||||
|
||||
Most of our projects will run on Node. For a new machine, you'll need to set that up.
|
||||
|
||||
We use `nvm` to manage Node versions. Fetch and run the install script:
|
||||
|
||||
```bash
|
||||
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash
|
||||
```
|
||||
|
||||
The script will automatically update the `.bashrc` file to load `nvm` into the PATH. Reload that:
|
||||
|
||||
```bash
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
Install the long-term support Node version.
|
||||
|
||||
```bash
|
||||
nvm install --lts
|
||||
```
|
||||
|
||||
This should automatically set it as the default. When updating, be sure to remove any older versions!
|
||||
|
||||
Finally, install `pnpm` as the package manager.
|
||||
|
||||
```bash
|
||||
npm i -g pnpm
|
||||
```
|
||||
|
||||
### 6.2. PM2
|
||||
|
||||
All of our processes run with PM2 to allow for monitoring and auto-restarts. You'll need to install it.
|
||||
|
||||
```bash
|
||||
pnpm i -g pm2
|
||||
```
|
||||
|
||||
To start a project, use this template:
|
||||
|
||||
```bash
|
||||
pm2 start '<script>' --name '<name>'
|
||||
```
|
||||
|
||||
Then run `pm2 save` to save the application list.
|
||||
@ -1,595 +0,0 @@
|
||||
---
|
||||
title: Style Guide
|
||||
---
|
||||
|
||||
This document outlines the style guide that applies to all of our projects.
|
||||
|
||||
## 1. Global Conventions
|
||||
|
||||
These sections apply to all code in any of our projects.
|
||||
|
||||
### 1.1. Copyright Notice
|
||||
|
||||
All code files should begin with a comment section containing the copyright information:
|
||||
|
||||
```js
|
||||
/**
|
||||
* @copyright nhcarrigan
|
||||
* @license Naomi's Public License
|
||||
* @author Naomi Carrigan
|
||||
*/
|
||||
```
|
||||
|
||||
Note that `copyright` _must_ be assigned to `nhcarrigan`, and our `license` must be applied, but when checking in new code you may attribute yourself as the author, or add yourself to the list for existing code.
|
||||
|
||||
## 2. JavaScript Projects
|
||||
|
||||
The following sections apply to our JavaScript/TypeScript projects. Style conventions are enforced through our [custom ESLint package](/projects/eslint).
|
||||
|
||||
:::caution
|
||||
We do _not_ use Prettier in any of our projects. Instead, our linter package also handles code styling.
|
||||
|
||||
If you are using VSCode, you can add this to your `.vscode/settings.json` file in the project directory to enable auto-formatting on save.
|
||||
|
||||
```json
|
||||
{
|
||||
"editor.codeActionsOnSave": {
|
||||
"source.fixAll.eslint": "explicit"
|
||||
},
|
||||
"eslint.validate": ["typescript"]
|
||||
}
|
||||
```
|
||||
|
||||
Because of this, our style guide will not cover the formatting section of our linter package.
|
||||
:::
|
||||
|
||||
## 2.1. Main Rules
|
||||
|
||||
These rules apply to all TypeScript code, and will run on files in `src/**/*.ts`.
|
||||
|
||||
### 2.1.1. `eslint` Enforced Rules
|
||||
|
||||
- Setters must have a corresponding getter.
|
||||
- Array methods which return a value must return a value in the callback.
|
||||
- Arrow functions should always use curly braces.
|
||||
- Variables must be used within the scope they are defined.
|
||||
- Comments should always start with a capital letter.
|
||||
- Avoid overly complex functions.
|
||||
- `return` statements must either never return a value, or always return a value.
|
||||
- `if` statements and similar control blocks should always use curly braces.
|
||||
- Switch statements must always have a default case, and the default case must always come last.
|
||||
- Never use loose equality.
|
||||
- A `for` loops iteration direction must match the conditional bound.
|
||||
- Functions assigned to a property must match the name of the property.
|
||||
- With the exception of callback functions, all functions should be assigned a name.
|
||||
- When using the `function` keyword, prefer `function name()` declarations over `const name = function()` expressions.
|
||||
- Getters should always return a value.
|
||||
- Getters and setters should be grouped together.
|
||||
- You should never use logical assignment operators.
|
||||
- You should never have more than one class per file.
|
||||
- Logical blocks should not be nested more than five levels deep. Prefer extracting into separate functions.
|
||||
- Files should not have more than 300 lines. Prefer extracting into modular functions.
|
||||
- Functions should not have more than 50 lines. Prefer breaking down into smaller logic.
|
||||
- Callbacks should not be nested more than two levels.
|
||||
- Functions should not have more than 20 logical statements/branches.
|
||||
- Constructor names should begin with a capital letter.
|
||||
- Do not use the `alert` API.
|
||||
- Promise executor functions should not be async.
|
||||
- Do not use `await` within loops.
|
||||
- Do not use bitwise operators.
|
||||
- Do not use `arguments.caller` or `arguments.callee`.
|
||||
- Do not declare variables within switch case statements.
|
||||
- Do not reassign class definitions.
|
||||
- Do not compare with `-0`.
|
||||
- Do not perform assignments in conditions e.g. `if (name = "Naomi")`.
|
||||
- Do not use the `console` API, prefer our custom logger.
|
||||
- Avoid confusing operator combinations e.g. `a + b ?? c`.
|
||||
- Avoid constant conditions e.g. `if(false)` or `while(true)`.
|
||||
- Constructors should not return a value. They implicitly return the instance.
|
||||
- Do not use control characters `\x00` in regular expressions.
|
||||
- Do not use `debugger` statements.
|
||||
- Do not use `delete` on variables.
|
||||
- Do not start a regular expression with `=` (confusing with `/=` operator).
|
||||
- Functions should not have multiple parameters with the same name.
|
||||
- Classes should not have multiple members with the same name.
|
||||
- Objects should not have multiple keys with the same name.
|
||||
- If/else statements should not use the same condition.
|
||||
- Switch statements should not have duplicate case conditions.
|
||||
- Import statements should not have duplicate imports.
|
||||
- Prefer using early return over if/else.
|
||||
- Block statements should not be empty.
|
||||
- Character classes in regular expressions should not be empty.
|
||||
- Destructured values should not be empty.
|
||||
- Static class blocks should not be empty.
|
||||
- You should not use loose equality with `null`.
|
||||
- You should not use `eval`.
|
||||
- Do not reassign the error parameter in a catch block.
|
||||
- Do not extend native prototypes.
|
||||
- Do not call `bind` unnecessarily.
|
||||
- Do not cast to a boolean in conditions.
|
||||
- Do not use `continue` or `break` unnecessarily.
|
||||
- All case statements should have a break statement.
|
||||
- Do not reassign function declarations.
|
||||
- Do not reassign global values (e.g. `window`).
|
||||
- Do not use implicit coercion (e.g. `!!bool`, `+num`).
|
||||
- Do not declare global variables. All values should be scoped to a module.
|
||||
- Do not reassign to imported variables.
|
||||
- Do not declare functions in logical blocks.
|
||||
- Do not pass invalid regular expression strings to `RegExp()`.
|
||||
- Do not use `this` outside of classes.
|
||||
- Do not use unusual space characters.
|
||||
- Do not access `__iterator__`.
|
||||
- Do not use loop labels.
|
||||
- Do not create unnecessary blocks.
|
||||
- Do not nest `if` within `else`, use `else if`.
|
||||
- Do not use multi-code characters (such as emotes) within character classes.
|
||||
- Do not chain assignment operators.
|
||||
- Do not use `\` to create multi-line strings. Use concatenation or template strings.
|
||||
- `if` conditions should not be in the negative (e.g. `!bool`).
|
||||
- Do not nest ternary statements.
|
||||
- Do not use `new` outside of an assignment.
|
||||
- Do not use `new` with `BigInt` or `Symbol`.
|
||||
- Do not use `new` with `String`, `Number`, or `Boolean`.
|
||||
- Do not use octal escapes (e.g. `\8`, `\2`).
|
||||
- Do not call the `Math`, `JSON`, `Reflect`, `Atomics`, or `Intl` objects as functions or constructors.
|
||||
- Do not call `new Object()` without an argument.
|
||||
- Do not use octal literals e.g. `071`.
|
||||
- Do not reassign function parameters.
|
||||
- Do not use the `++` operator.
|
||||
- Do not use `return` in promise executors.
|
||||
- Do not use the `__proto__` property.
|
||||
- Prefer calling the Object prototype over builtins (e.g. `Object.prototype.hasOwnProperty.call(foo, "bar")` over `foo.hasOwnProperty("bar")`).
|
||||
- Do not use literal spaces in regular expressions, use the escape sequence `\s`.
|
||||
- Do not return assignment operations.
|
||||
- Do not use `javascript:void` URLs.
|
||||
- Do not assign a variable to itself.
|
||||
- Do not compare a variable with itself.
|
||||
- Do not use the comma operator to evaluate multiple expressions.
|
||||
- Setters should not return a value.
|
||||
- Do not allow sparse arrays.
|
||||
- Do not use `${foo}` template interpolation in regular strings.
|
||||
- Do not reference `this` before calling `super` in constructors that call `super`.
|
||||
- Do not reference variables that are not declared.
|
||||
- Do not initialise variables to `undefined`.
|
||||
- With the exception of trailing underscores for unused variables, do not use dangling underscores.
|
||||
- Do not insert line breaks in confusing locations, such as the middle of a variable assignment.
|
||||
- Do not use a variable in a loop condition that is not modified within the loop.
|
||||
- Do not use a ternary if a simpler approach exists.
|
||||
- There should be no unreachable code.
|
||||
- Do not use control statements in `finally` blocks.
|
||||
- You must use parentheses when negating `in` or `instanceOf`, e.g. `if (!(key in obj))`.
|
||||
- Do not use optional chaining where an undefined value is not allowed.
|
||||
- Do not declare private class members that are not consumed by the class.
|
||||
- Do not declare variables that are unused.
|
||||
- Avoid backreferences in regular expressions when they would match nothing.
|
||||
- Do not use `.call()` or `.apply()` unnecessarily.
|
||||
- `catch` statements should _handle_ an error, not turn around and throw the error.
|
||||
- Do not use computed-key syntax for literal keys e.g. `{["a"]: "b"}`.
|
||||
- Do not concatenate string literals without variables.
|
||||
- Do not escape characters unnecessarily.
|
||||
- Do not rename a reference to the same name e.g. `let { a: a } = b;`.
|
||||
- Do not use redundant `return` statements.
|
||||
- No use of the `var` keyword.
|
||||
- Do not merge `TODO` or `FIX` comments into the main branch.
|
||||
- Do not use the `with` statement.
|
||||
- An object must use either all long-form definitions `{a : a}` or all short-form definitions `{ a }`, but never a mix of the two `{ a, b: c}`.
|
||||
- Avoid shorthand operators `+=`, prefer the explicit `x = x + y`.
|
||||
- Callback functions should be anonymous arrow functions.
|
||||
- Use `const` for all variables that are not reassigned.
|
||||
- Capture groups should be named.
|
||||
- Prefer `Object.hasOwn()`.
|
||||
- Prefer the spread operator over `Object.assign`.
|
||||
- Prefer regular expression literals over the RegExp constructor.
|
||||
- Prefer using the `...` operator instead of `arguments`.
|
||||
- Prefer the spread operator over `.apply()`.
|
||||
- Prefer template literals over string concatenation.
|
||||
- `parseInt()` should always be given a radix.
|
||||
- When an asynchronous function relies on an argument that might change (such as an object reference), care must be taken to avoid race conditions within that function.
|
||||
- Generator functions must use the `yield` keyword.
|
||||
- Object keys must be sorted alphabetically.
|
||||
- Variables within the same declaration block must be sorted alphabetically.
|
||||
- If using the `Symbol` function, you must include a description.
|
||||
- Do not compare to `NaN`, use `Number.isNaN()`.
|
||||
- `typeof` comparators must be a valid return type of `typeof`.
|
||||
- Conditions should always start with the variable, not the constant.
|
||||
|
||||
### 2.1.2. `typescript-eslint` Enforced Rules
|
||||
|
||||
- Do not use `await` on functions that do not return a Promise.
|
||||
- Exported type definitions should use the `export type` keyword.
|
||||
- Use dot notation for property access, unless such syntax would be invalid.
|
||||
- Do not use the `delete` keyword with arrays.
|
||||
- Do not use `<Object>.toString()` on objects. Prefer `JSON.stringify()`.
|
||||
- Do not assign void values to variables, such as `const log = console.log("Bad");`.
|
||||
- Do not duplicate types (e.g. `type myType = "A" | "A"`).
|
||||
- Promises should always be awaited.
|
||||
- Do not implicitly evaluate code, such as with `new Function()`.
|
||||
- Do not use `void` with functions that do not return a value.
|
||||
- Do not use Promises in places that do not consume them (such as callbacks).
|
||||
- Do not combine string and number values in an enum.
|
||||
- Do not use unions/intersections with overriding values (such as `any` or `unknown`).
|
||||
- Do not use comparison operators with boolean values (e.g. `variable === false`).
|
||||
- Do not pass values to a conditional statement that are always truthy or falsy.
|
||||
- Do not use unnecessary namespace references.
|
||||
- Do not use template strings without interpolated values.
|
||||
- Do not pass type arguments to a function that match the default value of that parameter.
|
||||
- Do not define unused type parameters in a function.
|
||||
- Values with an `any` type should not be passed to function calls.
|
||||
- Values with an `any` type should not be assigned to variables.
|
||||
- Values which have an `any` type should not be called as functions.
|
||||
- Do not merge declarations (instead of `interface Foo` and `class Foo`, use `interface Foo` and `class Bar implements Foo`).
|
||||
- Do not compare enum values against arbitrary values.
|
||||
- Do not use the `Function` type. Functions should have a specific type signature.
|
||||
- Values with an `any` type cannot have properties, and such properties should not be accessed.
|
||||
- Functions should not return an `any` value.
|
||||
- The unary minus operator should only be used on numbers.
|
||||
- `throw` statements should only throw an `Error` instance.
|
||||
- Object properties should be destructured, rather than assigned to variables via direct access.
|
||||
- Use `<Array>.find()` instead of `<Array>.filter()[0]` to find an element in an array.
|
||||
- Use `<Array>.includes()` instead of `<Array>.indexOf() === -1`.
|
||||
- Use `??` instead of `||`.
|
||||
- Use optional chaining when possible.
|
||||
- Promises that reject should always return an Error.
|
||||
- Class members that are not modified outside of the constructor should be `readonly`.
|
||||
- The `.reduce()` callback should have typed parameters.
|
||||
- When using a non-global regular expression, use `<RegExp>.exec` over `<String>.match()`.
|
||||
- Class methods that return `this` should have `this` as the return type, not the class.
|
||||
- When testing the beginning or end of a string, use `<String>.startsWith()` or `<String>.endsWith()`.
|
||||
- Functions which return a Promise must use the `async` keyword.
|
||||
- `<Array>.sort()` should always be given a compare function.
|
||||
- `async` functions must use `await`, or be rewritten without the promise.
|
||||
- The `+` operator can only be used with operands of the same type.
|
||||
- Values interpolated in a template string must be of type `string`.
|
||||
- Functions which return a promise should await that return value.
|
||||
- Conditions should not use nullable values - you must always explicitly compare against `null` or `undefined`.
|
||||
- Switch statements are not preferred, but when you must use them it should have exhaustive cases.
|
||||
- Unbound class methods must be called with the expected scope (e.g. `myClass.method.bind(myClass)`).
|
||||
- The `error` parameter in a catch statement is of type `unknown`.
|
||||
- Function overload signatures must be grouped together.
|
||||
- Array type definitions should use the generic `Array<T>` over `T[]`.
|
||||
- `@ts` directives are disallowed, except for `@ts-expect-error` which requires a description.
|
||||
- Classes with static public properties should have a getter for each property.
|
||||
- Class methods which are not static must make use of `this` or be converted to static.
|
||||
- Prefer passing type arguments to a constructor instead of a type annotation.
|
||||
- Prefer `Record<string, T>` over `{ [key: string]: T}`.
|
||||
- Do not use any type assertions (`x as T`).
|
||||
- Object types should be defined with `interface` over `type`.
|
||||
- Imported values which are only used as types should be imported with `type`.
|
||||
- Function parameters which are optional or have a default value should come after all mandatory parameters.
|
||||
- Functions should always have an explicit return type.
|
||||
- All class members should have an accessibility modifier (`public`, `protected`, `private`).
|
||||
- All exported functions and public class methods should have explicit parameter and return types.
|
||||
- Variables should always be initialised with a value.
|
||||
- Functions which take more than three arguments should take a single object instead.
|
||||
- Class members should be ordered as `constructor`, `fields`, `statics`, `getters`, `setters`, then `methods`.
|
||||
- Method types should use the property signature `func: (arg: string) => string`.
|
||||
- Variables should use `camelCase`, types and classes should use `PascalCase`. Only variables may use a leading underscore to indicate they are unused.
|
||||
- Never use the `Array` constructor.
|
||||
- Do not use non-null assertions.
|
||||
- Enums should not have duplicate values.
|
||||
- Do not use the `delete` operator on dynamic property accesses.
|
||||
- Functions, interfaces, and object types should never be empty.
|
||||
- Do not use `any`.
|
||||
- Classes should not consist solely of static members.
|
||||
- The `for...in` loop should not be used.
|
||||
- When all imported members are type imports, use `import type { a, b }` over `import { type a, type b }`.
|
||||
- Do not use type annotations for variables with a string, number, or boolean value. These can be inferred.
|
||||
- The `void` type should only be used as the _sole_ return type of a function. `(): void | string` is invalid.
|
||||
- Do not reference unsafe values in a loop.
|
||||
- Do not use number literals which would lose precision due to memory constraints.
|
||||
- Classes should use `constructor()`, not `new()`. Interfaces for the class should use `new()`, not `constructor()`.
|
||||
- Do not use namespaces.
|
||||
- Do not use `require()`.
|
||||
- Do not declare variables in an inner scope that share a name with a variable in the outer scope.
|
||||
- Do not alias `this`.
|
||||
- Do not needlessly assign constructor parameters to class members of the same name.
|
||||
- Do not `extends` `any` or `unknown`.
|
||||
- Unused expressions should be removed.
|
||||
- Unused variables should be removed.
|
||||
- Do not access a variable before its definition.
|
||||
- Do not define empty constructors.
|
||||
- Do not define empty exports.
|
||||
- Do not use wrapper types (e.g. use `boolean`, not `Boolean`).
|
||||
- Use `as const` over literal types.
|
||||
- Enum values should always be explicitly initialised.
|
||||
- The `for...of` loop should be used over the `for` loop, when the index _value_ is not needed.
|
||||
- Enum values should always be literal values.
|
||||
- Do not use TypeScript's `///` reference.
|
||||
- Do not use overloads when the same result can be achieved via union types or optional parameters.
|
||||
|
||||
### 2.1.3. `eslint-comments` Enforced Rules
|
||||
|
||||
- Do not use blanket `eslint-disable` directives. All `disable` directives must target specific rules.
|
||||
- All `disable` directives must include a comment explaining why the linter is being bypassed.
|
||||
|
||||
### 2.1.4. `deprecation` Enforced Rules
|
||||
|
||||
- Do not use deprecated methods/features, even if the package still supports them.
|
||||
|
||||
### 2.1.5. `import` Enforced Rules
|
||||
|
||||
- Do not use default imports if the module does not have a default export.
|
||||
- Do not import modules simply to re-export them.
|
||||
- Exports should always be at the end of the file.
|
||||
- With the exception of packages, imports should always have a file extension.
|
||||
- Imports should always be at the beginning of the file.
|
||||
- If a module has multiple named exports, group them in a single `export { a, b }` declaration.
|
||||
- Import statements should be followed by a newline.
|
||||
- Import paths should never be absolute
|
||||
- You should not use AMD syntax
|
||||
- You should not use CJS syntax
|
||||
- You should not define cyclical imports (if file a imports file b, file b CANNOT import file a)
|
||||
- Modules should not use a default export.
|
||||
- A module should not import the same file multiple times.
|
||||
- You should not use dynamic `require` calls.
|
||||
- Named import blocks cannot be empty.
|
||||
- You should not import packages that are not included in the `package.json` file.
|
||||
- You cannot `import` a CommonJS module.
|
||||
- Exports must always be declared with `const`.
|
||||
- You cannot use a named export as the default export.
|
||||
- You cannot use a named export as the property of a default export.
|
||||
- You should not have orphaned modules (modules without any exports, or a module which is never imported).
|
||||
- You cannot use webpack loader syntax.
|
||||
- Imports must be sorted alphabetically, first grouped by: builtin node modules, external packages, internal packages, modules in parent directory, modules in current directory, type-only imports.
|
||||
- There should be no new lines between these groups.
|
||||
|
||||
### 2.1.6. `jsdoc` Enforced Rules
|
||||
|
||||
- `@access` tags should be one of `package`, `private`, `protected`, or `public`.
|
||||
- Asterisks should be aligned.
|
||||
- Lines should not be improperly indented.
|
||||
- `@param` names should reflect the actual parameters.
|
||||
- `@property` names should reflect the actual properties.
|
||||
- Should not use `=` (GCC syntax).
|
||||
- All tags must be valid JSDoc tags.
|
||||
- `@template` names should be used in the `@typedef`.
|
||||
- `@license` tag MUST be set to `Naomi's Public License`.
|
||||
- Tags that do not expect content should not have content.
|
||||
- `@implements` should only be used on constructors or classes.
|
||||
- Tag descriptions should not be just a reflection of the name.
|
||||
- Description tags must be complete sentences.
|
||||
- JSDocs must be multiple lines. The first and last line cannot have text content.
|
||||
- JSDoc syntax must be valid.
|
||||
- JSDocs must have a description.
|
||||
- JSDocs cannot be empty.
|
||||
- A hyphen should separate the parameter name from the description.
|
||||
- JSDocs are required on all public functions, classes, and methods. They are encouraged on all public exports.
|
||||
- Parameters must have a name and description.
|
||||
- Properties must have a name and description.
|
||||
- If a function returns a value, it must be documented in `@returns`.
|
||||
- If a function throws an unhandled error intentionally, it must be documented in `@throws`.
|
||||
- If a generator yields a value, it must be documented in `@yields`.
|
||||
- Tags must be sorted alphabetically.
|
||||
- There should be no blank lines between tags.
|
||||
- Any types referenced must be valid types.
|
||||
|
||||
### 2.1.7. `unicorn` Enforced Rules
|
||||
|
||||
- Regular expressions should use special shorthand where possible.
|
||||
- `catch` blocks should always have `error` as the parameter.
|
||||
- When destructuring an object, all consumed properties should be destructured. Do not perform direct property access on an object that is previously destructured.
|
||||
- When spreading a ternary in an array, both sides of the expression must be of the same type.
|
||||
- Functions should be declared in the highest scope possible.
|
||||
- `Error()` constructor calls must always be given a message.
|
||||
- Escape sequences must use uppercase text.
|
||||
- Files should be named in camelCase.
|
||||
- Do not pass function references as callbacks to array methods.
|
||||
- Do not use `.forEach()`.
|
||||
- Do not use `this` in array methods.
|
||||
- Do not chain `.push()` calls.
|
||||
- Do not use `.reduce()`.
|
||||
- Do not access properties directly from an `await` expression.
|
||||
- Do not use `await` in Promise methods such as `.all()`.
|
||||
- Files should not be empty.
|
||||
- Do not use a `for` loop when you can use a `for...of` loop.
|
||||
- Use Unicode escape sequences over hexadecimal escape sequences.
|
||||
- Use `Array.isArray()` over `instanceof Array`.
|
||||
- `GET` or `HEAD` requests should never have a body.
|
||||
- Do not declare variables that start with `new` or `class`.
|
||||
- Do not use `.length` as the argument to `.slice()`.
|
||||
- Use `Buffer.from()`, not `new Buffer()`.
|
||||
- Do not use objects as default parameters.
|
||||
- Do not pass single-element arrays to Promise methods.
|
||||
- Do not define a class that only has static members.
|
||||
- Do not use `.then()`.
|
||||
- Do not assign to `this`.
|
||||
- Do not use `typeof x === "undefined"`.
|
||||
- `await` cannot be used on non-promise values.
|
||||
- You cannot ignore consecutive values when destructuring an array, e.g. `[,,,, val]`.
|
||||
- You cannot use IIFEs.
|
||||
- Promises should not return `.resolve()` or `.reject()`.
|
||||
- You should not spread an array into a new array without adding values.
|
||||
- You should not associate any case statements with the default statement.
|
||||
- Number literals cannot have trailing zeroes after the decimal place.
|
||||
- Number literals must use proper case.
|
||||
- Numbers over 9999 should use `_` to separate each group of three digits, e.g. `10_000`.
|
||||
- If you need to flatten an array, use `Array.flat()`.
|
||||
- Prefer `.flatMap()` over `.map().flat()`.
|
||||
- Prefer `indexOf` over `findIndex`.
|
||||
- Prefer `.some()` over `.filter().length`.
|
||||
- Prefer `.at()` for accessing array and string indices.
|
||||
- Prefer `.codePointAt()` over `.charCodeAt()`.
|
||||
- Prefer `Date.now()` over `new Date().getTime()`.
|
||||
- Use default parameters instead of reassigning undefined values.
|
||||
- Use `Math.trunc` to round numbers, not bitwise operators.
|
||||
- Use ESM modules, not CJS.
|
||||
- Use coercion functions such as `String()` directly.
|
||||
- Use a negative index instead of `.legnth - 1`.
|
||||
- Use the `node:` protocol when importing built-in packages.
|
||||
- Use `Number` properties instead of global helpers e.g. `Number.isNaN()` over `isNaN()`.
|
||||
- Use `Object.fromEntries` to create an object from key-value pairs.
|
||||
- If a `catch` block does not use the `error` parameter, the parameter should be omitted.
|
||||
- Prefer calling prototype methods over instance methods.
|
||||
- Prefer using `Set.has()` over `Array.includes` to check for existence.
|
||||
- Prefer using `Set.size` over `Array.length`.
|
||||
- Prefer using the spread operator over `Array.concat()` or `String.split("")`.
|
||||
- Prefer using `String.replaceAll()` over regex searches.
|
||||
- Prefer `String.slice()` over `String.substr[ing]()`.
|
||||
- Prefer `String.startsWith()` or `.endsWith()` over `RegExp.test()`.
|
||||
- Prefer `String.trim[Start|End]()` over `String.trim[Left|Right]()`.
|
||||
- Use `structuredClone` to create a deep clone of an object.
|
||||
- Use top-level await instead of IIFEs.
|
||||
- Variable names should not be abbreviated.
|
||||
- `Array.join()` must always be given a separator.
|
||||
- `Number.toFixed()` must always be given a digits argument.
|
||||
|
||||
## 2.2. React Rules
|
||||
|
||||
These rules apply to TSX, and will run on files in `src/**/*.tsx`.
|
||||
|
||||
- Boolean properties should be named accordingly, such as `isEnabled` instead of `enabled`.
|
||||
- Buttons must always have a `type` attribute.
|
||||
- If a radio button or checkbox is checked, it must be `readonly` or have an `onChange` handler.
|
||||
- Default properties should match the property types.
|
||||
- Properties, state, and context should always be destructured.
|
||||
- Components must always have a name.
|
||||
- A component cannot consume another component's propTypes.
|
||||
- PropTypes cannot use `any`, `array`, or `object`.
|
||||
- `forwardRef` components must use `ref`.
|
||||
- Components should always be defined as named arrow functions.
|
||||
- State should have matching names, e.g. `[color, setColor]`.
|
||||
- `iframes` should always use the `sandbox` attribute.
|
||||
- Boolean properties should always be explicitly written: `<Component prop={true}>`.
|
||||
- Spaces between JSX elements must be explicitly written: `{' '}`.
|
||||
- Files that contain JSX must have the extension `.jsx` or `.tsx`.
|
||||
- Fragments should always use the shorthand syntax.
|
||||
- Event handlers must be appropriately named: `onChange={this.handleChange}`
|
||||
- Iterators must always have a `key` prop, and it should never be the index.
|
||||
- You should not use `.bind()` in component props
|
||||
- You should not insert comments as text nodes.
|
||||
- Contexts should not use mutable values (e.g. objects), to prevent re-renders.
|
||||
- Components should not have duplicate properties.
|
||||
- Avoid leaking conditional values. Prefer `condition ? <Component> : null` over `condition && <Component>`.
|
||||
- Element text should always be wrapped in JSX containers.
|
||||
- You should never use `javascript:` urls.
|
||||
- `target=_blank` must always be accompanied with `rel=noreferrer`.
|
||||
- You should not use variables that are not declared.
|
||||
- You should not use fragments unless there is no singular wrapping element.
|
||||
- Components should use PascalCase.
|
||||
- You should not spread props multiple times.
|
||||
- Props should be sorted alphabetically.
|
||||
- You should not access `this.state` inside any `setState` functions.
|
||||
- You should not use arrow functions for lifecycle methods.
|
||||
- Children cannot be passed as props.
|
||||
- You cannot use dangerous properties (`dangerouslySetInnerHTML`).
|
||||
- You cannot use deprecated methods.
|
||||
- You cannot use `setState` in `componentDidMount` or `componentDidUpdate` or `componentWillUpdate`.
|
||||
- You cannot directly mutate `this.state`.
|
||||
- You cannot use `findDOMNode`.
|
||||
- You cannot use `isMounted`.
|
||||
- Each file should have only one component.
|
||||
- `ReactDOM.render`'s return value should not be used.
|
||||
- You should not use string references.
|
||||
- `this` cannot be used in stateless functional components.
|
||||
- HTML entities must be escaped.
|
||||
- You cannot use unknown HTML properties.
|
||||
- You cannot use unsafe lifecycle methods.
|
||||
- You cannot define a component within another component.
|
||||
- Class components should not have unused methods.
|
||||
- Components should not have unused propTypes or state
|
||||
- Class components should use the ES6 `class Component extends React.Component` syntax.
|
||||
- Props should be readonly.
|
||||
- Stateless components should be pure functions.
|
||||
- Property accesses must be reflected in the propTypes.
|
||||
- Any optional property must have a default value.
|
||||
- Classes using the `render` method MUST return a value.
|
||||
- Components without children must still have a separate closing tag.
|
||||
- State initialisation must always happen in the constructor.
|
||||
- Static properties should be defined as `static name = `.
|
||||
- The `style` property must always be an object.
|
||||
- Void elements `img`, `br` etc. must never have children.
|
||||
|
||||
## 2.3. Playwright Rules
|
||||
|
||||
These files apply to Playwright End-to-end tests, and will run on `e2e/**/*.spec.ts`.
|
||||
|
||||
- All tests must have at least one `expect` assertion.
|
||||
- `describe` calls cannot be nested more than two levels deep.
|
||||
- Playwright APIs must be `await`ed.
|
||||
- Tests cannot be commented out.
|
||||
- `expect` cannot be called conditionally.
|
||||
- Tests cannot contain conditional logic.
|
||||
- Setup and teardown hooks cannot be duplicated.
|
||||
- You cannot use element handles (`page.$`).
|
||||
- You cannot use `page.$eval()`.
|
||||
- Tests cannot be focused with `.only()`.
|
||||
- Tests cannot be forced with `{ force: true }`.
|
||||
- You cannot use `getByTitle()`.
|
||||
- You cannot use the `networkidle` option.
|
||||
- You cannot use `first()`, `lat()`, or `nth()`.
|
||||
- You cannot use `page.pause()`.
|
||||
- You cannot use `page.locator()`. Prefer specific methods like `page.getByRole()`.
|
||||
- Tests cannot be skipped with `.skip()`.
|
||||
- `expect` can only be called within test blocks.
|
||||
- You cannot reference variables in `page.evaluate()`.
|
||||
- Some Playwright methods are synchronous - these cannot be `await`ed.
|
||||
- You cannot use `.not()` when a specific matcher exists.
|
||||
- You cannot use `page.waitForSelector()` or `page.waitForTimeout()`.
|
||||
- Prefer `.toBeGreaterThan()` over `(x > 5).toBe(true)`.
|
||||
- Prefer `.toBe(5)` over `(x === 5).toBe(true)`
|
||||
- Hooks should be ordered as Playwright calls them: `beforeAll`, `beforeEach`, `afterEach`, `afterAll`.
|
||||
- Hooks should be at the top of the test.
|
||||
- Test names should be lowercase.
|
||||
- Use `.toStrictEqual()` over `.toEqual()`.
|
||||
- Use `.toBe()` over `.toStrictEqual()` for primitive values.
|
||||
- Use `.toContain()` over `.includes()`.
|
||||
- Use `.toHaveCount()` over `locator.count()` and `.toHaveLength()` over `.length`.
|
||||
- Prefer assertions like `.toBeVisible()` over `(locator.isVisible()).toBe(true)`.
|
||||
- Setup and teardown code must be in a hook.
|
||||
- `.toThrow()` assertions require a message.
|
||||
- Tests must be within a `describe` block.
|
||||
- All `expect()` calls must have a custom message.
|
||||
- Promises that contain an `expect` must be awaited.
|
||||
- Tests must have a title that is not empty.
|
||||
|
||||
## 2.4. Vitest Rules
|
||||
|
||||
These files apply to Vitest unit tests, and will run on `test/**/*.spec.ts`.
|
||||
|
||||
:::warn
|
||||
We also mandate the use of `describe`, `it`, and `expect` over `suite`, `test`, and `assert`.
|
||||
:::
|
||||
|
||||
- Files must have `.spec.ts` extension.
|
||||
- consistent-test-it
|
||||
- Tests must have at least one `expect`.
|
||||
- `describe` calls cannot be nested more than two levels deep.
|
||||
- Prefer `.toHaveBeenCalled()` over `.toBeCalled()`.
|
||||
- Tests cannot be commented out.
|
||||
- `expect` cannot be called conditionally.
|
||||
- Tests cannot contain conditional logic.
|
||||
- Tests cannot be run conditionally.
|
||||
- Tests cannot be disabled.
|
||||
- You cannot use the `done()` callback.
|
||||
- Setup and teardown hooks cannot be duplicated.
|
||||
- Tests cannot be focused with `.only()`.
|
||||
- Test titles must be unique.
|
||||
- `node:test` cannot be imported.
|
||||
- Snapshots cannot use string interpolation.
|
||||
- `expect` must be within `it` or `test`.
|
||||
- Tests cannot use `return`.
|
||||
- Prefer `toHaveBeenCalledWith()` over `toHaveBeenCalled()`.
|
||||
- Prefer `.toBeGreaterThan()` over `(x > 5).toBe(true)`.
|
||||
- Use `describe.each` instead of manual loops.
|
||||
- Prefer `.toBe(5)` over `(x === 5).toBe(true)`.
|
||||
- All tests must start with `expect.assertions(number)`.
|
||||
- Use `expect.resolves(fn)` over `expect(await fn)`.
|
||||
- Hooks should be ordered as Vitest calls them: `beforeAll`, `beforeEach`, `afterEach`, `afterAll`.
|
||||
- Hooks should be at the top of the test.
|
||||
- Test titles should be lowercase.
|
||||
- Prefer `vi.fn().mockResolvedValue(val)` over `vi.fn().mockImplementation(() => Promise.resolve(val))`.
|
||||
- Prefer `vi.spyOn(Date, "now")` instead of overwriting the global `Date.now = vi.fn()`.
|
||||
- Use `.toStrictEqual()` over `.toEqual()`.
|
||||
- Use `.toBe()` over `.toStrictEqual()` for primitive values.
|
||||
- Use `.toBeFalsy()` over `.toBe(false)`.
|
||||
- Use `.toBeObject()` over `.toBeInstanceOf(Object)`.
|
||||
- Use `.toBeTruthy()` over `.toBe(true)`.
|
||||
- Use `.toContain()` over `.includes()`.
|
||||
- Use `.toHaveLength()` over `.length`.
|
||||
- Use `test.todo()` instead of `test.skip()`.
|
||||
- Setup and teardown code must be in a hook.
|
||||
- `.toThrow()` assertions require a message.
|
||||
- Tests must be within a `describe` block.
|
||||
- The `describe` callback should not have any parameters and cannot use `return`.
|
||||
- All `expect()` calls must have a custom message.
|
||||
- Tests must have a title that is not empty.
|
||||
@ -1,54 +0,0 @@
|
||||
---
|
||||
title: Naomi's VTubing Setup
|
||||
---
|
||||
|
||||
Naomi uses her VTuber model for all of her client meetings, as well as streaming. Getting the software to work on Linux is a bit of a nightmare, so this page documents how she does so.
|
||||
|
||||
## 1. OpenSeeFace
|
||||
|
||||
In order to track her webcamera, OpenSeeFace needs to be run independently as a native script.
|
||||
|
||||
### 1.1. Installation
|
||||
|
||||
This should all be done in your home `~` directory.
|
||||
|
||||
- Begin by cloning the repository:
|
||||
- `git clone https://github.com/emilianavt/OpenSeeFace`
|
||||
- `cd OpenSeeFace`
|
||||
- You will need to prepare Python
|
||||
- Install the packages: `yay -Sy python python-virtualenv`
|
||||
- Prepare the environment: `virtualenv -p python3 env`
|
||||
- Source the environment: `source env/bin/activate`
|
||||
- Install the dependencies: `pip3 install onnxruntime opencv-python pillow numpy`
|
||||
|
||||
### 1.2. Running
|
||||
|
||||
```
|
||||
cd OpenSeeFace
|
||||
source env/bin/activate
|
||||
python facetracker.py -c 0 -W 1280 -H 720 --discard-after 0 --scan-every 0 --no-3d-adapt 1 --max-feature-updates 900
|
||||
```
|
||||
|
||||
## 2. VSeeFace
|
||||
|
||||
VSeeFace does not run natively, and will need to run with Wine.
|
||||
|
||||
### 2.1. Installation
|
||||
|
||||
[Download and run the installer](https://www.vseeface.icu/#download). When selecting a directory, put it in `~/VSeeFace`.
|
||||
|
||||
### 2.2. Running
|
||||
|
||||
```bash
|
||||
wine ~/VSeeFace/VSeeFace.exe --background-color "#00FF00"
|
||||
```
|
||||
|
||||
The `--background-color` flag creates a green screen background to be chroma-keyed out by OBS.
|
||||
|
||||
## 3. OBS
|
||||
|
||||
OBS allows for virtual camera, as well as for streaming.
|
||||
|
||||
### 3.1. Installation
|
||||
|
||||
The `obs-studio-git` AUR package is Naomi's current installation.
|
||||
@ -1,24 +0,0 @@
|
||||
---
|
||||
title: NHCarrigan Docs
|
||||
description: This site contains all of the documentation related to NHCarrigan, its Policies, and its Projects.
|
||||
template: splash
|
||||
hero:
|
||||
tagline:
|
||||
This site contains all of the documentation related to NHCarrigan, its Policies, and its Projects.
|
||||
actions:
|
||||
- text: Mission Statement
|
||||
link: /about/mission/
|
||||
variant: secondary
|
||||
- text: Code of Conduct
|
||||
link: /community/coc/
|
||||
variant: secondary
|
||||
- text: Contributing Guide
|
||||
link: /dev/contributing/
|
||||
variant: secondary
|
||||
- text: Software License
|
||||
link: /legal/license/
|
||||
variant: secondary
|
||||
- text: Contact Us
|
||||
link: /about/contact/
|
||||
variant: secondary
|
||||
---
|
||||
@ -1,121 +0,0 @@
|
||||
---
|
||||
title: DMCA and Intellectual Property Compliance Policy
|
||||
---
|
||||
|
||||
## 1. General Principles
|
||||
|
||||
- Respect for intellectual property rights is fundamental to our community's ethos and operations.
|
||||
- All community members, including users, contributors, and administrators, are expected to comply with applicable copyright laws, trademark regulations, and licensing terms.
|
||||
- This policy aims to protect the rights of content creators while fostering an environment of innovation and knowledge sharing.
|
||||
- Ignorance of the law or this policy is not considered a valid excuse for non-compliance.
|
||||
|
||||
## 2. Sharing Copyrighted Material
|
||||
|
||||
- Do not share copyrighted material without explicit permission from the copyright holder or a valid license.
|
||||
- When sharing is permitted, always include proper attribution and adhere to any specified terms of use.
|
||||
- Linking to legitimately published content is generally acceptable, but copying and pasting substantial portions is discouraged unless explicitly allowed by the copyright holder.
|
||||
- Be aware that even user-generated content on social media platforms may be copyrighted.
|
||||
- When in doubt about the copyright status of material, err on the side of caution and seek permission or clarification.
|
||||
|
||||
## 3. Fair Use and Educational Purposes
|
||||
|
||||
- Limited use of copyrighted material for commentary, criticism, news reporting, teaching, scholarship, or research may be permissible under fair use doctrines.
|
||||
- When relying on fair use, clearly indicate the source and purpose of the use.
|
||||
- Fair use is determined on a case-by-case basis, considering factors such as:
|
||||
- The purpose and character of the use (commercial vs. non-profit educational)
|
||||
- The nature of the copyrighted work
|
||||
- The amount and substantiality of the portion used
|
||||
- The effect of the use upon the potential market for the copyrighted work
|
||||
- Educational use does not automatically qualify as fair use; consider all factors carefully.
|
||||
|
||||
## 4. Proper Attribution
|
||||
|
||||
- When using or referencing others' work, always provide clear and comprehensive attribution.
|
||||
- Attribution should include:
|
||||
- The name of the creator or author
|
||||
- The title of the work
|
||||
- The source (e.g., website URL, book title, journal name)
|
||||
- The date of publication or creation (if available)
|
||||
- Any applicable license terms
|
||||
- For digital content, consider using hyperlinks to the original source when possible.
|
||||
- Follow citation guidelines appropriate to your field or the context of use (e.g., APA, Chicago).
|
||||
|
||||
## 5. Original Content Creation and Sharing
|
||||
|
||||
- Community members are encouraged to create and share original content.
|
||||
- By sharing original content in our community spaces, you grant the community a non-exclusive, worldwide, royalty-free right to use, reproduce, modify, adapt, publish, translate, distribute, and display the content within the community.
|
||||
- You retain copyright of your original work unless explicitly stated otherwise.
|
||||
- Consider adding a clear copyright notice to your original works.
|
||||
- Be mindful of using third-party content (e.g., images, music) in your original creations, ensuring you have the right to incorporate such elements.
|
||||
|
||||
## 6. Open Source and Creative Commons
|
||||
|
||||
- We encourage the use of open source licenses and Creative Commons for shared content where appropriate.
|
||||
- When using open source or Creative Commons licensed material, adhere strictly to the terms of the license.
|
||||
- Familiarize yourself with different types of open source and Creative Commons licenses and their requirements (e.g., attribution, share-alike, non-commercial use).
|
||||
- Provide clear license information when sharing your own content under open source or Creative Commons terms.
|
||||
|
||||
## 7. Code Snippets and Examples
|
||||
|
||||
- Short code snippets shared for educational or troubleshooting purposes are generally acceptable under fair use.
|
||||
- For larger code samples, include license information and attribution if taken from other sources.
|
||||
- When sharing your own code, consider using an appropriate open source license.
|
||||
- Be aware that copying entire programs or substantial portions of code may infringe copyright, even if source attribution is provided.
|
||||
|
||||
## 8. Plagiarism
|
||||
|
||||
- Presenting others' work as your own is strictly prohibited and considered a serious offence.
|
||||
- This includes code, text, images, ideas, and any other form of content.
|
||||
- Plagiarism can have serious consequences, including loss of community privileges, academic penalties, or legal action.
|
||||
- Always cite your sources and use quotation marks for direct quotes.
|
||||
|
||||
## 9. Trademark Usage
|
||||
|
||||
- Respect trademark rights when referencing products, services, or organizations.
|
||||
- Use trademark symbols (™, ®) appropriately when referring to trademarked names.
|
||||
- Avoid using trademarks in a way that suggests endorsement or affiliation without permission.
|
||||
|
||||
## 10. Digital Millennium Copyright Act (DMCA) Compliance
|
||||
|
||||
- We comply with the DMCA and maintain a policy for addressing claims of copyright infringement.
|
||||
- If you believe your copyrighted work has been improperly used within our community, submit a DMCA takedown notice to DMCA@nhcarrigan.com.
|
||||
- DMCA takedown notices must include:
|
||||
- Identification of the copyrighted work claimed to have been infringed
|
||||
- Identification of the allegedly infringing material
|
||||
- Contact information for the complainant
|
||||
- A statement of good faith belief that the use is not authorized
|
||||
- A statement, under penalty of perjury, that the information in the notice is accurate and that the complainant is authorized to act on behalf of the copyright owner
|
||||
- We will promptly investigate all legitimate DMCA takedown notices and take appropriate action, which may include content removal or account suspension.
|
||||
|
||||
## 11. Counter-Notifications
|
||||
|
||||
- If you believe your content was wrongly removed due to a DMCA takedown notice, you may submit a counter-notification.
|
||||
- Counter-notifications must include:
|
||||
- Identification of the removed material and its location before removal
|
||||
- A statement under penalty of perjury that you have a good faith belief the material was removed by mistake or misidentification
|
||||
- Your name, address, and telephone number
|
||||
- A statement that you consent to the jurisdiction of the federal district court for the judicial district in which you reside
|
||||
|
||||
## 12. Repeat Infringer Policy
|
||||
|
||||
- We maintain a repeat infringer policy to ensure ongoing DMCA compliance.
|
||||
- Users who repeatedly infringe copyrights may have their accounts terminated.
|
||||
- We keep records of DMCA notices and counter-notifications to identify repeat infringers.
|
||||
|
||||
## 13. Education and Awareness
|
||||
|
||||
- We are committed to educating our community about intellectual property rights and responsibilities.
|
||||
- Regular updates and resources on copyright law and best practices will be provided.
|
||||
- Members are encouraged to seek clarification on any aspect of this policy they find unclear.
|
||||
|
||||
## 14. Policy Updates
|
||||
|
||||
- This policy may be updated periodically to reflect changes in law, technology, or community needs.
|
||||
- Continued use of our community platforms constitutes acceptance of the current policy.
|
||||
|
||||
## 15. Disclaimer
|
||||
|
||||
- This policy is not exhaustive and does not constitute legal advice.
|
||||
- Users are encouraged to seek independent legal counsel for specific intellectual property matters.
|
||||
|
||||
By participating in our community, you agree to abide by this DMCA and Intellectual Property Compliance Policy. Failure to comply may result in content removal, account suspension, or other appropriate actions as determined by community administrators.
|
||||
@ -1,34 +0,0 @@
|
||||
---
|
||||
title: Government Actions and Compliance
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
The purpose of this document is to maintain transparency regarding any government or legal authority's actions against our organisation that result in a release of your data to those authorities.
|
||||
|
||||
### 1.1. Disclaimers
|
||||
|
||||
- We do not provide any sort of proactive information to regulatory agencies.
|
||||
- We do not, and will never, set up "backdoors" or other direct access routes for regulatory agencies to surveil or access your data.
|
||||
- All data in this document cover the entirety of NHCarrigan's lifetime, from our inception in
|
||||
|
||||
## 2. Requests for Information
|
||||
|
||||
We have received 0 requests for information/data from authoritative agencies.
|
||||
|
||||
| Agency | Data Requested | Result |
|
||||
| ------ | -------------- | ------ |
|
||||
|
||||
## 3. Warrants and Subpoenas
|
||||
|
||||
We have been the subject of 0 warrants or subpoenas for our information/data.
|
||||
|
||||
| Agency | Date of Action | Result |
|
||||
| ------ | -------------- | ------ |
|
||||
|
||||
## 4. Asset Seizures
|
||||
|
||||
We have had our data/information searched or seized 0 times.
|
||||
|
||||
| Agency | Scope of Search | Result |
|
||||
| ------ | --------------- | ------ |
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,290 +0,0 @@
|
||||
---
|
||||
title: Privacy Policy
|
||||
---
|
||||
|
||||
## 1. Overview and Scope
|
||||
|
||||
### 1.1. General Applicability
|
||||
|
||||
This privacy policy ("General Policy") governs the collection, use, storage, and protection of data across all our services, platforms, and applications (collectively referred to as "Services").
|
||||
|
||||
### 1.2. Project-Specific Policies
|
||||
|
||||
Individual projects or Services may be subject to additional, project-specific privacy policies ("Project Policies"). These Project Policies apply concurrently with the General Policy. In the event of any conflict between the General Policy and a Project Policy, the stricter privacy protections shall prevail.
|
||||
|
||||
### 1.3. Policy Updates and Retroactivity
|
||||
|
||||
We reserve the right to modify, amend, or update this General Policy and any Project Policies at any time. All changes to these policies, including the General Policy and any Project Policies, are retroactive and apply to previously collected data as well as data collected after the changes take effect.
|
||||
|
||||
### 1.4. Notification of Changes
|
||||
|
||||
We will make reasonable efforts to notify users of significant changes to our privacy policies. However, it is the user's responsibility to regularly review the applicable privacy policies for any updates.
|
||||
|
||||
### 1.5. Acceptance of Terms
|
||||
|
||||
By accessing, using, or continuing to use our Services, you explicitly acknowledge and agree to be bound by the most current version of the General Policy and any applicable Project Policies. If you do not agree with the terms of these policies, you must immediately cease using our Services.
|
||||
|
||||
### 1.6. Effective Date
|
||||
|
||||
The effective date of the current version of this policy will be clearly stated at the beginning of the document. Each revision will be numbered or dated for easy reference.
|
||||
|
||||
## 2. Error Logging and Transparency
|
||||
|
||||
### 2.1. Public Error Logging
|
||||
|
||||
In alignment with our commitment to open source principles, we maintain a policy of transparency regarding application errors and issues. All errors encountered in our Services are logged publicly in our Discord community.
|
||||
|
||||
### 2.2. Content of Error Logs
|
||||
|
||||
Error logs may include, but are not limited to:
|
||||
|
||||
- Timestamp of the error
|
||||
- Error type and description
|
||||
- Relevant application or service name
|
||||
- Non-personally identifiable technical details necessary for troubleshooting
|
||||
- General user actions that led to the error (without specific user identification)
|
||||
|
||||
### 2.3. Potentially Included Information
|
||||
|
||||
While we strive to minimize inclusion of personal or sensitive information, error logs may sometimes contain:
|
||||
|
||||
- User IDs or usernames (in hashed or partially redacted form)
|
||||
- IP addresses (in hashed or partially redacted form)
|
||||
- Device information
|
||||
- Other technical data relevant to the error
|
||||
|
||||
### 2.4. Access to Error Logs
|
||||
|
||||
We strongly recommend that all users join our Discord community prior to using our applications. This allows you to:
|
||||
|
||||
- Review the types of information being logged
|
||||
- Understand the frequency and nature of errors
|
||||
- Participate in discussions about bugs and improvements
|
||||
|
||||
### 2.5. Discord Community Access
|
||||
|
||||
To join our Discord community and access the error logs, please use the following link: https://chat.nhcarrigan.com
|
||||
|
||||
### 2.6. Opt-Out and Data Removal
|
||||
|
||||
If you have concerns about information appearing in error logs:
|
||||
|
||||
- You may opt-out of using our Services
|
||||
- You can contact us to request removal of specific log entries, subject to our data retention policies
|
||||
|
||||
### 2.7. Continuous Improvement
|
||||
|
||||
Public error logging helps us maintain transparency, quickly identify and resolve issues, and continually improve our Services. We appreciate our users' understanding and participation in this process.
|
||||
|
||||
## 3. Data Collection, Documentation, and User Rights
|
||||
|
||||
### 3.1. Data Collection Practices
|
||||
|
||||
We strive to collect only the data necessary for the proper functioning and improvement of our Services. However, the scope of data collection may change as our Services evolve.
|
||||
|
||||
### 3.2. Documentation Efforts
|
||||
|
||||
We make every effort to maintain accurate and up-to-date documentation regarding our data collection practices. This includes:
|
||||
|
||||
- Regular reviews of our data collection processes
|
||||
- Timely updates to our privacy policy and related documentation
|
||||
- Clear communication about significant changes in data collection
|
||||
|
||||
### 3.3. Potential Undocumented Data Collection
|
||||
|
||||
Despite our best efforts, it is possible that at any given time, an application or Service may collect data that is not explicitly documented. This may occur due to:
|
||||
|
||||
- Recent updates or changes to our Services
|
||||
- Technical issues or bugs
|
||||
- Third-party integrations or dependencies
|
||||
|
||||
### 3.4. General Data Rights
|
||||
|
||||
Regardless of whether specific data collection is documented, users have the following rights:
|
||||
|
||||
#### 3.4.1. Right to Access:
|
||||
|
||||
At any time, you may request a complete copy of your data stored by one of our applications. Requests must be done via our [support server](https://chat.nhcarrigan.com) from the Discord account the data belongs to. This ensures that a user cannot impersonate you and request your data. We may request additional identifying information, depending on the structure of the data collected by the application.
|
||||
|
||||
#### 3.4.2. Right to Rectification:
|
||||
|
||||
You may request corrections to any inaccurate data we hold about you.
|
||||
|
||||
#### 3.4.3. Right to Erasure:
|
||||
|
||||
At any time, you may request complete removal of your stored data. Requests must be done via our [support server](https://chat.nhcarrigan.com) from the Discord account the data belongs to. This ensures that a user cannot impersonate you and request your data. We may request additional identifying information, depending on the structure of the data collected by the application.
|
||||
|
||||
This will **not** opt you out of future data collection unless specifically requested. We reserve the right to refuse removal requests when the data are necessary for specific functionality of the app, in circumstances where removing your data would compromise the functionality for all users.
|
||||
|
||||
#### 3.4.4. Right to Restrict Processing:
|
||||
|
||||
At any time, you may request to opt out of data collection for an application by requesting removal of your data and discontinuing interaction with the application. We may request additional identifying information, depending on the structure of the data collected by the application.
|
||||
|
||||
We reserve the right to refuse opt-out requests when the data are necessary for specific functionality of the app, in circumstances where opting-out would compromise the functionality for all users.
|
||||
|
||||
#### 3.4.5. Right to Data Portability:
|
||||
|
||||
You may request a copy of your data in a structured, commonly used, and machine-readable format.
|
||||
|
||||
### 3.5. Exercising Your Rights
|
||||
|
||||
To exercise any of these rights or to inquire about data we may hold:
|
||||
|
||||
- Contact us through our discord server: https://chat.nhcarrigan.com
|
||||
- Be prepared to verify your identity to protect the security of your information
|
||||
|
||||
### 3.6. Opting Out of Data Collection
|
||||
|
||||
- You may cease using our Services
|
||||
- For specific types of data collection, we may offer granular opt-out options
|
||||
- Note that opting out of essential data collection may limit or prevent your use of certain Services
|
||||
|
||||
### 3.7. Response Time and Process
|
||||
|
||||
We will make reasonable efforts to respond to all data-related requests within 30 days. Complex requests may require additional time, in which case we will notify you.
|
||||
|
||||
### 3.8. Limitations
|
||||
|
||||
While we strive to honour all legitimate requests, be aware that legal requirements may sometimes prevent us from fully complying with certain requests.
|
||||
|
||||
### 3.9. Ongoing Commitment
|
||||
|
||||
We are committed to transparency and user privacy. We continuously work to improve our data practices and documentation to ensure the highest standards of data protection and user trust.
|
||||
|
||||
## 4. Data Retention
|
||||
|
||||
### 4.1. Retention Principle
|
||||
|
||||
We adhere to the principle of data minimization, storing personal data for the shortest time necessary to fulfil the purposes for which it was collected and to ensure the proper functioning of our applications.
|
||||
|
||||
### 4.2. Retention Periods
|
||||
|
||||
Specific retention periods may vary depending on the type of data and the purpose for which it is processed. Generally:
|
||||
|
||||
- Active user data is retained for the duration of the user's account activity
|
||||
- Inactive user data may be retained for a period after the last user interaction, typically not exceeding 12 months
|
||||
- Aggregated and anonymized data may be retained indefinitely for analytical purposes
|
||||
|
||||
### 4.3. Automatic Deletion
|
||||
|
||||
Where technically feasible, we implement automated processes to delete or anonymize personal data that has exceeded its retention period.
|
||||
|
||||
### 4.4. Legal and Regulatory Compliance
|
||||
|
||||
Certain data may be retained for longer periods if required by applicable laws, regulations, or to comply with legal obligations.
|
||||
|
||||
### 4.5. Backup Retention
|
||||
|
||||
For data recovery purposes, backups may contain personal data for a period beyond the active retention period. These backups are secured and accessed only when necessary for system restoration.
|
||||
|
||||
### 4.6. User-Initiated Deletion
|
||||
|
||||
Users may request the deletion of their data at any time, subject to our legitimate business needs and legal obligations.
|
||||
|
||||
## 5. Availability of Data
|
||||
|
||||
### 5.1. Access Control
|
||||
|
||||
Access to user data is strictly controlled and limited to authorized members of the nhcarrigan team on a need-to-know basis.
|
||||
|
||||
### 5.2. Purpose Limitation
|
||||
|
||||
Data access by the nhcarrigan team is permitted only for the following purposes:
|
||||
|
||||
- Debugging application issues
|
||||
- Improving application functionality and user experience
|
||||
- Contributing to the development and maintenance of the application
|
||||
- Responding to user support requests
|
||||
- Ensuring compliance with legal and regulatory requirements
|
||||
|
||||
### 5.3. Data Security Measures
|
||||
|
||||
We implement robust security measures to protect data from unauthorized access, including but not limited to:
|
||||
|
||||
- Encryption of data in transit and at rest
|
||||
- Multi-factor authentication for developer accounts
|
||||
- Regular security audits and vulnerability assessments
|
||||
- Logging of data access and modifications
|
||||
|
||||
### 5.4. Developer Training and Accountability
|
||||
|
||||
All team members with data access are:
|
||||
|
||||
- Required to undergo privacy and security training
|
||||
- Bound by confidentiality agreements
|
||||
- Subject to disciplinary action for unauthorized data access or misuse
|
||||
|
||||
### 5.5. Third-Party Access
|
||||
|
||||
We do not sell user data. In cases where third-party service providers require access to perform specific functions:
|
||||
|
||||
- Access is limited to the minimum necessary data
|
||||
- Providers are bound by strict contractual obligations to protect user data
|
||||
- We regularly review and audit third-party practices
|
||||
|
||||
### 5.6. Transparency
|
||||
|
||||
We maintain logs of data access by our team and can provide this information upon justified request, subject to privacy and security considerations.
|
||||
|
||||
### 5.7. User Data Requests
|
||||
|
||||
Users may request information about how their data has been accessed or used by contacting our designated data protection contact.
|
||||
|
||||
### 5.8. Continuous Improvement
|
||||
|
||||
We regularly review and update our data handling practices to ensure the highest standards of data protection and to minimize unnecessary access to personal information.
|
||||
|
||||
## 6. Contact Information and Data Inquiries
|
||||
|
||||
We value transparency and are committed to addressing any questions or concerns you may have regarding our privacy practices. There are several ways to reach us:
|
||||
|
||||
### 6.1. Discord Support Server
|
||||
|
||||
For immediate assistance and community support, join our Discord server: https://chat.nhcarrigan.com
|
||||
|
||||
### 6.2. Email Contact
|
||||
|
||||
For privacy-specific inquiries or formal requests, please email: `privacy@nhcarrigan.com`
|
||||
|
||||
### 6.3. Response Time
|
||||
|
||||
We strive to respond to all inquiries within 5 business days. Complex issues may require additional time.
|
||||
|
||||
### 6.4. Types of Inquiries
|
||||
|
||||
We welcome contact regarding:
|
||||
|
||||
- Questions about this privacy policy
|
||||
- Inquiries about our data collection and use practices
|
||||
- Requests to exercise your data rights (access, rectification, erasure, etc.)
|
||||
- Reporting of potential data breaches or security concerns
|
||||
- Suggestions for improving our privacy practices
|
||||
|
||||
### 6.5. Information to Include
|
||||
|
||||
To help us address your inquiry efficiently, please include:
|
||||
|
||||
- Your full name
|
||||
- The email address associated with your account (if applicable)
|
||||
- A detailed description of your question or concern
|
||||
- Any relevant dates, times, or specific instances related to your inquiry
|
||||
|
||||
### 6.6. Verification Process
|
||||
|
||||
For security reasons, we may need to verify your identity before processing certain requests, especially those related to personal data.
|
||||
|
||||
### 6.7. Alternative Contact Methods
|
||||
|
||||
If you are unable to use Discord or email, please visit our website for additional contact options: https://nhcarrigan.com
|
||||
|
||||
### 6.8. Updates and Notifications
|
||||
|
||||
If you wish to receive updates about changes to our privacy policy or data practices, please join our Discord server: https://chat.nhcarrigan.com
|
||||
|
||||
### 6.9. Legal Inquiries
|
||||
|
||||
For legal or formal inquiries, please use the email provided above and clearly mark your message as a legal inquiry.
|
||||
|
||||
### 6.10. Accessibility
|
||||
|
||||
If you require this information in an alternative format for accessibility reasons, please let us know, and we will do our best to accommodate your needs.
|
||||
@ -1,137 +0,0 @@
|
||||
---
|
||||
title: Security Policy
|
||||
---
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
This Security Policy outlines the procedures for reporting security vulnerabilities in our applications and the terms under which we handle such reports. By participating in our security reporting process, you agree to comply with this policy.
|
||||
|
||||
## 2. Scope
|
||||
|
||||
This policy applies to all applications, services, and systems maintained by our organization, including but not limited to:
|
||||
|
||||
- Our main websites and applications
|
||||
- All open-source projects hosted on our repositories
|
||||
- Any associated APIs or backend services
|
||||
|
||||
## 3. Reporting a Vulnerability
|
||||
|
||||
### 3.1 Reporting Channels
|
||||
|
||||
If you discover a security vulnerability within any of our applications or systems, please report it through one of the following secure channels:
|
||||
|
||||
1. Create a private ticket on our [support server](https://chat.nhcarrigan.com)
|
||||
2. Send an email to `security@nhcarrigan.com`
|
||||
|
||||
### 3.2 Public Disclosure Prohibition
|
||||
|
||||
Do NOT disclose the vulnerability publicly or through any public channels, including but not limited to:
|
||||
|
||||
- Public GitHub issues
|
||||
- Social media platforms
|
||||
- Public forums or chat rooms
|
||||
- Blog posts or articles
|
||||
|
||||
### 3.3 Required Information
|
||||
|
||||
When reporting a vulnerability, please provide:
|
||||
|
||||
- A detailed description of the vulnerability
|
||||
- Steps to reproduce the issue
|
||||
- Potential impact of the vulnerability
|
||||
- Any suggested mitigation or fix (if known)
|
||||
|
||||
## 4. Response Process
|
||||
|
||||
### 4.1 Acknowledgment
|
||||
|
||||
We will acknowledge receipt of your vulnerability report within 3 business days.
|
||||
|
||||
### 4.2 Assessment and Verification
|
||||
|
||||
Our security team will assess the reported vulnerability and may contact you for additional information if needed.
|
||||
|
||||
### 4.3 Resolution Timeline
|
||||
|
||||
We strive to resolve confirmed vulnerabilities within 90 days of the initial report, depending on the complexity and severity of the issue.
|
||||
|
||||
## 5. Disclosure Policy
|
||||
|
||||
### 5.1 Coordinated Disclosure
|
||||
|
||||
We practice coordinated disclosure. We will work with you to ensure that a fix is available before any public disclosure of the vulnerability.
|
||||
|
||||
### 5.2 Public Acknowledgment
|
||||
|
||||
With your permission, we may publicly acknowledge your contribution in discovering and reporting the vulnerability after it has been resolved.
|
||||
|
||||
## 6. Legal Safe Harbor
|
||||
|
||||
### 6.1 Authorization
|
||||
|
||||
We authorize security research and vulnerability disclosure activities, provided they are conducted in accordance with this policy and all applicable laws.
|
||||
|
||||
### 6.2 Scope of Protection
|
||||
|
||||
We will not initiate legal action for accidental, good faith violations of this policy. This safe harbor applies only to activities that:
|
||||
|
||||
- Comply with all aspects of this Security Policy
|
||||
- Do not compromise or attempt to compromise the privacy or safety of our users, employees, or systems
|
||||
- Do not violate any applicable laws
|
||||
|
||||
### 6.3 Limitations
|
||||
|
||||
This safe harbor does not apply to:
|
||||
|
||||
- Vulnerabilities or information obtained through means other than security research
|
||||
- Research conducted on third-party applications or services that integrate with our systems
|
||||
|
||||
## 7. Bug Bounty Program
|
||||
|
||||
We do not currently offer monetary rewards or "bug bounties" for reporting security vulnerabilities. Your contributions to our security are greatly appreciated, but are on a voluntary basis.
|
||||
|
||||
We will gladly thank you in our [Hall of Fame](/community/hall-of-fame)
|
||||
|
||||
## 8. Data Protection and Privacy
|
||||
|
||||
### 8.1 Handling of Submitted Information
|
||||
|
||||
Any information you provide in your vulnerability report will be handled in accordance with our Privacy Policy and applicable data protection laws.
|
||||
|
||||
### 8.2 Confidentiality
|
||||
|
||||
We will treat all vulnerability reports as confidential and will not share the information beyond what is necessary to address the reported issue.
|
||||
|
||||
## 9. Proactive Measures
|
||||
|
||||
In order to maintain the best possible effort to protect your data and the safety of our applications, we implement the following proactive security measures.
|
||||
|
||||
### 9.1. Code Scanning
|
||||
|
||||
Our projects are scanned for potential security risks and vulnerabilities using SonarQube. You can view the latest scan reports [on our dashboard](https://quality.nhcarrigan.link).
|
||||
|
||||
### 9.2. Local Scanning
|
||||
|
||||
We also run a weekly scan on all of our projects using local tooling:
|
||||
|
||||
- Gitleaks (to detect leaked secrets and credentials)
|
||||
- Grype (secondary detection for vulnerabilities in dependencies)
|
||||
- Snyk (in-depth scanning of code and dependencies)
|
||||
- Syft (to generate Software Bill of Materials for third-party auditors to use)
|
||||
- Trivy (to detect vulnerabilities in dependencies)
|
||||
|
||||
The results of these scans are found at https://security.nhcarrigan.com
|
||||
|
||||
## 10. Compliance with Laws and Regulations
|
||||
|
||||
All security research and vulnerability disclosure activities must comply with all applicable local, state, and federal laws, as well as any relevant international laws.
|
||||
|
||||
## 11. Policy Updates
|
||||
|
||||
We reserve the right to update or modify this Security Policy at any time. Any changes will be effective immediately upon posting the updated policy on our website or repository.
|
||||
|
||||
## 12. Contact Information
|
||||
|
||||
For any questions regarding this Security Policy, please contact us at `security@nhcarrigan.com`.
|
||||
|
||||
By reporting a security vulnerability to us, you acknowledge that you have read, understood, and agree to this Security Policy.
|
||||
@ -1,31 +0,0 @@
|
||||
---
|
||||
title: Data Subprocessors
|
||||
---
|
||||
|
||||
## 1. Subprocessors
|
||||
|
||||
The following entities process your data on our behalf. Interacting with our applications is subject to the privacy policies and terms of these entities.
|
||||
|
||||
### 1.1. Primary Subprocessors
|
||||
|
||||
These entities directly store, manage, or handle our application data.
|
||||
|
||||
| Entity | Data Processed |
|
||||
| ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Anthropic | Any data provided to our AI-powered applications such as the AltGenerator Discord bot. |
|
||||
| DigitalOcean | Any data transmitted over the network to and from our applications. |
|
||||
| Discord | Any information related to usage logging and errors posted in our community. |
|
||||
| HubSpot | Data submitted to our Contact, Sales Inquiry, Sanction Appeals, Newsletter Sign-up, and Staff Application forms, as well as data transmitted via our embedded chat widgets. |
|
||||
| MongoDB | Any data provided to our applications when you interact with them. |
|
||||
| ProtonMail | Any information transmitted to and from our `nhcarrigan.com` email addresses. |
|
||||
| Stripe | Information provided during the identity and age verification processes necessary to access certain applications and community channels. |
|
||||
|
||||
### 1.2. Secondary Subprocessors
|
||||
|
||||
In addition to our primary subprocessors, platforms and services you engage with in order to interface with our applications maintain their own privacy policies, and may store your data pursuant to those policies.
|
||||
|
||||
Such platforms include, but are not limited to:
|
||||
|
||||
- Codeberg
|
||||
- Discord
|
||||
- GitHub
|
||||
File diff suppressed because it is too large
Load Diff
@ -1,37 +0,0 @@
|
||||
---
|
||||
title: <app name>
|
||||
---
|
||||
|
||||
<app name> (hereinafter the "Application") is <description>
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for those interacting with a live instance of the Application.
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
|
||||
## 4. Contributing Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for documentation related to contributing to the Application's codebase.
|
||||
@ -1,89 +0,0 @@
|
||||
---
|
||||
title: AltGenerator
|
||||
---
|
||||
|
||||
AltGenerator (hereinafter the "Application") is a wrapper around Anthropic's Claude model that allows you to sumbit an image to the LLM and receive descriptive alt-text.
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
:::caution[Note]
|
||||
We offer free access to this bot within [our Discord server](https://chat.nhcarrigan.com).
|
||||
|
||||
For the bot to respond to you in other servers, or via DMs, you will need to subscribe.
|
||||
:::
|
||||
|
||||
This section is for those interacting with a live instance of the Application.
|
||||
|
||||
To interact with the Application, you must send a message (in a server channel it can see and respond to, or in a direct message with the bot). The content of your message **must start with** a mention (or ping) of the bot.
|
||||
|
||||
If you are using the Application outside of our server, and have not subscribed, you will be met with a prompt to subscribe:
|
||||
|
||||
|
||||
|
||||
Otherwise, the bot will respond to your query. Note that the bot does NOT look at the text content of your message, only image attachments.
|
||||
|
||||
|
||||
|
||||
To cut down on costs and provide this service at an affordable rate to you, the Application does not track any conversation history. Each message you send is treated as an isolated query and receives a response independent of any prior interactions.
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
In order to host your own instance of this application, you will need to complete a few steps.
|
||||
|
||||
### 2.1. Discord Application
|
||||
|
||||
First, you will need to go through the [Discord Developer Portal](https://discord.com/developers/applications) to set up a new Discord Bot account. The bot will not need any privileged intents.
|
||||
|
||||
Once you have the bot set up, save the token in 1password and update the `DISCORD_TOKEN` secret reference in `prod.env`.
|
||||
|
||||
You'll also need to set up a Discord webhook for debug logs. Save the URL in 1password and update the `DEBUG_HOOK` secret reference in `prod.env`.
|
||||
|
||||
### 2.2. Anthropic
|
||||
|
||||
You will need to register for an [Anthropic API account](https://console.anthropic.com). Note that this is NOT the same as a paid Claude account - they are independent services with independent billing.
|
||||
|
||||
Under the `Billing` tab, you'll need to load some credits. There is no free tier for this API.
|
||||
|
||||
Under the `API Keys` tab, generate an API key for your workspace. Save the key in 1password and update the `ANTHROPIC_TOKEN` secret reference in `prod.env`.
|
||||
|
||||
### 2.3. Monetisation
|
||||
|
||||
Whether you wish to enable monetisation or not, you'll want to update the logic in `src/index.ts` around line 239 to reflect the behaviour and values relevant to your instance.
|
||||
|
||||
For example, you may need to update the SKU in the button with the SKU for your application, or remove the entitlement logic entirely and offer the service for free.
|
||||
|
||||
### 2.4. Running the Application
|
||||
|
||||
Once you have the Application on a [configured server](/dev/servers), you'll need to run the following commands:
|
||||
|
||||
```bash
|
||||
pnpm install #install the dependencies
|
||||
pnpm build #compile the typescript into javascript
|
||||
OP_SERVICE_ACCOUNT_TOKEN=<key> pm2 start 'pnpm start' --name 'naomiai' #start the app as a PM2 process
|
||||
```
|
||||
|
||||
If you have configured everything correctly, you'll be all set!
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
|
||||
### 3.1. Privacy Policy
|
||||
|
||||
The Application does not use Discord's Message Content intent. This means that it cannot see the content of ANY message you send unless you explicitly ping the bot (or have DMed the bot directly).
|
||||
|
||||
We do not store any data related to the use of this Application.
|
||||
|
||||
The image files you consensually submit to the Application as part of normal usage are sent to Anthropic to generate the LLM response. Messages are sent anonymously, and not tied to your user account. However, the files may be processed in accordance with Anthropic's Terms and Privacy Policies.
|
||||
|
||||
Your UUID is logged in our support server, with the quantity and cost of tokens consumed in your interaction with the Application. No message content or other information is logged, and these data are solely used to track usage metrics and identify a need to adjust costs.
|
||||
|
||||
## 4. Contributing Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for documentation related to contributing to the Application's codebase.
|
||||
@ -1,184 +0,0 @@
|
||||
---
|
||||
title: ESLint Config
|
||||
---
|
||||
|
||||
import { Tabs, TabItem } from "@astrojs/starlight/components";
|
||||
|
||||
ESLint Config (hereinafter the "Application") is an `npm` package containing our highly customised set of ESLint rules. Every rule has been explicitly set - there are no default configurations loaded.
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
This section is for those interacting with a live instance of the Application.
|
||||
|
||||
### 1.1. Installation
|
||||
|
||||
To use this linter configuration in your own project, you must be using Node.js. Install the package and the necessary dependency:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="npm">
|
||||
```bash
|
||||
npm install -D eslint @nhcarrigan/eslint-config
|
||||
```
|
||||
</TabItem>
|
||||
<TabItem label="yarn">
|
||||
```bash
|
||||
yarn add --dev eslint @nhcarrigan/eslint-config
|
||||
```
|
||||
</TabItem>
|
||||
<TabItem label="pnpm">
|
||||
```bash
|
||||
pnpm install --save-dev eslint @nhcarrigan/eslint-config
|
||||
```
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
:::caution[Warning!]
|
||||
This package requires ESLint v9 and uses a flat config!
|
||||
:::
|
||||
|
||||
### 1.2. Usage
|
||||
|
||||
To begin using this package, you'll need to create an `eslint.config.js` file in the root of your project. To load our configuration exactly as is with no changes, you can copy-paste this snippet:
|
||||
|
||||
```js
|
||||
import NaomisConfig from "@nhcarrigan/eslint-config";
|
||||
|
||||
export default [...NaomisConfig];
|
||||
```
|
||||
|
||||
Then, to run it, you'll likely want to define a `package.json` script that covers your files. Our configuration can run against:
|
||||
|
||||
- `src/**/*.ts`
|
||||
- `src/**/*.tsx`
|
||||
- `e2e/**/*.spec.ts` (These should be Playwright tests)
|
||||
- `test/**/*.spec.ts` (These should be Vitest tests)
|
||||
|
||||
An example script for all of these might be:
|
||||
|
||||
```json
|
||||
{
|
||||
"lint": "eslint src e2e test --max-warnings 0"
|
||||
}
|
||||
```
|
||||
|
||||
### 1.3. Overriding Rules
|
||||
|
||||
You may need to tweak some of the rules to fit your needs. It is *highly* recommended that you only adjust rules on a per-file basis. You can extend the configuration by adding your rules *after* you spread our config:
|
||||
|
||||
```js
|
||||
import NaomisConfig from "@nhcarrigan/eslint-config";
|
||||
|
||||
export default [
|
||||
...NaomisConfig,
|
||||
{
|
||||
files: ["test/**/*.spec.ts"],
|
||||
rules: {
|
||||
"import/no-extraneous-dependencies": "off",
|
||||
"max-nested-callbacks": "off",
|
||||
"@typescript-eslint/consistent-type-assertions": "off",
|
||||
"max-lines-per-function": "off",
|
||||
},
|
||||
},
|
||||
];
|
||||
```
|
||||
|
||||
Note that the `files` key allows you to specify which files receive the rules updates. If omitted, the rule changes will apply to *all* of your files (including those that our configuration might not check!).
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
This section is not applicable to this project.
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
|
||||
This section is not applicable to this project.
|
||||
|
||||
## 4. Contributing Documentation
|
||||
|
||||
This section is for documentation related to contributing to the Application's codebase.
|
||||
|
||||
:::danger[WAIT!]
|
||||
The addition of new rules or packages MUST be discussed on an issue and approved by the NHCarrigan team *before* a pull request is submitted. Pull requests without a related issue will be systematically closed.
|
||||
:::
|
||||
|
||||
### 4.1. Adding or Updating Rules
|
||||
|
||||
When adding new rules to an existing plugin, or changing existing rules, you should find the appropriate file for that plugin within the `src/rules` directory. Each plugin has its own file.
|
||||
|
||||
Most of these should be self-explanatory, but there are a couple of caveats:
|
||||
|
||||
- The `eslint.ts` file has a `disabledEslintRules` object. This is the **only** place where rules are explicitly turned off, and these are the rules that conflict with an enabled `@typescript-eslint` rule. If you are adding a new `@typescript-eslint` rule that has a documented conflict, be sure to add the relevant `eslint` rule here.
|
||||
- The `typescriptEslint.ts` file has a `typescriptEslintRulesWithTypes` object. Certain `@typescript-eslint` rules require type definitions to be generated. However, our project structure excludes tests from being compiled (because they are not production code), so those do not get type definitions. As such, rules that *need* type definitions must go in this object so that they can be run only on `src/**/*.ts`.
|
||||
|
||||
### 4.2. Adding Plugins
|
||||
|
||||
Adding a new plugin is a much more ambitious change. First, ensure that you are using `pnpm` and you install the plugin **as a pinned dependency**:
|
||||
|
||||
```bash
|
||||
pnpm install --save-exact <plugin>
|
||||
```
|
||||
|
||||
Additionally, if the plugin relies on another tool (such as Vitest), add that to the peer dependencies restricted to greater than the current major version.
|
||||
|
||||
Once your plugin is installed, you will need to create the rules file in `src/rules` for that plugin. Define a rules object named `<plugin name>Rules`, annotate it as `Linter.RulesRecord`, and export it. This is where your rules will go. HOWEVER:
|
||||
|
||||
Before you start adding rules, navigate to the `src/index.ts` file. Import your new rules object, **and** import the newly installed plugin.
|
||||
|
||||
Find the appropriate region for the *type* of files your plugin should run on (e.g. TypeScript, Playwright). The plugin will need to be added to the `plugins` property of that object, and here's the catch:
|
||||
|
||||
:::tip
|
||||
The key name you assign your plugin in the `config.plugins` object will become the key prefix for **all of the plugin rules**.
|
||||
|
||||
Say you install a package called `@naomi/eslint-plugin-example`, and it has a rule called `test-rule`. You might load the plugin in the config like so:
|
||||
|
||||
```json
|
||||
{
|
||||
"example": naomisExamplePlugin
|
||||
}
|
||||
```
|
||||
|
||||
THIS MEANS THAT ALL RULES FOR THIS PLUGIN ARE PREFIXED WITH `example`! Our `test-rule` would then be added to the new ruleset as `example/test-rule`.
|
||||
:::
|
||||
|
||||
Add your rules to the `rules` property of the same config object you added the plugin to.
|
||||
|
||||
If your new plugin should run on multiple file-sets, you'll need to add it to each of the objects for that file set.
|
||||
|
||||
### 4.3. Error or Warn?
|
||||
|
||||
As a general principle, we want:
|
||||
|
||||
- "Error" for rules that should not be violated even in development for temporary testing
|
||||
- "Warn" for rules that are safe to ignore while working on the code, but should not be checked in to `main`.
|
||||
|
||||
There are a couple of caveats:
|
||||
|
||||
- Stylistic rules should always be "warn".
|
||||
- Test rules should always be "warn".
|
||||
|
||||
With the exception of the `disabledEslintRules` object mentioned earlier, **no rule should be set to `off`**. We do not load any default configurations, so every rule is off by default.
|
||||
|
||||
### 4.4. Adding Tests
|
||||
|
||||
If you have not added a new plugin, the tests *should* be flexible enough to continue passing as is. If you HAVE added a new plugin:
|
||||
|
||||
- If it is a plugin that falls under the "all rules are warn" category, you'll need to create a `<plugin>.spec.ts` file and assert that all rules are set to "warn". You can refer to `playwright.spec.ts` for an example of this.
|
||||
- If it is a plugin that runs on all file sets, an assertion for it will need to be added to the `baseProperties` function in `config.spec.ts`.
|
||||
- If it is a plugin that runs on a subset of files, an assertion for it will need to be added to the appropriate `it` block for the file subset configs.
|
||||
|
||||
In any case, you will likely need to update the number of assertions and the length of the plugins objects.
|
||||
|
||||
### 4.5. Testing Changes
|
||||
|
||||
Your very first step is to confirm that `pnpm lint` works. This will start by compiling the TypeScript so it can load the updated configuration.
|
||||
|
||||
It will then run the new linter configuration *against* the linter project. If your configuration *works*, you should either see a successful run, or a failed run with specific linter issues.
|
||||
|
||||
If you instead see a failed run with ESlint errors (not linter errors, but package errors), your configuration has failed to parse and will need to be adjusted.
|
||||
|
||||
Once that has passed successfully (including resolving any linter flags), you can proceed to running `pnpm test` to ensure the existing unit tests pass (and any tests you added to cover new plugins).
|
||||
|
||||
As always, feel free to reach out to us in [Discord](https://chat.nhcarrigan.com) if you have any questions!~
|
||||
@ -1,89 +0,0 @@
|
||||
---
|
||||
title: NaomiAI
|
||||
---
|
||||
|
||||
NaomiAI, also known as Anthropic Bot, (hereinafter the "Application") is a wrapper around Anthropic's Claude model that allows you to ask questions to the LLM directly through Discord. The Application is designed to respond as if it was a magical girl.
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
:::caution[Note]
|
||||
We offer free access to this bot within [our Discord server](https://chat.nhcarrigan.com).
|
||||
|
||||
For the bot to respond to you in other servers, or via DMs, you will need to subscribe.
|
||||
:::
|
||||
|
||||
This section is for those interacting with a live instance of the Application.
|
||||
|
||||
To interact with the Application, you must send a message (in a server channel it can see and respond to, or in a direct message with the bot). The content of your message **must start with** a mention (or ping) of the bot.
|
||||
|
||||
If you are using the Application outside of our server, and have not subscribed, you will be met with a prompt to subscribe:
|
||||
|
||||
|
||||
|
||||
Otherwise, the bot will respond to your query:
|
||||
|
||||
|
||||
|
||||
To cut down on costs and provide this service at an affordable rate to you, the Application does not track any conversation history. Each message you send is treated as an isolated query and receives a response independent of any prior interactions.
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
In order to host your own instance of this application, you will need to complete a few steps.
|
||||
|
||||
### 2.1. Discord Application
|
||||
|
||||
First, you will need to go through the [Discord Developer Portal](https://discord.com/developers/applications) to set up a new Discord Bot account. The bot will not need any privileged intents.
|
||||
|
||||
Once you have the bot set up, save the token in 1password and update the `DISCORD_TOKEN` secret reference in `prod.env`.
|
||||
|
||||
You'll also need to set up a Discord webhook for debug logs. Save the URL in 1password and update the `DEBUG_HOOK` secret reference in `prod.env`.
|
||||
|
||||
### 2.2. Anthropic
|
||||
|
||||
You will need to register for an [Anthropic API account](https://console.anthropic.com). Note that this is NOT the same as a paid Claude account - they are independent services with independent billing.
|
||||
|
||||
Under the `Billing` tab, you'll need to load some credits. There is no free tier for this API.
|
||||
|
||||
Under the `API Keys` tab, generate an API key for your workspace. Save the key in 1password and update the `ANTHROPIC_TOKEN` secret reference in `prod.env`.
|
||||
|
||||
### 2.3. Monetisation
|
||||
|
||||
Whether you wish to enable monetisation or not, you'll want to update the logic in `src/index.ts` around line 239 to reflect the behaviour and values relevant to your instance.
|
||||
|
||||
For example, you may need to update the SKU in the button with the SKU for your application, or remove the entitlement logic entirely and offer the service for free.
|
||||
|
||||
### 2.4. Running the Application
|
||||
|
||||
Once you have the Application on a [configured server](/dev/servers), you'll need to run the following commands:
|
||||
|
||||
```bash
|
||||
pnpm install #install the dependencies
|
||||
pnpm build #compile the typescript into javascript
|
||||
OP_SERVICE_ACCOUNT_TOKEN=<key> pm2 start 'pnpm start' --name 'naomiai' #start the app as a PM2 process
|
||||
```
|
||||
|
||||
If you have configured everything correctly, you'll be all set!
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
|
||||
### 3.1. Privacy Policy
|
||||
|
||||
The Application does not use Discord's Message Content intent. This means that it cannot see the content of ANY message you send unless you explicitly ping the bot (or have DMed the bot directly).
|
||||
|
||||
We do not store any data related to the use of this Application.
|
||||
|
||||
The messages you consensually submit to the Application as part of normal usage are sent to Anthropic to generate the LLM response. Messages are sent anonymously, and not tied to your user account. However, the content of the message may be processed in accordance with Anthropic's Terms and Privacy Policies.
|
||||
|
||||
Your UUID is logged in our support server, with the quantity and cost of tokens consumed in your interaction with the Application. No message content or other information is logged, and these data are solely used to track usage metrics and identify a need to adjust costs.
|
||||
|
||||
## 4. Contributing Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for documentation related to contributing to the Application's codebase.
|
||||
@ -1,303 +0,0 @@
|
||||
---
|
||||
title: Task Bot
|
||||
---
|
||||
|
||||
Task Bot (hereinafter the "Application") is a user-installable Discord application which allows you to manage your tasks anywhere on Discord: in a server, in a direct message with the bot, in direct messages with your friends... The possibilities are endless.
|
||||
|
||||
Task management with this bot is an individual feature. If you need server-level task management, such as for a development team, please reach out to us in our support server to discuss pricing.
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
This section is for those interacting with a live instance of the Application.
|
||||
|
||||
### 1.1. User Interactivity
|
||||
|
||||
Interaction with the Application is done through a series of slash commands ("Commands") exposed via Discord's native UI. The primary function of the Application is to allow users to create and manage "tasks", or records of objectives that must be completed.
|
||||
|
||||
#### 1.1.1. `assign` Command
|
||||
|
||||
:::note
|
||||
This command is only available on guild-level private instances.
|
||||
:::
|
||||
|
||||
The `/assign` command allows you to assign a specific Discord user to a task. A task may have multiple assignees.
|
||||
|
||||
|
||||
|
||||
##### 1.1.1.1. Required Arguments
|
||||
|
||||
- `task`: An integer greater than 0, which is the unique identifier of the task you want to edit.
|
||||
- `assignee`: The user to assign to (or unassign from) a ticket.
|
||||
|
||||
##### 1.1.1.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.1.3. Execution
|
||||
|
||||
Once the command has been called, a database query will be made to confirm a task exists with the given `task` ID.
|
||||
|
||||
If a task does not exist, you will be notified.
|
||||
|
||||
If a task does exist, the Application will determine whether the `assignee` has been added to the task previously or not. If the `assignee` is already on the task, they will be removed. If they are not on the task, they will be assigned. You will be shown a confirmation message indicating which action the Application performed.
|
||||
|
||||
#### 1.1.2. `complete` Command
|
||||
|
||||
The `/complete` command allows you to mark a task as completed. Once completed, a task can not be uncompleted. It can still be modified and deleted.
|
||||
|
||||
|
||||
|
||||
##### 1.1.2.1. Required Arguments
|
||||
|
||||
- `task`: An integer greater than 0, which is the unique identifier of the task you want to edit.
|
||||
|
||||
##### 1.1.2.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.2.3. Execution
|
||||
|
||||
Once the command has been called, a database query will be made to confirm a task exists with the given `task` ID.
|
||||
|
||||
If a task does not exist, you will be notified.
|
||||
|
||||
If a task does exist, the Application will mark the task as completed and inform you of the success.
|
||||
|
||||
#### 1.1.3. `create` Command
|
||||
|
||||
The `/create` command allows you to create a new task.
|
||||
|
||||
|
||||
|
||||
##### 1.1.2.1. Required Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.2.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.2.3. Execution
|
||||
|
||||
Once the command has been called, the Application will construct and show a Discord-powered modal form. There are three fields you must complete.
|
||||
|
||||
|
||||
|
||||
- `TITLE`: The title of the task. This should be a short summary.
|
||||
- `DESCRIPTION`: The description of the task. This may be longer, and supports multiple lines.
|
||||
- `DUE DATE`: The date the task is due. This must be a format that can be parsed, such as `September 1, 2000`.
|
||||
|
||||
:::caution
|
||||
If the Application cannot parse your `DUE DATE` value, it will fall back to the current date. You can edit this with the `/update` command.
|
||||
:::
|
||||
|
||||
When you submit the modal form, the Application will insert a new task into the database and assign it an incremental ID. It will provide this ID to you as confirmation.
|
||||
|
||||
#### 1.1.4. `delete` Command
|
||||
|
||||
The `/delete` command allows you to "delete" a task from the database. The task record will remain present, as the incremental ID logic requires records to persist. All information will be scrubbed from the task and replaced with default values.
|
||||
|
||||
:::danger
|
||||
Deleting a task is a very destructive action. You will not be able to undo it. Our support team will not be able to undo it. The data will be purged from our records.
|
||||
:::
|
||||
|
||||
|
||||
|
||||
##### 1.1.4.1. Required Arguments
|
||||
|
||||
- `task`: The numerical identifier of the task you wish to delete.
|
||||
|
||||
##### 1.1.4.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.4.3. Execution
|
||||
|
||||
Once the command has been called, a database query will be made to confirm a task exists with the given `task` ID.
|
||||
|
||||
If a task does not exist, you will be notified.
|
||||
|
||||
If a task does exist, the Application will mark the task as `deleted`, and set the following default values:
|
||||
|
||||
```json
|
||||
{
|
||||
"assignees": [],
|
||||
"deleted": true,
|
||||
"description": "This task has been deleted.",
|
||||
"dueAt": Date,
|
||||
"priority": "deleted",
|
||||
"tags": [],
|
||||
"title": "Deleted Task",
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
You will receive confirmation when the deletion is complete.
|
||||
|
||||
#### 1.1.5. `list` Command
|
||||
|
||||
The `list` command allows you to view your tasks, optionally applying filters to narrow the results.
|
||||
|
||||
|
||||
|
||||
##### 1.1.5.1. Required Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.5.2. Optional Arguments
|
||||
|
||||
- `priority`: Only show tasks which are at this priority level. If omitted, will show all priorities.
|
||||
- `tag`: Only show tasks whose tags include this tag. If omitted, will not restrict query by any tags.
|
||||
- `completed`: Show either complete or incomplete tasks. If omitted, will show incomplete tasks.
|
||||
|
||||
**Guild-level private instances** will also be able to filter by `assignee`.
|
||||
|
||||
##### 1.1.5.3. Execution
|
||||
|
||||
The Application will construct your selected filters into a database query and use that to fetch the tasks.
|
||||
|
||||
If your query returns no tasks, the Application will notify you to adjust your filters. Otherwise, you will receive a list of task titles and IDs.
|
||||
|
||||
#### 1.1.6. `priority` Command
|
||||
|
||||
The priority command allows you to modify the priority level of a task. A task may have one of the following priorities: `Low`, `Medium`, `High`, `Critial`, and `None`.
|
||||
|
||||
|
||||
|
||||
##### 1.1.6.1. Required Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.6.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.6.3. Execution
|
||||
|
||||
Once the command has been called, a database query will be made to confirm a task exists with the given `task` ID.
|
||||
|
||||
If a task does not exist, you will be notified.
|
||||
|
||||
If a task does exist, the Application will update the `priority` field and send you a confirmation.
|
||||
|
||||
#### 1.1.7. `tag` Command
|
||||
|
||||
The `/tag` command allows you to assign a specific tag to a task. A task may have multiple tags.
|
||||
|
||||
|
||||
|
||||
##### 1.1.7.1. Required Arguments
|
||||
|
||||
- `task`: An integer greater than 0, which is the unique identifier of the task you want to edit.
|
||||
- `tag`: The case-sensitive tag to apply.
|
||||
|
||||
##### 1.1.7.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.7.3. Execution
|
||||
|
||||
Once the command has been called, a database query will be made to confirm a task exists with the given `task` ID.
|
||||
|
||||
If a task does not exist, you will be notified.
|
||||
|
||||
If a task does exist, the Application will determine whether the `tag` has been added to the task previously or not. If the `tag` is already on the task, it will be removed. If it is not on the task, it will be added. You will be shown a confirmation message indicating which action the Application performed.
|
||||
|
||||
#### 1.1.8. `update` Command
|
||||
|
||||
The `/update` command allows you to update an existing task.
|
||||
|
||||
|
||||
|
||||
##### 1.1.8.1. Required Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.8.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.8.3. Execution
|
||||
|
||||
Once the command has been called, the Application will construct and show a Discord-powered modal form. There is one field you MUST complete, and three fields you MAY complete.
|
||||
|
||||
|
||||
|
||||
- `TASK NUMBER`: The numerical identifier of the task you wish to update.
|
||||
- `TITLE`: The title of the task. This should be a short summary.
|
||||
- `DESCRIPTION`: The description of the task. This may be longer, and supports multiple lines.
|
||||
- `DUE DATE`: The date the task is due. This must be a format that can be parsed, such as `September 1, 2000`.
|
||||
|
||||
If you do not want to update a field, leave it blank and the Application will not modify it.
|
||||
|
||||
:::caution
|
||||
If the Application cannot parse your `DUE DATE` value, it will fall back to the current date.
|
||||
:::
|
||||
|
||||
When you submit the modal form, the Application will construct an update query from your fields. It will then try to update the task in the database, using the ID you provide. If it fails to find a record with that ID, it will notify you. Otherwise, it will send a confirmation message.
|
||||
|
||||
#### 1.1.9. `view` Command
|
||||
|
||||
The view command allows you to query a task by its ID and see all the information on that task.
|
||||
|
||||
|
||||
|
||||
##### 1.1.9.1. Required Arguments
|
||||
|
||||
- `id`: The numerical ID of the task you wish to view.
|
||||
|
||||
##### 1.1.9.2. Optional Arguments
|
||||
|
||||
- `null`
|
||||
|
||||
##### 1.1.9.3. Execution
|
||||
|
||||
When you run the command, the bot will fetch the task matching your specified ID from the database. If no task is found, the bot will notify you.
|
||||
|
||||
|
||||
|
||||
Otherwise, the bot will display an embed containing all of the information about that task.
|
||||
|
||||
### 1.2. User Access Permissions
|
||||
|
||||
:::danger
|
||||
The Application does not perform any permission validation against users calling commands. All commands are available to all users.
|
||||
:::
|
||||
|
||||
:::note
|
||||
User-access permissions are only available on guild-level private instances. The user-level public application will only allow you to manage tasks you have created.
|
||||
:::
|
||||
|
||||
If you need to restrict access to specific commands based on a user's permission levels, you can do so through Discord's native UI.
|
||||
|
||||
|
||||
|
||||
This functionality will allow you to hide commands from users with or without specific roles, or grant scoped access to individual commands and channels. For more instructions on how to leverage this tool, please review [Discord's support article for command permissions](https://support.discord.com/hc/en-us/articles/4644915651095-Command-Permissions).
|
||||
|
||||
### 1.3. Application Access Permissions
|
||||
|
||||
The Application should not require any specific Discord permissions to function in your community.
|
||||
|
||||
### 1.4. Errors
|
||||
|
||||
We strive to deliver reliable and quality applications, but we are not perfect. If the Application generates an error, it will provide you with a Snowflake ID and a link to [our support server](https://chat.nhcarrigan.com).
|
||||
|
||||
When you join the server and share the ID with us, we will be able to look up the specific log and determine the cause of the error.
|
||||
|
||||
Note that not all errors are caused by the Application. Errors can occur for many reasons, including misconfigured permissions on the user side, external platform outages, and more. Our support team will be happy to assist you with any errors that you encounter, but we kindly ask that you demonstrate patience toward our team (many of whom are volunteers).
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
@ -1,117 +0,0 @@
|
||||
---
|
||||
title: Translation Bot
|
||||
---
|
||||
|
||||
Translation Bot (hereinafter the "Application") is a multi-platform application that allows quick and seamless translation of user messages.
|
||||
|
||||
## 1. User Documentation
|
||||
|
||||
This section is for those interacting with a live instance of the application.
|
||||
|
||||
### 1.1. Discord Integration
|
||||
|
||||
The Application is available as a user-installable Discord integration. Once installed, it becomes available for you to use in any server.
|
||||
|
||||
:::tip
|
||||
The command names and descriptions should all be localised to the language you have your Discord client set to.
|
||||
:::
|
||||
|
||||
All interactions with this Application are "ephemeral", meaning that only you will see the result. This leaves you free to use the Application in whatever way you need without disrupting your colleagues.
|
||||
|
||||
[Install the Discord integration](https://discord.com/oauth2/authorize?client_id=1293778694292115457)
|
||||
|
||||
#### 1.1.1. Setting Your Language
|
||||
|
||||
|
||||
|
||||
The `/language` command allows you to configure your target language. The language you set here will be the language messages are translated into.
|
||||
|
||||
|
||||
|
||||
#### 1.1.2. Translating Messages
|
||||
|
||||
|
||||
|
||||
To translate a message, right click on the message to open the context menu. Select the `translate` command, and the bot will translate the message you selected.
|
||||
|
||||
|
||||
|
||||
### 1.2. Slack Integration
|
||||
|
||||
The Application is available as a workspace-level Slack integration. Once installed, it becomes available for anyone to use in the workspace.
|
||||
|
||||
All interactions with this Application are "ephemeral", meaning that only you will see the result. This leaves you free to use the Application in whatever way you need without disrupting your colleagues.
|
||||
|
||||
[Install the Slack integration](https://trans-slack.nhcarrigan.com/slack/install)
|
||||
|
||||
#### 1.2.1. Setting Your Language
|
||||
|
||||
|
||||
|
||||
The `/lang` command allows you to configure your target language. The language you set here will be the language messages are translated into.
|
||||
|
||||
|
||||
|
||||
#### 1.1.2. Translating Messages
|
||||
|
||||
|
||||
|
||||
To translate a message, right click on the message to open the context menu. Select `More message actions`, then the `translate` command, and the bot will translate the message you selected.
|
||||
|
||||
|
||||
|
||||
### 1.3. Language Codes
|
||||
|
||||
The commands to toggle your language require a two-character language code. You may refer to the table below to identify the code for your language.
|
||||
|
||||
:::note
|
||||
The list of languages we support is determined by the languages supported on each platform AND the languages supported by our translation service.
|
||||
:::
|
||||
|
||||
| Language | Code |
|
||||
| --------------------- | ---- |
|
||||
| English | "en" |
|
||||
| Bulgarian | "bg" |
|
||||
| Czech | "cs" |
|
||||
| Danish | "da" |
|
||||
| German | "de" |
|
||||
| Greek | "el" |
|
||||
| Spanish | "es" |
|
||||
| Finnish | "fi" |
|
||||
| French | "fr" |
|
||||
| Hindi | "hi" |
|
||||
| Hungarian | "hu" |
|
||||
| Italian | "it" |
|
||||
| Japanese | "ja" |
|
||||
| Korean | "ko" |
|
||||
| Lithuanian | "lt" |
|
||||
| Dutch | "nl" |
|
||||
| Norwegian | "no" |
|
||||
| Polish | "pl" |
|
||||
| Portuguese | "pt" |
|
||||
| Romanian | "ro" |
|
||||
| Russian | "ru" |
|
||||
| Swedish | "sv" |
|
||||
| Thai | "th" |
|
||||
| Turkish | "tr" |
|
||||
| Ukrainian | "uk" |
|
||||
| Chinese (Simplified) | "zh" |
|
||||
| Chinese (Traditional) | "zt" |
|
||||
|
||||
## 2. Technical Documentation
|
||||
|
||||
:::note
|
||||
This section is coming soon!
|
||||
:::
|
||||
|
||||
This section is for those interested in running their own instance of the Application.
|
||||
|
||||
## 3. Legal Documentation
|
||||
|
||||
This section is for expansions to our legal policies specific to the Application.
|
||||
|
||||
### 3.1. Data Collection
|
||||
|
||||
The only Data the Application collects and stores is a map of your unique identifier (UUID) for each platform and the target language you have selected for the platform.
|
||||
|
||||
Message data and contents are NEVER stored by our application.
|
||||
@ -1,19 +0,0 @@
|
||||
---
|
||||
title: Join Our Staff Team
|
||||
---
|
||||
|
||||
## 1. Volunteer Positions
|
||||
|
||||
Unless explicitly stated otherwise in a separate written agreement, all positions within our organization are on a voluntary basis. No compensation, monetary or otherwise, should be expected for these roles.
|
||||
|
||||
## 2. Application Process
|
||||
|
||||
If you feel ready to apply to join our team, please complete the [application form](https://nhcarrigan.com/apply).
|
||||
|
||||
## 3. Legal Disclaimer
|
||||
|
||||
This document does not constitute an offer of employment or a binding contract. Our organization reserves the right to modify, suspend, or terminate any volunteer position or the mentorship programme at any time, without prior notice.
|
||||
|
||||
By engaging in any volunteer activities you acknowledge that you have read, understood, and agree to these terms.
|
||||
|
||||
For any questions or clarifications regarding these policies, please contact us on Discord.
|
||||
@ -1,939 +0,0 @@
|
||||
---
|
||||
title: Staff Handbook
|
||||
---
|
||||
|
||||
Welcome to our organization. This Staff Handbook serves as a comprehensive guide to our policies, procedures, and expectations. It is designed to help you understand your role in our community and how you can contribute to our collective success.
|
||||
|
||||
We rely on every staff member, regardless of position, to help keep our community running smoothly and efficiently. Your dedication, skills, and adherence to our standards are crucial in achieving our organizational goals.
|
||||
|
||||
By familiarizing yourself with this handbook and adhering to its guidelines, you play a vital role in maintaining the integrity and effectiveness of our organization. Your commitment to these principles helps ensure a positive, productive, and harmonious work environment for all.
|
||||
|
||||
## 1. Activity Requirements
|
||||
|
||||
### 1.1 Flexible Engagement
|
||||
|
||||
We recognize and deeply appreciate that our staff members are volunteers dedicating their time and effort to support our community. As such, we do not impose rigid activity quotas or specific engagement levels.
|
||||
|
||||
### 1.2 Communication of Extended Absences
|
||||
|
||||
While we maintain a flexible approach to activity, we kindly request that you inform us of any anticipated absences:
|
||||
|
||||
- For absences exceeding one week, please notify the team via the `#staff-chat` channel on Discord.
|
||||
- This communication helps us manage workload distribution and ensures continued smooth operation of our community.
|
||||
|
||||
### 1.3 Extended Inactivity
|
||||
|
||||
In cases of prolonged inactivity:
|
||||
|
||||
- If you are inactive for more than one month without prior communication, we may remove you from the active staff team.
|
||||
- This policy helps maintain an engaged and responsive staff roster.
|
||||
- Please note that removal due to inactivity is not punitive and does not reflect negatively on your contributions.
|
||||
|
||||
### 1.4 Returning to the Team
|
||||
|
||||
We value your contributions and understand that life circumstances can change:
|
||||
|
||||
- If you've been removed due to inactivity, you are always welcome to rejoin the staff team when your schedule permits.
|
||||
- To rejoin, please contact an admin.
|
||||
|
||||
### 1.5 Balancing Commitments
|
||||
|
||||
We encourage you to balance your volunteer work with your personal life and other commitments:
|
||||
|
||||
- Your well-being is important to us. Never feel pressured to overextend yourself.
|
||||
- If you find your role becoming stressful or overly time-consuming, please discuss this with an admin.
|
||||
|
||||
### 1.6 Recognition of Contributions
|
||||
|
||||
While we don't set specific activity requirements, we do recognize and appreciate consistent engagement and contributions:
|
||||
|
||||
- Regular participation helps build a strong, cohesive community.
|
||||
- Outstanding contributions may be acknowledged through our staff recognition program.
|
||||
|
||||
## 2. Moderator Guidelines
|
||||
|
||||
### 2.1 Role Definition
|
||||
|
||||
As a moderator, you occupy a position of trust within our community. This role comes with additional responsibilities and tools to ensure the safety and well-being of our community members. However, it's crucial to understand that:
|
||||
|
||||
- Being a moderator does not elevate you above other community members.
|
||||
- Your role is one of service and support, not authority or superiority.
|
||||
|
||||
### 2.2 General Expectations
|
||||
|
||||
#### 2.2.1 Leading by Example
|
||||
|
||||
As moderators, you are expected to exemplify the ideal community member:
|
||||
|
||||
- Be active and engaged within the community.
|
||||
- Strictly adhere to all community rules and guidelines.
|
||||
- Demonstrate a welcoming and inclusive attitude towards all members, especially newcomers.
|
||||
|
||||
#### 2.2.2 Balancing Roles
|
||||
|
||||
Remember that you are both a moderator and a community member:
|
||||
|
||||
- Not every interaction requires a moderation action.
|
||||
- Engage in regular social interactions with fellow community members.
|
||||
- Maintain a balance between your moderator duties and personal enjoyment within the community.
|
||||
|
||||
#### 2.2.3 Platform Familiarity
|
||||
|
||||
Our community spans multiple platforms:
|
||||
|
||||
- You are entrusted with maintaining all our platforms, but you're not expected to be an expert on all of them.
|
||||
- Focus on moderating platforms you're comfortable with.
|
||||
- Seek assistance or guidance from fellow moderators when dealing with unfamiliar platforms.
|
||||
|
||||
### 2.3 Conduct Guidelines
|
||||
|
||||
#### 2.3.1 Professionalism
|
||||
|
||||
Maintain a professional demeanour in all interactions:
|
||||
|
||||
- Remain calm and objective, especially in challenging situations.
|
||||
- Avoid engaging in or escalating conflicts.
|
||||
- Use appropriate language and tone at all times.
|
||||
|
||||
#### 2.3.2 Fairness and Consistency
|
||||
|
||||
Apply rules and take actions consistently:
|
||||
|
||||
- Treat all community members equally, regardless of their status or your personal feelings.
|
||||
- Make decisions based on community guidelines, not personal preferences.
|
||||
|
||||
#### 2.3.3 Transparency
|
||||
|
||||
Be open about your actions as a moderator:
|
||||
|
||||
- Clearly explain the reasons for any moderation decisions when appropriate.
|
||||
- Be willing to discuss your actions with other moderators or admins if questions arise.
|
||||
|
||||
### 2.4 Collaboration and Support
|
||||
|
||||
#### 2.4.1 Team Communication
|
||||
|
||||
Maintain open lines of communication with your fellow moderators:
|
||||
|
||||
- Use designated channels (e.g., `#staff-chat`) to discuss moderation issues.
|
||||
- Share experiences and seek advice when facing challenging situations.
|
||||
|
||||
#### 2.4.2 Continuous Learning
|
||||
|
||||
Stay informed and improve your moderation skills:
|
||||
|
||||
- Keep up-to-date with any changes to community guidelines or moderation policies.
|
||||
- Participate in any provided training or skill-sharing sessions.
|
||||
|
||||
#### 2.4.3 Escalation Protocol
|
||||
|
||||
Know when and how to escalate issues:
|
||||
|
||||
- Identify situations that require input from administrators.
|
||||
- Follow established procedures for escalating complex or sensitive matters.
|
||||
|
||||
### 2.2 Discord Moderation Guidelines
|
||||
|
||||
#### 2.2.1 General Principles
|
||||
|
||||
- Always approach situations calmly and objectively.
|
||||
- Escalate gradually: Start with the least severe action necessary and progress as needed.
|
||||
- Document all moderation actions using the mod bot for consistency and future reference.
|
||||
|
||||
#### 2.2.2 Warning a Member
|
||||
|
||||
Use warnings for minor infractions or first-time offences.
|
||||
|
||||
**When to Warn:**
|
||||
- Mild spam (e.g., posting the same message a few times)
|
||||
- Non-discriminatory insults (e.g., "You're a jerk")
|
||||
- Minor rule violations
|
||||
|
||||
**How to Warn:**
|
||||
Use the mod bot command:
|
||||
```txt
|
||||
/warn @user [reason for warning]
|
||||
```
|
||||
|
||||
**Follow-up:**
|
||||
- Monitor the member's behavior after the warning.
|
||||
- If behavior improves, no further action is needed.
|
||||
- If issues persist, consider stronger measures.
|
||||
|
||||
#### 2.2.3 Kicking a Member
|
||||
|
||||
Kicking is a temporary removal that allows the member to rejoin.
|
||||
|
||||
**When to Kick:**
|
||||
- Repeated minor infractions after warnings
|
||||
- Arguing with moderators
|
||||
- Moderate spam
|
||||
- Non-severe rule violations
|
||||
|
||||
**How to Kick:**
|
||||
Use the mod bot command:
|
||||
```txt
|
||||
/kick @user [reason for kick]
|
||||
```
|
||||
|
||||
**Follow-up:**
|
||||
- Monitor if the user returns and their subsequent behavior.
|
||||
- Be prepared to take stronger action if issues continue upon their return.
|
||||
|
||||
#### 2.2.4 Banning a Member
|
||||
|
||||
Banning is the most severe action and should be used judiciously.
|
||||
|
||||
**When to Ban:**
|
||||
- Severe rule violations
|
||||
- Repeated offences after warnings and kicks
|
||||
- Malicious actions (e.g., raiding, doxxing, severe harassment)
|
||||
|
||||
**How to Ban:**
|
||||
Use the mod bot command:
|
||||
```txt
|
||||
/ban @user [reason for ban]
|
||||
```
|
||||
|
||||
**Important Considerations:**
|
||||
- Discord bans are IP-specific.
|
||||
- The member cannot rejoin until the ban is lifted.
|
||||
- Always double-check the user and reason before banning.
|
||||
- For permanent bans, consult with administrators.
|
||||
|
||||
#### 2.2.5 Moderation Best Practices
|
||||
|
||||
1. **Communication:** Clearly explain the reason for moderation actions to the affected member when possible.
|
||||
|
||||
2. **Consistency:** Apply rules uniformly to all members.
|
||||
|
||||
3. **Documentation:** Always use the mod bot for actions to ensure proper logging.
|
||||
|
||||
4. **Discretion:** Use your judgment. Context matters in deciding appropriate actions.
|
||||
|
||||
5. **Team Coordination:** Discuss unclear situations with fellow moderators.
|
||||
|
||||
6. **Appeals Process:** Be aware of the process for members to appeal moderation decisions.
|
||||
|
||||
7. **Continuous Learning:** Stay updated on any changes to community guidelines or moderation policies.
|
||||
|
||||
### 2.3 Twitch Moderation
|
||||
|
||||
#### 2.3.1 General Responsibilities
|
||||
|
||||
- Monitor chat actively during live streams.
|
||||
- Enforce our community rules and Twitch's Terms of Service.
|
||||
- Assist viewers with questions and foster a welcoming atmosphere.
|
||||
- Support the streamer by managing chat flow and addressing issues promptly.
|
||||
|
||||
#### 2.3.2 Chat Moderation Tools
|
||||
|
||||
Familiarize yourself with Twitch's built-in moderation tools:
|
||||
|
||||
1. **Timeout:** Temporarily prevents a user from chatting.
|
||||
2. **Ban:** Permanently removes a user from the channel.
|
||||
3. **Delete Message:** Removes a single message from chat.
|
||||
4. **Slow Mode:** Limits how often users can send messages.
|
||||
5. **Followers-Only Mode:** Restricts chat to followers.
|
||||
6. **Subscribers-Only Mode:** Limits chat to subscribers.
|
||||
7. **Unique-Chat Mode:** Prevents users from posting duplicate messages.
|
||||
|
||||
#### 2.3.3 Moderation Actions
|
||||
|
||||
##### 2.3.3.1 Warnings
|
||||
|
||||
- For minor infractions, start with a verbal warning in chat.
|
||||
- Use clear, concise language to explain the issue.
|
||||
|
||||
Example: "@User, please avoid spamming emotes. Next time may result in a timeout."
|
||||
|
||||
##### 2.3.3.2 Timeouts
|
||||
|
||||
Use timeouts for more serious or repeated minor offences.
|
||||
|
||||
- First offence: 5-minute timeout
|
||||
- Second offence: 10-minute timeout
|
||||
- Third offence: 30-minute timeout
|
||||
|
||||
To timeout: `/timeout @username [duration]`
|
||||
|
||||
##### 2.3.3.3 Bans
|
||||
|
||||
Reserve bans for severe violations or persistent problematic behavior.
|
||||
|
||||
To ban: `/ban @username`
|
||||
|
||||
Always document the reason for bans in your moderator notes or designated channel.
|
||||
|
||||
#### 2.3.4 Specific Situations
|
||||
|
||||
1. **Spam:** Use timeouts, increasing duration for repeat offences.
|
||||
2. **Hate Speech/Discrimination:** Immediate ban and report to Twitch.
|
||||
3. **Excessive Backseat Gaming:** Start with a warning, then short timeout if it continues.
|
||||
4. **Spoilers:** Delete message and issue a warning.
|
||||
5. **Self-Promotion:** Remove message and warn. Timeout for repeated offences.
|
||||
6. **Bot Attacks:** Enable followers-only or subscribers-only mode temporarily.
|
||||
|
||||
#### 2.3.5 Communication
|
||||
|
||||
- Coordinate with other moderators via a separate chat or Discord channel.
|
||||
- Inform the streamer of any significant issues or decisions made during the stream.
|
||||
- Be prepared to explain moderation actions if questioned by viewers.
|
||||
|
||||
#### 2.3.6 Raids and Hosting
|
||||
|
||||
- Welcome incoming raids positively.
|
||||
- Be extra vigilant during raids to catch any potential influx of rule-breaking behavior.
|
||||
- Assist in shouting out and thanking raiders/hosts as appropriate.
|
||||
|
||||
#### 2.3.7 Clips and Highlights
|
||||
|
||||
- Monitor clips created during streams for any inappropriate content.
|
||||
- Report or delete any clips that violate our guidelines or Twitch ToS.
|
||||
|
||||
#### 2.3.8 Post-Stream Duties
|
||||
|
||||
- Review any user reports or issues that occurred during the stream.
|
||||
- Discuss any notable incidents or concerns with the moderation team.
|
||||
- Provide feedback or suggestions for improving stream moderation.
|
||||
|
||||
### 2.4 Reddit Moderation
|
||||
|
||||
#### 2.4.1 General Responsibilities
|
||||
|
||||
- Regularly check the moderation queue for reported posts and comments.
|
||||
- Enforce subreddit rules and Reddit's content policy.
|
||||
- Engage with the community to encourage positive interactions.
|
||||
- Collaborate with other moderators to maintain consistency.
|
||||
|
||||
#### 2.4.2 Moderation Tools
|
||||
|
||||
Familiarize yourself with Reddit's moderation tools:
|
||||
|
||||
1. **Remove:** Takes down a post or comment from public view.
|
||||
2. **Spam:** Removes content and marks it as spam.
|
||||
3. **Approve:** Manually approves content, overriding auto-mod actions.
|
||||
4. **Lock:** Prevents further comments on a post.
|
||||
5. **Sticky:** Pins important posts to the top of the subreddit.
|
||||
6. **Distinguish:** Marks your comment as coming from a moderator.
|
||||
7. **Ban:** Prevents a user from posting or commenting in the subreddit.
|
||||
|
||||
#### 2.4.3 Moderation Actions
|
||||
|
||||
##### 2.4.3.1 Content Removal
|
||||
|
||||
- Remove posts and comments that violate subreddit rules or Reddit's content policy.
|
||||
- Always provide a reason for removal, using removal reasons or commenting.
|
||||
|
||||
##### 2.4.3.2 User Warnings
|
||||
|
||||
- For minor infractions, issue a warning via modmail or comment.
|
||||
- Document warnings in mod notes for future reference.
|
||||
|
||||
##### 2.4.3.3 Temporary Bans
|
||||
|
||||
- Use for repeated minor offences or more serious rule violations.
|
||||
- Typical durations: 3 days, 7 days, 14 days, 30 days.
|
||||
- Always include the reason and duration in the ban message.
|
||||
|
||||
##### 2.4.3.4 Permanent Bans
|
||||
|
||||
- Reserve for severe violations or persistent problematic behavior.
|
||||
- Always provide a clear reason in the ban message.
|
||||
- Allow for appeal process through modmail.
|
||||
|
||||
#### 2.4.4 Specific Situations
|
||||
|
||||
1. **Spam:** Remove and mark as spam. Temp ban for repeated offences.
|
||||
2. **Harassment:** Remove, warn, and escalate to temp or permanent ban as needed.
|
||||
3. **Off-topic Posts:** Remove and direct users to appropriate subreddits.
|
||||
4. **Reposts:** Remove recent reposts, with a comment explaining the removal.
|
||||
5. **Trolling:** Remove comments, warn, and ban for persistent behavior.
|
||||
6. **Vote Manipulation:** Report to Reddit admins and remove content.
|
||||
|
||||
#### 2.4.5 AutoModerator
|
||||
|
||||
- Familiarize yourself with our AutoModerator configuration.
|
||||
- Regularly review and update AutoMod rules as needed.
|
||||
- Check the moderation log to ensure AutoMod is functioning correctly.
|
||||
|
||||
#### 2.4.6 Flair Management
|
||||
|
||||
- Ensure posts have the proper flair.
|
||||
- Assist users with setting up user flairs if applicable.
|
||||
|
||||
#### 2.4.7 Modmail
|
||||
|
||||
- Respond to modmail inquiries promptly and professionally.
|
||||
- Use templates for common responses to ensure consistency.
|
||||
- Escalate complex issues to admins when necessary.
|
||||
|
||||
#### 2.4.8 Community Engagement
|
||||
|
||||
- Participate in discussions to set a positive example.
|
||||
- Use distinguish feature judiciously when speaking officially as a moderator.
|
||||
- Create and maintain community resources (FAQ, wiki, etc.).
|
||||
|
||||
#### 2.4.9 Coordinating with the Mod Team
|
||||
|
||||
- Use private moderator channels or subreddits for team discussions.
|
||||
- Participate in periodic mod team meetings or discussions.
|
||||
- Propose and discuss potential rule or policy changes.
|
||||
|
||||
#### 2.4.10 Handling Sensitive Content
|
||||
|
||||
- Remove adult-only content.
|
||||
- For controversial topics, monitor discussions closely and lock if necessary.
|
||||
- Report any illegal content to Reddit admins immediately.
|
||||
|
||||
### 2.5 Codeberg Moderation
|
||||
|
||||
#### 2.5.1 General Responsibilities
|
||||
|
||||
- Monitor repository activities, including issues, pull requests, and discussions.
|
||||
- Enforce our organization's code of conduct and Codeberg's terms of service.
|
||||
- Assist contributors with questions and foster a welcoming atmosphere for new participants.
|
||||
- Manage repository settings and access controls.
|
||||
|
||||
#### 2.5.2 Moderation Tools
|
||||
|
||||
Familiarize yourself with Codeberg's moderation features:
|
||||
|
||||
1. **Issue Management:** Open, close, label, and moderate issues.
|
||||
2. **Pull Request Review:** Review, comment on, and merge or reject pull requests.
|
||||
3. **Commit Management:** Revert or cherry-pick commits if necessary.
|
||||
4. **User Management:** Manage collaborator access and block problematic users.
|
||||
5. **Repository Settings:** Adjust visibility, branch protection, and other settings.
|
||||
|
||||
#### 2.5.3 Moderation Actions
|
||||
|
||||
##### 2.5.3.1 Issue and Pull Request Moderation
|
||||
|
||||
- Review and triage new issues and pull requests promptly.
|
||||
- Apply appropriate labels for categorization and priority.
|
||||
- Close or merge after thorough review and discussion.
|
||||
|
||||
##### 2.5.3.2 Comment Moderation
|
||||
|
||||
- Remove inappropriate or off-topic comments.
|
||||
- Provide warnings for minor infractions.
|
||||
- Lock discussions that become unproductive or violate guidelines.
|
||||
|
||||
##### 2.5.3.3 User Management
|
||||
|
||||
- Grant appropriate access levels to contributors.
|
||||
- Temporarily restrict access for users violating guidelines.
|
||||
- Block persistent offenders after warnings and temporary restrictions.
|
||||
|
||||
#### 2.5.4 Specific Situations
|
||||
|
||||
1. **Spam:** Remove spam content and warn the user. Block for repeated offences.
|
||||
2. **Harassment:** Remove offending content, warn the user, and escalate to blocking if behavior persists.
|
||||
3. **Off-topic Discussions:** Redirect to appropriate channels or close if irrelevant.
|
||||
4. **Code of Conduct Violations:** Address promptly, following the enforcement guidelines in the CoC.
|
||||
5. **Licensing Issues:** Ensure all contributions comply with the project's license. Remove any content that violates licensing terms.
|
||||
|
||||
#### 2.5.5 Repository Management
|
||||
|
||||
- Regularly review and update repository descriptions and README files.
|
||||
- Manage branch protection rules to maintain code quality.
|
||||
|
||||
#### 2.5.6 Collaboration and Communication
|
||||
|
||||
- Use repository discussions or a designated communication channel for project-related conversations.
|
||||
- Clearly communicate decisions and reasoning behind moderation actions.
|
||||
- Encourage constructive feedback and open dialogue among contributors.
|
||||
|
||||
#### 2.5.7 Pull Request Review Process
|
||||
|
||||
- Establish and communicate clear guidelines for PR submissions.
|
||||
- Conduct thorough code reviews, focusing on both functionality and style.
|
||||
- Provide constructive feedback and guidance, especially for new contributors.
|
||||
- Ensure all checks (e.g., tests, linting) pass before merging.
|
||||
|
||||
#### 2.5.8 Security Management
|
||||
|
||||
- Monitor and address security vulnerabilities promptly.
|
||||
- Manage responsible disclosure of security issues.
|
||||
- Regularly update dependencies to patch known vulnerabilities.
|
||||
|
||||
#### 2.5.9 Community Building
|
||||
|
||||
- Recognize and appreciate valuable contributions.
|
||||
- Organize periodic community events or sprints to boost engagement.
|
||||
- Maintain a welcoming atmosphere for contributors of all experience levels.
|
||||
|
||||
#### 2.5.10 Documentation
|
||||
|
||||
- Ensure project documentation is comprehensive and up-to-date.
|
||||
- Encourage contributors to improve documentation alongside code changes.
|
||||
- Maintain clear guidelines for project structure, coding standards, and contribution processes.
|
||||
|
||||
### 2.6 IRC Moderation
|
||||
|
||||
#### 2.6.1 General Responsibilities
|
||||
|
||||
- Monitor channel activities continuously while online.
|
||||
- Enforce channel rules and network policies.
|
||||
- Assist users with questions and foster a welcoming atmosphere.
|
||||
- Manage channel modes and user privileges as needed.
|
||||
|
||||
#### 2.6.2 IRC-Specific Moderation Tools
|
||||
|
||||
Familiarize yourself with these essential IRC commands:
|
||||
|
||||
1. `/kick <nick> [reason]`: Remove a user from the channel temporarily.
|
||||
2. `/ban <mask>`: Ban a user or hostmask from the channel.
|
||||
3. `/mute <nick>`: Prevent a user from speaking in the channel.
|
||||
4. `/topic`: Set or modify the channel topic.
|
||||
5. `/mode`: Change channel modes (e.g., moderated, invite-only).
|
||||
|
||||
#### 2.6.3 Moderation Actions
|
||||
|
||||
##### 2.6.3.1 Warnings
|
||||
|
||||
For minor infractions, start with a verbal warning in the channel.
|
||||
|
||||
Example: "Username, please avoid using excessive caps. It's considered shouting."
|
||||
|
||||
##### 2.6.3.2 Kicks
|
||||
|
||||
Use kicks for more serious or repeated minor offences.
|
||||
|
||||
To kick: `/kick username Reason for kick`
|
||||
|
||||
##### 2.6.3.3 Bans
|
||||
|
||||
Reserve bans for severe violations or persistent problematic behavior.
|
||||
|
||||
To ban: `/ban username*!*@*`
|
||||
|
||||
Always document the reason for bans in your moderation logs.
|
||||
|
||||
#### 2.6.4 Specific Situations
|
||||
|
||||
1. **Spam**: Use kicks, escalating to short-term bans for repeat offences.
|
||||
2. **Offensive Language**: Warn, then kick. Ban for repeated offences.
|
||||
3. **Flooding**: Mute temporarily, kick if behavior continues.
|
||||
4. **Off-topic Discussions**: Gently redirect to appropriate channels.
|
||||
5. **Bot Attacks**: Set channel to moderated mode (+m) temporarily.
|
||||
|
||||
#### 2.6.5 Channel Management
|
||||
|
||||
- Regularly update channel topics with important information or rules.
|
||||
- Manage channel modes to maintain order (e.g., +m for moderated discussions).
|
||||
- Coordinate with other ops to ensure consistent coverage and enforcement.
|
||||
|
||||
#### 2.6.6 User Support
|
||||
|
||||
- Be responsive to user queries about channel rules or IRC usage.
|
||||
- Guide new users on proper IRC etiquette and our community standards.
|
||||
|
||||
#### 2.6.7 Logging and Reporting
|
||||
|
||||
- Maintain logs of significant moderation actions for team review.
|
||||
- Report any serious incidents or patterns to admins.
|
||||
|
||||
### 2.7 Slack Moderation
|
||||
|
||||
#### 2.7.1 General Responsibilities
|
||||
|
||||
- Monitor channel activities across public channels.
|
||||
- Enforce workspace rules and Slack's terms of service.
|
||||
- Assist users with questions and foster a collaborative atmosphere.
|
||||
- Manage channel settings and user permissions as needed.
|
||||
|
||||
#### 2.7.2 Slack-Specific Moderation Tools
|
||||
|
||||
Familiarize yourself with these essential Slack moderation features:
|
||||
|
||||
1. Message deletion: Remove inappropriate messages.
|
||||
2. User management: Adjust user roles and permissions.
|
||||
3. Channel management: Create, archive, or modify channel settings.
|
||||
4. Workspace settings: Configure global settings for the workspace.
|
||||
|
||||
#### 2.7.3 Moderation Actions
|
||||
|
||||
##### 2.7.3.1 Warnings
|
||||
|
||||
For minor infractions, start with a private message to the user.
|
||||
|
||||
Example: "Hi [Username], please remember to use threads for extended discussions to keep the main channel clear. Thanks!"
|
||||
|
||||
##### 2.7.3.2 Message Removal
|
||||
|
||||
Use message deletion for content that violates workspace rules.
|
||||
|
||||
##### 2.7.3.3 Restricting Privileges
|
||||
|
||||
For repeated offences, consider restricting user privileges temporarily.
|
||||
|
||||
##### 2.7.3.4 Removing Users
|
||||
|
||||
In severe cases, remove users from the workspace. This should be a last resort.
|
||||
|
||||
#### 2.7.4 Specific Situations
|
||||
|
||||
1. **Off-topic discussions**: Gently redirect to appropriate channels.
|
||||
2. **Inappropriate content**: Remove the content and privately message the user.
|
||||
3. **Spam**: Delete spam messages and restrict user privileges if persistent.
|
||||
4. **Heated arguments**: Intervene privately to de-escalate and remind users of conduct guidelines.
|
||||
5. **Sensitive information sharing**: Quickly remove any posts containing sensitive data and follow up with the user.
|
||||
|
||||
#### 2.7.5 Channel Management
|
||||
|
||||
- Regularly review and update channel purposes and topics.
|
||||
- Archive inactive channels to keep the workspace organized.
|
||||
- Ensure channels have appropriate permissions set.
|
||||
|
||||
#### 2.7.6 User Support
|
||||
|
||||
- Be responsive to user queries about workspace rules or Slack usage.
|
||||
- Guide new users on Slack etiquette and our community standards.
|
||||
- Assist with general troubleshooting of Slack features.
|
||||
|
||||
#### 2.7.7 Logging and Reporting
|
||||
|
||||
- Utilize Slack's built-in logs for auditing purposes.
|
||||
- Report any serious incidents or patterns to admins.
|
||||
|
||||
#### 2.7.8 Integration Management
|
||||
|
||||
- Monitor and manage third-party app integrations to ensure they're used appropriately.
|
||||
- Be prepared to troubleshoot or disable problematic integrations.
|
||||
|
||||
|
||||
### 2.8 Matrix Moderation
|
||||
|
||||
#### 2.8.1 General Responsibilities
|
||||
|
||||
- Monitor room activities across our Matrix spaces.
|
||||
- Enforce room rules and the Matrix.org Terms of Service.
|
||||
- Assist users with questions and foster an inclusive atmosphere.
|
||||
- Manage room settings and user power levels as needed.
|
||||
|
||||
#### 2.8.2 Matrix-Specific Moderation Tools
|
||||
|
||||
Familiarize yourself with these essential Matrix moderation features:
|
||||
|
||||
1. Redaction: Remove inappropriate messages.
|
||||
1. Kick/Ban: Remove users temporarily or permanently from rooms.
|
||||
1. Room settings: Modify room join rules, visibility, and other parameters.
|
||||
|
||||
#### 2.8.3 Moderation Actions
|
||||
|
||||
##### 2.8.3.1 Warnings
|
||||
|
||||
For minor infractions, start with a private message to the user.
|
||||
|
||||
Example: "Hi @username:domain.com, please remember to stay on-topic in #general. Thanks for your cooperation!"
|
||||
|
||||
##### 2.8.3.2 Message Redaction
|
||||
|
||||
Use redaction for content that violates room rules or Matrix ToS.
|
||||
|
||||
##### 2.8.3.3 Kicks and Bans
|
||||
|
||||
In severe cases, kick or ban users from the room. Use bans sparingly and for serious violations.
|
||||
|
||||
#### 2.8.4 Specific Situations
|
||||
|
||||
1. **Spam**: Redact spam messages and lower user power level if persistent.
|
||||
2. **Offensive content**: Redact the content and privately message the user.
|
||||
3. **Off-topic discussions**: Gently redirect to appropriate rooms or spaces.
|
||||
4. **Bridged content issues**: Address issues specific to bridged networks (e.g., IRC, Discord) appropriately.
|
||||
5. **End-to-end encrypted rooms**: Be aware of limitations in moderating e2ee rooms.
|
||||
|
||||
#### 2.8.5 Room Management
|
||||
|
||||
- Regularly review and update room topics and info.
|
||||
- Manage room aliases and directory visibility.
|
||||
- Ensure rooms have appropriate power level settings.
|
||||
|
||||
#### 2.8.6 User Support
|
||||
|
||||
- Be responsive to user queries about room rules or Matrix usage.
|
||||
- Guide new users on Matrix etiquette and our community standards.
|
||||
- Assist with general troubleshooting of Matrix clients and features.
|
||||
|
||||
#### 2.8.7 Logging and Reporting
|
||||
|
||||
- Utilize Matrix's event logs for auditing purposes where necessary.
|
||||
- Report any serious incidents or patterns to admins.
|
||||
|
||||
#### 2.8.8 Federation Management
|
||||
|
||||
- Be aware of federation status with other homeservers.
|
||||
- Know how to contact admins of other homeservers if inter-server issues arise.
|
||||
|
||||
## 3. Working With Fellow Moderators
|
||||
|
||||
### 3.1 Communication Channels
|
||||
|
||||
#### 3.1.1 Primary Communication Platform
|
||||
- Discord serves as our primary communication hub for the moderation team.
|
||||
- A private `#staff-chat` channel is available for internal discussions.
|
||||
|
||||
#### 3.1.2 Use of Staff Chat
|
||||
- Utilize the `#staff-chat` channel for:
|
||||
- Discussing concerns
|
||||
- Seeking advice on handling situations
|
||||
- Requesting assistance with ongoing issues
|
||||
- Sharing relevant information with the team
|
||||
|
||||
### 3.2 Collaborative Problem-Solving
|
||||
|
||||
- Approach fellow moderators for help and insights when needed.
|
||||
- Be open to offering assistance when others request it.
|
||||
- Engage in constructive discussions to find optimal solutions.
|
||||
|
||||
### 3.3 Team Unity and Public Image
|
||||
|
||||
- Maintain a united front in public spaces.
|
||||
- Avoid disagreeing with or criticizing fellow moderators in public forums.
|
||||
- If you have concerns about a moderation action or a colleague's behavior:
|
||||
- Address the issue privately in the staff chat or through direct messages.
|
||||
- Seek resolution through open and respectful dialogue.
|
||||
|
||||
### 3.4 Conflict Resolution
|
||||
|
||||
- If unable to resolve disagreements among yourselves:
|
||||
- Escalate the matter to Naomi for guidance.
|
||||
- Present the situation objectively, providing necessary context.
|
||||
|
||||
### 3.5 Supporting Each Other
|
||||
|
||||
- Recognize that moderation can be challenging.
|
||||
- Offer emotional support and encouragement to fellow moderators.
|
||||
- Share experiences and coping strategies for dealing with difficult situations.
|
||||
|
||||
### 3.6 Knowledge Sharing
|
||||
|
||||
- Use the staff chat to share useful resources, tools, or techniques.
|
||||
- Discuss emerging trends or patterns in user behavior that may require attention.
|
||||
|
||||
### 3.7 Consistency in Moderation
|
||||
|
||||
- Regularly discuss and align on interpretation and enforcement of community rules.
|
||||
- Share examples of how you've handled specific situations to ensure consistency.
|
||||
|
||||
### 3.8 Respecting Privacy
|
||||
|
||||
- Keep all discussions in staff channels confidential.
|
||||
- Do not share private moderator conversations with community members.
|
||||
|
||||
### 3.9 Active Participation
|
||||
|
||||
- Regularly check and engage in staff communications.
|
||||
- Contribute to team discussions and decision-making processes.
|
||||
|
||||
### 3.10 Continuous Improvement
|
||||
|
||||
- Be open to feedback from fellow moderators.
|
||||
- Suggest improvements to moderation processes or team communication.
|
||||
- Participate in any team training or development activities.
|
||||
|
||||
## 4. Logging Sanctions
|
||||
|
||||
### 4.1 Discord Sanctions
|
||||
|
||||
- Moderation actions on Discord are automatically logged by our system.
|
||||
- No additional manual logging is required for Discord-specific actions.
|
||||
|
||||
### 4.2 Sanctions on Other Platforms
|
||||
|
||||
For all platforms other than Discord, manual logging is necessary:
|
||||
|
||||
#### 4.2.1 Logging Channel
|
||||
- Use the `#mod-logs` channel in our Discord community for logging all non-Discord sanctions.
|
||||
|
||||
#### 4.2.2 Required Information
|
||||
When logging a sanction, include the following details:
|
||||
|
||||
1. Platform: Specify the platform where the action was taken (e.g., Twitch, Reddit, Codeberg).
|
||||
2. Username: Provide the exact username or handle of the sanctioned member.
|
||||
3. Reason: Clearly state the reason for the sanction, referencing specific rule violations if applicable.
|
||||
4. Evidence: Include or describe any relevant evidence supporting the action taken.
|
||||
5. Action Taken: Specify the type of sanction (e.g., warning, temporary ban, permanent ban).
|
||||
6. Duration: For temporary sanctions, note the duration.
|
||||
|
||||
#### 4.2.3 Logging Format
|
||||
Use the following format for consistency:
|
||||
|
||||
```
|
||||
Platform: [Platform Name]
|
||||
User: [Username]
|
||||
Action: [Type of Sanction]
|
||||
Duration: [If applicable]
|
||||
Reason: [Detailed explanation]
|
||||
Evidence: [Description or link to evidence]
|
||||
```
|
||||
|
||||
### 4.3 Best Practices for Sanction Logging
|
||||
|
||||
1. **Timeliness**: Log the sanction as soon as possible after taking action.
|
||||
2. **Objectivity**: Stick to facts and avoid personal opinions in the log.
|
||||
3. **Clarity**: Ensure your log entry is clear and understandable to other moderators.
|
||||
4. **Completeness**: Include all relevant information, even if it seems minor.
|
||||
5. **Confidentiality**: Do not share logs outside of the moderation team.
|
||||
|
||||
### 4.4 Using Logged Information
|
||||
|
||||
- Regularly review logs to identify patterns or recurring issues.
|
||||
- Use logged information to ensure consistent application of rules across platforms.
|
||||
- Refer to logs when discussing moderation strategies or updating community guidelines.
|
||||
|
||||
### 4.5 Correcting or Updating Logs
|
||||
|
||||
- If you need to correct or update a logged sanction, do so in the same channel.
|
||||
- Clearly mark your message as an update or correction to a previous log entry.
|
||||
|
||||
### 4.6 Reviewing Logs
|
||||
|
||||
- Administrators should periodically review sanction logs to ensure:
|
||||
- Consistency in moderation across the team
|
||||
- Proper documentation of all actions
|
||||
- Identification of any trends or areas needing attention
|
||||
|
||||
## 5. User Support
|
||||
|
||||
### 3.1 Role in User Experience
|
||||
|
||||
As a member of our team, you play a crucial role in ensuring a positive and smooth user experience across all our platforms. Your ability to provide timely and accurate support is essential to our community's satisfaction and growth.
|
||||
|
||||
### 5.2 Knowledge Base
|
||||
|
||||
- Familiarize yourself with most of our projects to answer a wide range of questions.
|
||||
- Stay updated on recent changes or updates to our projects.
|
||||
- Utilize available resources (documentation, FAQs, wikis) to assist users effectively.
|
||||
|
||||
### 5.3 Handling User Inquiries
|
||||
|
||||
#### 5.3.1 Immediate Assistance
|
||||
- Respond promptly to users seeking help on any of our platforms.
|
||||
- Provide clear, concise answers to questions you're confident about.
|
||||
|
||||
#### 5.3.2 Complex Inquiries
|
||||
- For questions you're unsure about, don't hesitate to seek help.
|
||||
- Inform the user that you're looking into their issue to manage expectations.
|
||||
|
||||
### 5.4 Collaborative Problem-Solving
|
||||
|
||||
- Utilize the staff chat in Discord for discussing complex user questions.
|
||||
- Engage with fellow staff members to collaboratively find solutions.
|
||||
- Share knowledge and insights to improve the team's overall support capabilities.
|
||||
|
||||
### 5.5 Follow-up
|
||||
|
||||
- After providing a solution, check if the user's issue has been fully resolved.
|
||||
- Encourage users to reach out again if they need further assistance.
|
||||
|
||||
### 5.6 Continuous Improvement
|
||||
|
||||
- Keep track of common user issues and suggest improvements to our documentation or user interfaces.
|
||||
- Share insights gained from user interactions with the rest of the team to enhance our overall support quality.
|
||||
|
||||
## 6. Contributor Support
|
||||
|
||||
### 6.1 Welcoming New Contributors
|
||||
|
||||
- Greet new contributors warmly when they show interest in our projects.
|
||||
- Provide guidance on where to find our contribution guidelines and code of conduct.
|
||||
- Offer assistance in identifying suitable first issues or tasks for newcomers.
|
||||
|
||||
### 6.2 Technical Assistance
|
||||
|
||||
- Help contributors set up their development environments.
|
||||
- Provide explanations or resources for understanding our project structure and coding standards.
|
||||
- Assist with version control (e.g. git) usage if needed.
|
||||
|
||||
### 6.3 Code Review Support
|
||||
|
||||
- Offer constructive feedback on pull requests or proposed changes.
|
||||
- Explain the reasoning behind any requested modifications.
|
||||
- Guide contributors through the process of updating their submissions.
|
||||
|
||||
### 6.4 Documentation Support
|
||||
|
||||
- Assist contributors in locating or updating project documentation.
|
||||
- Encourage and guide contributors who wish to improve our documentation.
|
||||
- Provide feedback on proposed documentation changes.
|
||||
|
||||
### 6.5 Issue Clarification
|
||||
|
||||
- Help contributors understand the scope and requirements of open issues.
|
||||
- Provide additional context or clarification on feature requests or bug reports.
|
||||
|
||||
### 6.6 Communication Channels
|
||||
|
||||
- Direct contributors to appropriate communication channels (e.g., mailing lists, chat rooms, forums) for project-specific discussions.
|
||||
- Monitor these channels to provide timely responses to contributor queries.
|
||||
|
||||
### 6.7 Mentoring
|
||||
|
||||
- Offer mentorship to promising contributors who show consistent interest.
|
||||
- Provide guidance on best practices, advanced topics, and project goals.
|
||||
|
||||
### 6.8 Recognition and Encouragement
|
||||
|
||||
- Acknowledge and thank contributors for their efforts, regardless of the outcome.
|
||||
- Highlight significant contributions in project updates or community announcements.
|
||||
|
||||
### 6.9 Conflict Resolution
|
||||
|
||||
- Mediate any disagreements between contributors professionally and impartially.
|
||||
- Ensure discussions remain constructive and aligned with our code of conduct.
|
||||
|
||||
### 6.10 Continuous Improvement
|
||||
|
||||
- Regularly review and update our contribution processes based on feedback.
|
||||
- Seek input from contributors on how to improve their experience.
|
||||
|
||||
## 7. Cross-Platform Access
|
||||
|
||||
### 7.1 Eligibility for Cross-Platform Roles
|
||||
|
||||
- Once you have been selected for a staff position on any of our platforms, you become eligible to request staff access on additional platforms.
|
||||
- This opportunity is open to all current staff members in good standing.
|
||||
|
||||
### 7.2 Requesting Additional Platform Access
|
||||
|
||||
- If you wish to expand your staff role to other platforms:
|
||||
- Express your interest to an admin or through the designated channel for such requests.
|
||||
- Specify which additional platform(s) you'd like to moderate.
|
||||
- Briefly explain why you're interested in moderating these additional platforms.
|
||||
|
||||
### 7.3 Approval Process
|
||||
|
||||
- Requests for additional platform access will be reviewed by the admin team.
|
||||
- Factors considered in the approval process may include:
|
||||
- Your performance in your current role
|
||||
- Your familiarity with the requested platform
|
||||
- The current staffing needs on that platform
|
||||
|
||||
### 7.4 Training and Onboarding
|
||||
|
||||
- If approved for a cross-platform role, you may be required to undergo platform-specific training.
|
||||
- Familiarize yourself with any unique rules or moderation tools for the new platform.
|
||||
|
||||
### 7.5 Responsibilities of Cross-Platform Staff
|
||||
|
||||
- Maintain consistency in rule enforcement across all platforms you moderate.
|
||||
- Be aware of platform-specific nuances and adjust your approach accordingly.
|
||||
- Help bridge communication between different platform teams.
|
||||
|
||||
### 7.6 Benefits of Cross-Platform Moderation
|
||||
|
||||
- Provides a more cohesive user experience across our community's various platforms.
|
||||
- Allows for more efficient sharing of information and moderation strategies.
|
||||
- Enhances your skills and versatility as a moderator.
|
||||
|
||||
### 7.7 Balancing Responsibilities
|
||||
|
||||
- Ensure that taking on additional platforms does not negatively impact your performance on your original platform.
|
||||
- Communicate with the moderation team if you feel overwhelmed or need to scale back your responsibilities.
|
||||
|
||||
### 7.8 Periodic Review
|
||||
|
||||
- Your cross-platform roles will be periodically reviewed to ensure effective moderation across all assigned platforms.
|
||||
- Feedback and additional training may be provided as needed.
|
||||
1
src/env.d.ts
vendored
1
src/env.d.ts
vendored
@ -1 +0,0 @@
|
||||
/// <reference path="../.astro/types.d.ts" />
|
||||
@ -1,8 +0,0 @@
|
||||
@font-face {
|
||||
font-family: "OpenDyslexic Mono";
|
||||
src: url("https://cdn.nhcarrigan.com/fonts/OpenDyslexicMono-Regular.otf") format("opentype");
|
||||
}
|
||||
|
||||
* {
|
||||
font-family: "OpenDyslexic Mono", monospace !important;
|
||||
}
|
||||
@ -1,68 +0,0 @@
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
<!--
|
||||
We used to use Docsify, so rather than breaking links we borrowed this from freeCodeCamp
|
||||
to make our things work.
|
||||
-->
|
||||
<script>
|
||||
document.addEventListener('DOMContentLoaded', () => {
|
||||
const { hash } = window.location;
|
||||
if (!hash || hash === '#/' || hash === '#') {
|
||||
window.location.replace('/intro');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/coc") {
|
||||
window.location.replace('/community/coc');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/contributing") {
|
||||
window.location.replace('/dev/contributing');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/privacy") {
|
||||
window.location.replace('/legal/privacy');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/terms") {
|
||||
window.location.replace('/legal/terms');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/security") {
|
||||
window.location.replace('/legal/security');
|
||||
return;
|
||||
}
|
||||
if (hash === "#/contact") {
|
||||
window.location.replace('/about/contact');
|
||||
return;
|
||||
}
|
||||
window.location.replace('/intro');
|
||||
});
|
||||
</script>
|
||||
<style>
|
||||
.loader {
|
||||
border: 8px solid #0a0a23;
|
||||
border-top: 8px solid #f3f3f3;
|
||||
border-radius: 50%;
|
||||
width: 40px;
|
||||
height: 40px;
|
||||
animation: spin 2s linear infinite;
|
||||
margin: auto;
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
bottom: 0;
|
||||
right: 0;
|
||||
}
|
||||
|
||||
@keyframes spin {
|
||||
0% {
|
||||
transform: rotate(0deg);
|
||||
}
|
||||
100% {
|
||||
transform: rotate(360deg);
|
||||
}
|
||||
}
|
||||
</style>
|
||||
<div class='loader'></div>
|
||||
@ -1,95 +0,0 @@
|
||||
:root {
|
||||
--primary-color: #04624f;
|
||||
--background-color: #abfcecdd;
|
||||
--sl-color-text-accent: #04624f;
|
||||
}
|
||||
|
||||
.main-frame::before {
|
||||
background: url(https://cdn.nhcarrigan.com/background.png);
|
||||
background-size: cover;
|
||||
background-position: center;
|
||||
width: 100%;
|
||||
height: 100%;
|
||||
z-index: -1;
|
||||
content: "";
|
||||
position: fixed;
|
||||
top: 0;
|
||||
left: 0;
|
||||
right: 0;
|
||||
bottom: 0;
|
||||
opacity: 1;
|
||||
pointer-events: none;
|
||||
}
|
||||
|
||||
.main-pane {
|
||||
margin: auto;
|
||||
background-color: var(--background-color);
|
||||
color: var(--primary-color);
|
||||
}
|
||||
|
||||
.sidebar-pane,
|
||||
.right-sidebar-panel {
|
||||
background-color: var(--background-color);
|
||||
color: var(--primary-color);
|
||||
}
|
||||
|
||||
h1,
|
||||
h2,
|
||||
h3,
|
||||
h4,
|
||||
h5,
|
||||
h6,
|
||||
a {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
a[aria-current="page"] {
|
||||
color: var(--background-color) !important;
|
||||
background-color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
header {
|
||||
color: var(--primary-color) !important;
|
||||
background-color: var(--background-color) !important;
|
||||
}
|
||||
|
||||
.large {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.right-sidebar-panel :where(a) {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.right-sidebar-panel :where(a):hover {
|
||||
color: var(--background-color) !important;
|
||||
background-color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
footer > div > a,
|
||||
footer > div > a:visited,
|
||||
footer > div > p {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.social-icons::after {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.sidebar-content {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.link-title {
|
||||
color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.pagination-links > a:hover {
|
||||
color: var(--background-color) !important;
|
||||
background-color: var(--primary-color) !important;
|
||||
}
|
||||
|
||||
.pagination-links > a:hover > span > .link-title {
|
||||
color: var(--background-color) !important;
|
||||
background-color: var(--primary-color) !important;
|
||||
}
|
||||
@ -1,3 +0,0 @@
|
||||
{
|
||||
"extends": "astro/tsconfigs/strictest"
|
||||
}
|
||||
Loading…
x
Reference in New Issue
Block a user