CONTRIBUTING.md

Contribution guide

We're glad you're interested in contributing to Sharkey! In this document you will find the information you need to contribute to the project.

Roadmap

See ROADMAP.md for the upstream Misskey roadmap.

Issues

Before creating an issue, please check the following:

• To avoid duplication, please search for similar issues before creating a new issue.
• Do not use Issues to ask questions or troubleshooting.
  • Issues should only be used to feature requests, suggestions, and bug tracking.
  • Please ask questions or troubleshooting in Discord.

[!WARNING] Do not close issues that are about to be resolved. It should remain open until a commit that actually resolves it is merged.

Recommended discussing before implementation

We welcome your proposal.

When you want to add a feature or fix a bug, please open an issue, don't just start writing code. We may suggest different approaches, or show that the "bug" is actually intended behaviour (and offer work-arounds), or maybe we won't be able to merge your new feature because it would make it too hard to incorporate future changes from Misskey. Each of these examples have actually happened!

On the other hand, it's very likely that we'll tell you "go ahead!". We try our best to incorporate improvements from our users!

Also, when you start implementation, assign yourself to the Issue (if you cannot do it yourself, ask Committer to assign you). By expressing your intention to work on the Issue, you can prevent conflicts in the work.

To the Committers: you should not assign someone on it before the Final Decision.

How issues are triaged

The Committers may:

• close an issue that is not reproducible on latest stable release,
• merge an issue into another issue,
• split an issue into multiple issues,
• or re-open that has been closed for some reason which is not applicable anymore.

@syuilo reserves the Final Decision rights including whether the project will implement feature and how to implement, these rights are not always exercised.

Well-known branches

• stable branch is tracking the latest release and used for production purposes.
• develop branch is where we work for the next release.
  • When you create a PR, basically target it to this branch.

Creating a PR

Thank you for your PR! Before creating a PR, please check the following:

• If possible, prefix the title with a keyword that identifies the type of this PR, as shown below.
  • fix / refactor / feat / enhance / perf / chore etc
  • Also, make sure that the granularity of this PR is appropriate. Please do not include more than one type of change or interest in a single PR.
• If there is an Issue which will be resolved by this PR, please include a reference to the Issue in the text.
• Please add the summary of the changes to CHANGELOG.md. However, this is not necessary for changes that do not affect the users, such as refactoring.
• Check if there are any documents that need to be created or updated due to this change.
• If you have added a feature or fixed a bug, please add a test case if possible.
• Please make sure that tests and Lint are passed in advance.
  • You can run it with pnpm test and pnpm lint. See more info
• If this PR includes UI changes, please attach a screenshot in the text.

Thanks for your cooperation 🤗

Additional things for ActivityPub payload changes

This section is specific to misskey-dev implementation. Other fork or implementation may take different way. A significant difference is that non-"misskey-dev" extension is not described in the misskey-hub's document.

If PR includes changes to ActivityPub payload, please reflect it in misskey-hub's document by sending PR.

The name of purporsed extension property (referred as "extended property" in later) to ActivityPub shall be prefixed by _misskey_. (i.e. _misskey_quote)

The extended property in packages/backend/src/core/activitypub/type.ts must be declared as optional because ActivityPub payloads that comes from older Misskey or other implementation may not contain it.

The extended property must be included in the context definition. Context is defined in packages/backend/src/core/activitypub/misc/contexts.ts. The key shall be same as the name of extended property, and the value shall be same as "short IRI".

"Short IRI" is defined in misskey-hub's document, but usually takes form of misskey:<name of extended property>. (i.e. misskey:_misskey_quote)

One should not add property that has defined before by other implementation, or add custom variant value to "well-known" property.

Reviewers guide

Be willing to comment on the good points and not just the things you want fixed 💯

読んでおくといいやつ

• https://blog.lacolaco.net/posts/1e2cf439b3c2/
• https://konifar-zatsu.hatenadiary.jp/entry/2024/11/05/192421

Review perspective

• Scope
  • Are the goals of the PR clear?
  • Is the granularity of the PR appropriate?
• Security
  • Does merging this PR create a vulnerability?
• Performance
  • Will merging this PR cause unexpected performance degradation?
  • Is there a more efficient way?
• Testing
  • Does the test ensure the expected behavior?
  • Are there any omissions or gaps?
  • Does it check for anomalies?

Security Advisory

For reporter