Mastodon/Hacking: Difference between revisions

From neuromatch
(adding more good practices)
Line 2: Line 2:


== Good Practices for Collaborative Hacking ==
== Good Practices for Collaborative Hacking ==
* The [https://github.com/NeuromatchAcademy/mastodon/tree/dev dev] branch is for neuromatch.social's stable features only.  
* The <code>[https://github.com/NeuromatchAcademy/mastodon/tree/dev-stable dev-stable]</code> 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]], the feature may not need to be maintained indefinitely.
* The [https://github.com/NeuromatchAcademy/mastodon/tree/main main] branch should always be in a state where you can easily roll-back to a previous stable [https://github.com/NeuromatchAcademy/mastodon/tree/dev dev] branch.  
* The <code>[https://github.com/NeuromatchAcademy/mastodon/tree/main main]</code> 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.[https://github.com/NeuromatchAcademy/mastodon/tree/custom-glitch4.2 custom-glitch4.2] branch.  
* DO NOT commit even small/important changes directly to [https://github.com/NeuromatchAcademy/mastodon/tree/main main]. This makes is hard to keep track of the changes for future merges. If you are fixing a feature from upstream, do it in a separate branch.
* '''DO NOT''' commit even small/important changes directly to [https://github.com/NeuromatchAcademy/mastodon/tree/main 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.  
* '''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.
* Keep features as small as possible.
* Choose the parent of the feature branch wisely!  
* '''Choose the parent of the feature branch wisely!'''
** If a feature is being added on top of [https://github.com/glitch-soc/mastodon/tree/main glitch-soc:main], then fork it to create the feature branch.
** If a feature is being added on top of [https://github.com/glitch-soc/mastodon/tree/main glitch-soc:main], then first sync <code>[https://github.com/glitch-soc/mastodon/tree/glitch-clean-sync glitch-clean-sync]</code> using the "sync fork" feature on GitHub and then create a feature branch from this synced version. Please note that <code>[https://github.com/glitch-soc/mastodon/tree/glitch-clean-sync glitch-clean-sync]</code> is a locked read-only branch by design to protect it from force-pushes.
** If a feature is being added on top of some feature-branch-XYZ that was added exclusively to neuromatch.social, then either contribute to feature-branch-XYZ by submitting PRs or create a new feature branch by forking feature-branch-XYZ.
** If a feature is being added on top of some branch feature-XYZ that was added exclusively to neuromatch.social's dev-stable, then:
* Any feature branch must be approved by at least 1 reviewer before it can be merged to [https://github.com/NeuromatchAcademy/mastodon/tree/dev dev].
*** 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.
* Any feature branch must be approved by at least 1 reviewer before it can be merged to [https://github.com/NeuromatchAcademy/mastodon/tree/dev-stable dev-stable].
* Features MUST pass tests before they can be merged.  
* 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 [https://github.com/NeuromatchAcademy/mastodon/tree/dev dev] branch
* 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 [https://github.com/NeuromatchAcademy/mastodon/tree/dev-stable dev-stable] branch
* Clean code -- please be kind to your fellow maintainers 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 dev] 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 (which eventually gets merged to main), the other maintainers have the right to ignore that feature branch's commits when merging upstream with dev during a new release. In this case, maintainers should include that 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.
 
 


== ~ Features ~ ==
== ~ Features ~ ==

Revision as of 06:45, 1 October 2023

Up to: Mastodon

Good Practices for Collaborative Hacking

  • 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, 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 glitch-clean-sync using the "sync fork" feature on GitHub and then create a feature branch from this synced version. Please note that glitch-clean-sync is a locked read-only branch by design to protect it from force-pushes.
    • 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.
  • 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.

~ Features ~

 DescriptionCompletionActive
AutofollowMake all new accounts follow a a comma-separated list of account handles given in the .env file 🙂CompletedCompleted
Better Code BlocksBetter Code BlocksCompletedCompleted
Exclusive ListsAccounts on lists marked as exclusive do not appear on the home feedCompletedCompleted
Expanding lines in collapsed postsExpanding lines in collapsed postsCompletedCompleted
Fetch All RepliesFetch all replies for a given post, even if we don't follow everyone!DraftActive
Filter Duplicate BoostsPrevent duplicated boosts in public timelines like in home timelinesCompletedInactive
Fine-Grained Post VisibilityAllow greater control over post visibility, decoupling placement in timelines from audience and indexingStubInactive
Mastodon/Emoji ReactsBorrow emoji reacts to messages from glitch-soc main :)Stub
Mastodon/FootnotesStubInactive
Mastodon/MathjaxBorrowing mathjax from mathstodon :)CompletedCompleted
Mastodon/Slugified URLsCreate slugified URLs for posts, potentially adding a "title" fieldStubInactive
Post TitlesGive posts titles w/ slugified URLs to support longer-form writing and minimizationDraftActive
SearchFull-text search on neuromatch.socialStubActive
Sticky Posts

See Also

Dev Environment

sneakers-the-rat#mathjax22-12-12 20:53:43

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