Merge tag 'beta-1.0.1-RC-2'

CONTRIBUTING.md

@@ -1,25 +1,37 @@
-==== CONTRIBUTION GUIDELINES ====
-
 Hello!
 
-If you're reading this, you probably want to contribute to Mlem. Welcome! We're happy to have you on board.
+If you're reading this, you probably want to contribute to Mlem. Welcome! We're happy to have you on board. You may wish to join our [Matrix room](https://matrix.to/#/#mlemappspace:matrix.org) if you haven't already.
+
+## Prerequesites
+
+This project makes use of [SwiftLint](https://github.com/realm/SwiftLint#swiftlint). This runs as part of the Xcode build phases.
+
+In order to benefit please ensure you have [Homebrew](https://brew.sh) installed on your system and then run the following command to install Swiftlint:
+
+`brew install swiftlint`
+
+## Getting started
 
 To avoid having multiple in-flight tasks working on the same part of the codebase, we have a set procedure for claiming and performing work. If you don't follow it, your PR will *probably* be rejected (unless it's really *that* good).
 
-1. Go to our project board and find something in the "todo" section
-2. Comment that you want to handle that task
-3. Wait for the task to be assigned to you! This is very important for avoiding merge conflicts.
-4. Fork the repository and develop the change on your fork
-5. Open a PR for the task. The description should clearly reference the issue that you are addressing, and your PR should be able to merge with no conflicts--if the master branch changes before your PR is merged, you should either rebase or merge so that your fork can be merged cleanly.
+1. Go to our [project board](https://github.com/orgs/mlemgroup/projects/1/views/1).
+2. Find an unassigned issue under the "Todo" section that you'd like to work on.
+3. Comment that you would like the issue to be assigned to you.
+4. Wait for the task to be assigned to you! This is very important for avoiding merge conflicts.
+5. Fork the repository (if you haven't already) and develop the changes on your fork. It is important that you create your development branch using the upstream `dev` branch as the source, not the `master` branch.
+6. Open a Pull Request for your changes. Your PR should be able to merge with no conflicts - if conflicting changes are made to the `dev` branch before your PR is merged, you will have to resolve the conflicts or rebase your changes.
 
-In addition, please develop according to the following principles:
-- One named View struct per file. The name of the file should describe the view (e.g., "Large Post View,"), and the name of the struct should be match the name of the file but with spaces removed (e.g., "LargePostView"). Every file containing a View struct must end in "View."
-- All View-specific functions should live in an extension to that view, located in the same directory as the view. This file should be named "<View Name> Logic" (e.g., "Large Post View Logic")
-- Within reason, any complex of views that renders a single component of a larger view should be placed in a descriptively named let, func, or @ViewBuilder var beneath the body of the View. This keeps pyramids from piling up and makes our accessibility expert's work easier.
-- If you can reuse code, do. Prefer abstracting common components to a generic struct and common logic to a generic function.
+## Merge Protocol
+
+When your code is approved, it can be merged into the `dev` branch by a member of the development team. If you need to tinker with your changes post-approval, please make a comment that you are doing so. PRs that sit approved for more than 12 hours with no input from the dev may be merged if they are blocking other work.
 
-==== MERGE PROTOCOL ====
+## Conventions
+
+Please develop according to the following principles:
+- One View per file. A file containing a View struct must end in "View". We're yet to decide on an official naming scheme for files - feel free to offer your thoughts [here](https://github.com/mlemgroup/mlem/issues/55).
+- Within reason, any complex of views that renders a single component of a larger view should be placed in a descriptively named function, computed property or `@ViewBuilder` variable beneath the body of the View. This keeps pyramids from piling up and makes our accessibility experts' work easier.
+- If you can reuse code, do. Prefer abstracting common components to a generic struct and common logic to a generic function.
 
-We follow the principle that devs should merge their own code. This ensures that nothing enters the codebase without it being completely ready in both the eyes of the reviewers and the developer, thereby cutting down on bad code in master and tack-on PRs.
+## Testing
 
-When your code is approved, if you have permission to do so, you are responsible for clicking that beautiful "squash and merge." If you need to tinker with it post-approval, please make a comment that you are doing so. PRs that sit approved for more than 12 hours with no input from the dev may be merged if they are blocking other work.
+We operate a Lemmy Instance at https://test-mlem.jo.wtf/ which you may use for testing purposes.