Mastodon/Hacking: Difference between revisions

From neuromatch
No edit summary
(Added good practices for collaborative hacking)
Line 1: Line 1:
Up to: [[Part Of::Mastodon]]
Up to: [[Part Of::Mastodon]]
== Good Practices for Collaborative Hacking ==
* Create a new branch for each new feature.
* Any feature branch must be approved by at least 1 reviewer before it can be merged to dev.
* When the 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
* 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
* If an author leaves any errors (including linting errors) and proceed 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.


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

Revision as of 00:08, 1 October 2023

Up to: Mastodon

Good Practices for Collaborative Hacking

  • Create a new branch for each new feature.
  • Any feature branch must be approved by at least 1 reviewer before it can be merged to dev.
  • When the feature has been tested, reviewed, and is ready to be merged, do not merge the feature branch directly to main. Merge to the dev 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 dev branch
  • If an author leaves any errors (including linting errors) and proceed 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.


~ 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