Mastodon/Hacking: Difference between revisions
Line 19: | Line 19: | ||
* Clean code -- please be kind to your fellow maintainers who may not know what features you've implemented and save their time by ensuring that that there are no linting errors and no errors in general when you merge a feature branch to the [https://github.com/NeuromatchAcademy/mastodon/tree/dev-stable dev-stable] branch | * Clean code -- please be kind to your fellow maintainers who may not know what features you've implemented and save their time by ensuring that that there are no linting errors and no errors in general when you merge a feature branch to the [https://github.com/NeuromatchAcademy/mastodon/tree/dev-stable dev-stable] branch | ||
* If an author leaves any errors (including linting errors) and proceeds to merge a feature branch with dev-stable, the other maintainers have the right to ignore that feature branch's commits when merging upstream and dev-stable for deploying a new release. In this case, maintainers should include this in the pull request description, inform the author, and update the corresponding feature page. | * If an author leaves any errors (including linting errors) and proceeds to merge a feature branch with dev-stable, the other maintainers have the right to ignore that feature branch's commits when merging upstream and dev-stable for deploying a new release. In this case, maintainers should include this in the pull request description, inform the author, and update the corresponding feature page. | ||
[[File:Masto-contributions-SOP.png|thumb]] | |||
== Custom Features == | == Custom Features == |
Revision as of 19:41, 1 October 2023
Up to: Mastodon
Good Practices for Collaborative Contributions
- The
dev-stable
branch is for neuromatch.social's stable custom features only i.e. if a custom feature is extremely relevant to the instance and will be maintained indefinitely by the Tech_WG.- If the author of a custom feature leaves the Tech_WG, or if the feature no longer meets the needs of the instance, the feature may not need to be maintained indefinitely.
- The
main
branch should always be in a state where you can easily roll-back to a previous stable release with our instance's features e.g.custom-glitch4.2 branch. - DO NOT commit even small/important changes directly to main. This makes it hard to keep track of the changes for future merges. If you are fixing a feature from upstream, do it in a separate branch.
- Create a separate branch for each new feature.
- Name feature branches as feature-<insert appropriate name>, e.g. feature-autofollow
- Keep features as small as possible.
- Choose the parent of the feature branch wisely!
- If a feature is being added on top of glitch-soc:main, then first sync
dev-stable
using the "sync fork" feature on GitHub and then create a feature branch from this synced version. - If a feature is being added on top of some branch feature-XYZ that was added exclusively to neuromatch.social's dev-stable, then:
- either contribute to the branch feature-XYZ by submitting a PR if your hack enhances the feature
- or create a new feature branch by forking dev-stable if it's a major re-write of the feature-XYZ. If this new feature branch eventually gets merged then the original feature-XYZ branch should be deleted to keep the repo clean.
- If a feature is being added on top of glitch-soc:main, then first sync
- Any feature branch must be approved by at least 1 reviewer before it can be merged to dev-stable.
- Features MUST pass tests before they can be merged.
- When a feature has been tested, reviewed, and is ready to be merged, do not merge the feature branch directly to main. Merge to the dev-stable branch
- Clean code -- please be kind to your fellow maintainers who may not know what features you've implemented and save their time by ensuring that that there are no linting errors and no errors in general when you merge a feature branch to the dev-stable branch
- If an author leaves any errors (including linting errors) and proceeds to merge a feature branch with dev-stable, the other maintainers have the right to ignore that feature branch's commits when merging upstream and dev-stable for deploying a new release. In this case, maintainers should include this in the pull request description, inform the author, and update the corresponding feature page.
Custom Features
Description | Completion | Active | |
---|---|---|---|
Autofollow | Make all new accounts follow a a comma-separated list of account handles given in the .env file 🙂 | Completed | Completed |
Better Code Blocks | Better Code Blocks | Completed | Completed |
Exclusive Lists | Accounts on lists marked as exclusive do not appear on the home feed | Completed | Completed |
Expanding lines in collapsed posts | Expanding lines in collapsed posts | Completed | Completed |
Fetch All Replies | Fetch all replies for a given post, even if we don't follow everyone! | Draft | Active |
Filter Duplicate Boosts | Prevent duplicated boosts in public timelines like in home timelines | Completed | Inactive |
Fine-Grained Post Visibility | Allow greater control over post visibility, decoupling placement in timelines from audience and indexing | Stub | Inactive |
Mastodon/Emoji Reacts | Borrow emoji reacts to messages from glitch-soc main :) | Stub | |
Mastodon/Footnotes | Stub | Inactive | |
Mastodon/Mathjax | Borrowing mathjax from mathstodon :) | Completed | Completed |
Mastodon/Slugified URLs | Create slugified URLs for posts, potentially adding a "title" field | Stub | Inactive |
Post Titles | Give posts titles w/ slugified URLs to support longer-form writing and minimization | Draft | Active |
Search | Full-text search on neuromatch.social | Stub | Active |
Sticky Posts |
See Also
Dev Environment
Mastodon/Mathjax: information in this thread about different possible implementation approaches
Mastodon/Hacking#Dev Environment: Details on setting up Vagrant for local development
Wikibot#TODO: implement n-back archiving of threads and previous posts, the parser already supports it
Mastodon/Hacking: Added contributing guidelines under Good Practices for Collaborative Contributions (still undergoing refinement -- I've a diagram in mind)