🎉 First off, thanks for taking the time to contribute! 🎉
The following is a set of guidelines for contributing to Go Misskey. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
Please read our Code of Conduct.
What should I know before I get started?
Other then Go, not much. If you are present on any of the Misskey instances, it may be a bit of an advantage, but you can contribute without any experiences with Misskey.
However, implementing and testing endpoints requires an API token, as the
official documentation is not accurate. In some places it says there is no
response body with 201 No Content status code, but in reality it's
200 OK and it has a response body.
We try to map 1:1 on endpoints with services under the services directory,
but sometimes it's better to create sub-packages or to rename functions.
This section guides you through submitting a bug report. Following these guidelines helps maintainers and the community to understand your report 📝, reproduce the behavior 💻 💻, and find related reports 🔎.
We have a template for bugs, if you are reporting one, please
give us as much detail as you can and use the template as a guideline.
The Bug report template is not a strict template, you can format your report
in different ways as long as it helps understanding the issue better.
Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.
This section guides you through submitting an enhancement suggestion, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community to understand your suggestion 📝 and find related suggestions 🔎.
We have a template for Feature requests, if you are submitting an
enhancement suggestion, please give us as much detail as you can
and use the template as a guideline. The Feature requests template
is not a strict template, you can format your report in different ways
as long as it helps understanding the issue better.
Perform a cursory search to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one.
Unsure where to begin contributing?
You can start by looking through these ❤️ Good first issue,
📖 Documentation and 🏳️ Help wanted issues:
- ❤️ Good first issue - issues which should be easy to to implement based on existing code. They are mostly an endpoint or endpoint group with straightforward implementation.
- 🏳️ Help wanted - issues which should be a bit more involved
than
❤️ Good first issueissues. - 📖 Documentation - issues which may not require deep understanding of the system, but requires to understand go.
As a requirement, you will need Go to be installed and a Misskey API token
to test service endpoints which need authentication.
If you don't have an API Token yet, you can create a new user on Slippy.
The registration requires only a username and a password
(yes, no email or phone).
To test your local changes, simply create a small Go program inside the repository so it compiles with the code, running your modifications:
package main
import (
"log"
"os"
"github.com/yitsushi/go-misskey"
)
func main() {
client, _ := misskey.NewClientWithOptions(
misskey.WithAPIToken(os.Getenv("MISSKEY_TOKEN")),
misskey.WithBaseURL("https", "slippy.xyz", ""),
misskey.WithLogLevel(logrus.DebugLevel),
)
if err != nil {
log.Printf("Error happened: %s", err)
return
}
response, err := client.Notes().Show("8ebr49xcpj")
if err != nil {
log.Printf("Error happened: %s", err)
return
}
for index, choice := range response.Poll.Choices {
log.Printf("%2d %s", index, choice.Text)
}
}If you are using Visual Studio Code or any other editors that has a REST Client functionality (built-in or plugin), you can create a request file to test endpoints.
For Vim, I use diepm/vim-rest-console:
# Global scope.
https://slippy.xyz/api
Content-Type: yourtoken
-s
-i
apiToken = zU6RqyRosMtkJlXPdkjMUoMSzZr8h0bv
--
# List lists
--
POST /users/lists/list
{
"i": ":apiToken"
}For vscode, you can use REST Client by Huachao Mao:
@host = slippy.xyz
@token = yourtoken
# @name create
POST https://{{host}}/api/notes/create
Content-Type: application/json
{
"i": "{{token}}",
"text": "Test message"
}
###
@noteID = {{create.response.body.$.createdNote.id}}
POST https://{{host}}/api/notes/delete
Content-Type: application/json
{
"i": "{{token}}",
"noteId": "{{noteID}}"
}The process described here has several goals:
- Maintain quality
- Fix problems that are important to users
- Enable a sustainable system for maintainers to review contributions
Please follow these steps to have your contribution considered by the maintainers:
- Follow all instructions in the template
- Follow the styleguides.
- Follow the Patterns and Structure guide
- After you submit your pull request, verify that all status checks
are passing
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
A Pull Request may be rejected without a related issue.
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Set the header..." not "Sets the header...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
For Go package, function, struct, const, var or interface
documentation, follow the Go guidelines for documentation. Some of them
are tested with linter.
Any other documentation lives under the docs/ directory and
uses Markdown format.
This section lists the labels we use to help track and manage issues and pull requests.
The labels are loosely grouped by their purpose, but it's not required that every issue have a label from every group or that an issue can't have more than one label from the same group.
| Label | Issues | Description |
|---|---|---|
| 🐛 Bug | Link | Something isn't working |
| ✨ Feature | Link | New feature or request |
| ♻️ Duplicate | Link | This issue or pull request already exists |
| ❤️ Good first issue | Link | New feature request or enhancement suggestion |
| 🏳️ Help wanted | Link | Extra attention is needed |
| 🚫 Invalid | Link | This doesn't seem right |
| 💬 Question | Link | Further information is requested |
| 🤡 Wontfix | Link | The team has decided not to fix these issues for now |
| Label | Issues | Description |
|---|---|---|
| 👮 Admin | Link | Admin endpoint related |
| ⚙️ Core | Link | Core related |
| 📖 Documentation | Link | Improvements or additions to documentation |
| 🔒 Security | Link | Security issues |
| 🛠️ Service | Link | Related to any of the services/endpoints |