📝 Update README and CONTRIBUTING

.github/CONTRIBUTING.md

@@ -6,65 +6,36 @@ To ensure nobody's time and effort is wasted, please be sure to follow the guide
 
 1. Check to see if an issue already exists relevant to your feature/topic
 2. Create an issue (if an issue does not already exist) and express interest in working it (see the [issues](#issues) section below)
-3. Create a new feature branch **off of the `develop` branch** - _not_ `main`. All PRs should be made against `develop`.
+3. Create a new feature branch **off of the `experimental` or `develop` branches** - _not_ `main`. All PRs should be made against either `experimental` or `develop`.
 4. Add appropiate documentation, tests, etc, if necessary.
 5. Ensure you have your code formatters properly configured (both Prettier and Rustfmt).
 6. Once you've completed your changes, create your PR!
-7. Follow the PR naming format to help ensure the changelog generator properly picks up your additions:
+7. Follow the PR naming format outlined at [gitmoji.dev](https://gitmoji.dev/specification), used for more uniform generation of release notes
 
-   > :information_source: Honestly, don't stress about this part right now. I don't even have a changelog generator!! This kind of structure will only matter once releases are more regular and providing changelogs are more important. For now, just make sure your PR name and body is descriptive and concise :heart:
-
-   ```
-   <type>: <description>
-   ```
-
-   Where `type` is one of the following:
-
-   - `feat`: A new feature
-   - `fix`: A bug fix
-   - `docs`: Documentation only changes
-   - `refactor`: A code change that neither fixes a bug nor adds a feature
-   - `perf`: A code change that improves performance
-   - `test`: Adding missing tests or correcting existing tests
-   - `ci`: Changes to our CI configuration files and scripts
-   - `chore`: Other changes that don't modify `src` or `test` files, such as updating `package.json` or `README.md`
-   - `revert`: Reverts a previous commit
-   - `WIP`: Work in progress
-
-   The `description` should contain a _succinct_ description of the change:
-
-   - use the imperative, present tense: "change" not "changed" nor "changes"
-   - don't capitalize the first letter
-   - no dot (.) at the end
-
-   Examples:
-
-   ```
-   feat: add support for Reading Lists
-   fix: remove broken link
-   docs: update CONTRIBUTING.md to include PR naming format
-   ```
+   > :information_source: Don't stress too much about this part. Just make sure your PR name and body is descriptive and concise, :heart:
 
 8. Stick around and make sure your PR passes all checks and gets merged!
 
 ## Issues
 
-I use GitHub issues to track bugs, feature requests, and other tasks. No rigid structure is enforced, but please try and follow these guidelines:
+I use GitHub issues to track bugs, feature requests, and other tasks. No rigid structure is enforced, but please try to fill out the templates fully as best you can. Generally, it is useful to include the following information:
+
+- Docker tag (or commit hash displayed in settings)
+- Log output (server logs, browser console, etc)
+- Access method (browser on host machine, mobile on network, etc)
+- Network logs (network tab) and details (reverse proxy, VPN, etc)
+
+If you're not sure if an issue is relevant or appropriate, e.g. if you have more of a question to ask, feel free to pop in the [Discord](https://discord.gg/63Ybb7J3as) and ask!
 
-- Please try and be as descriptive as possible when opening an issue.
-- There are a few templates available to help guide you, but if you're not sure which one to use just use the "Blank Issue" template.
-  - If you're opening an issue to request a feature, please try and explain why you think it would be a good addition to the project. If applicable, include example use cases.
-  - If you're opening an issue to report a bug, please try and include a minimal reproduction of the bug (video, code, logs, etc).
-  - If you're not sure if an issue is relevant or appropriate, e.g. if you have more of a question to ask, feel free to pop in the [Discord](https://discord.gg/63Ybb7J3as) and ask!
-- **Please don't ghost an issue you've been assigned** - if you're no longer interested in working on it, that is totally okay! Just leave a comment on the issue so that I know you're no longer interested and I can reassign it to someone else. I will never be offended if you no longer want to work on an issue - I'm just trying to make sure that nobody's time and effort is wasted.
+## Pull Requests
 
-## A note on merging
+> :information_source: There are two development branches: `experimental` and `develop`. These correspond to the `experimental` and `nightly` tags on Docker Hub, respectively. In general, `experimental` is for large or breaking changes, while `develop` is for smaller, more incremental changes.
 
 PRs will be merged once the following criteria are met:
 
 - All CI checks pass
 - At least one _maintainer_ has reviewed your PR
 
-All PRs to `develop` will be squashed. All PRs to `main` will be merge commits. This is to ensure that the commit history is clean and easy to follow, and to ensure that the changelog generator works properly.
+All PRs to `experimental` will be squashed. All PRs to `develop` from `experimental` and to `main` will be merge commits. This is to ensure that the commit history is clean and easy to follow, and to ensure that the changelog generator works properly.
 
 Thanks for considering contributing to Stump! :heart:

README.md

@@ -129,14 +129,14 @@ And that's it!
 
 #### Where to start?
 
-If you aren't sure where to start, I recommend taking a look at [open issues](https://github.com/stumpapp/stump/issues). You can also check out the [milestones](https://github.com/stumpapp/stump/milestones) page for a more curated list of issues that need to be addressed.
+If you aren't sure where to start, I recommend taking a look at [open issues](https://github.com/stumpapp/stump/issues). You can also check out the [current project board](https://github.com/orgs/stumpapp/projects/4) to see what's actively being worked on or planned.
 
 In general, the following areas are good places to start:
 
 - Translation, so Stump is accessible to as many people as possible
-  - [Crowdin](https://crowdin.com/project/stump) is being used for translations
+  - [Crowdin](https://crowdin.com/project/stump) is used for translations
 - Writing comprehensive tests
-- Designing UI elements/sections or improving the existing UI/UX
+- Designing and/improving UI/UX
 - Docker build optimizations, caching, etc
 - CI pipelines, automated releases and release notes, etc
 - And lots more!
@@ -155,7 +155,7 @@ Stump has a monorepo structure managed by [yarn workspaces](https://yarnpkg.com/
 Stand-alone applications that can be run independently, at `/apps` in the root of the project:
 
 - `desktop`: A React + Tauri desktop application
-- `mobile`: A React Native application ([#125](https://github.com/stumpapp/stump/issues/125))
+- `expo`: A React Native application ([#125](https://github.com/stumpapp/stump/issues/125))
 - `server`: An [Axum](https://github.com/tokio-rs/axum) HTTP server
 - `web`: A React application, the primary UI for both the built-in web app the server serves and the desktop app