Contributing Guidelines

Thank you for your interest in the development of Hoshii. We aim to provide a good collaborating environment for everyone who is involved. The guidelines below will help you through your contribution process.

Submitting an Issue

Issues such as bug reports, feature requests, or questions are welcome. Please keep in mind that issues submitted must be as detailed as possible to avoid any misunderstanding or unnecessary questions needed.

• Before submitting an issue, make sure the issue has not existed.

Please remember to always check whether your issue is not a duplicate of other pre-existing issues. If an issue already exists, you may help contribute by providing additional information that may help us.

• Try to include information as detail as possible

Try to avoid using the keyword "It's not working" or "It bugged" when submitting a bug report. Bugs are commonly occurred due to specific specs. As such, providing descriptive information about the bug is a standard basis.

• Refrain from asking if an issue has been resolved or not

In general, we do not provide an estimation of when an issue has been resolved. Please refrain from asking about the status of an issue, or whether it has been resolved yet. A resolution for your issue is determined by how crucial it is deemed to be. Demanding for its resolutions after being reported will unlikely increase its priority in any shape or form.

Submitting a Pull Request

Pull requests are very welcome here. We love to see what changes were brought by unaffiliated contributors. If you are new, the issue-tracker should provide plenty of existing issues you may work on. Any issues that might be suitable for newcomers will be marked with the good first issue label.

Here are a few key things you need to keep in mind before start contributing:

• Make sure you are familiar with TypeScript and Guilded API

Keeping the quality of a code has been part of the development environment. We accept all kinds of contributions, but we also tend to keep the code quality of the library. If you are not familiar with any of these, we recommend that you start by learning the programming language syntax and a basic understanding of how Guilded API works.

• Provide a clear and descriptive about your pull request

If it is viable, please provide a clear and descriptive about your pull request. Having a clear description of your pull request helped us organise the development. As such, it makes us easier to read and understanding how you described your own feature.

• Test your code before opening a pull request

Please make sure to test your own code before opening a pull request. It is a mandatory measure to ensure that your code is working and functional. Do keep in mind that pull requests must always be ready for merge.

• Mark your pull request as a draft if they are still WIP

If your PR introduces major changes and you want to let everyone know that it has already been worked on, feel free to submit a draft pull request. As such, this will reduce an overlap pull request. In addition, you may always reach out to the other contributors to test your code, ensuring that it is working for everyone.

Keeping a draft pull request for a long period with no status update makes the development slower. Hence, do not hesitate to close yours if you are unable to continue any longer. This will allow another person to do it instead.

• Run ESLint test before opening a pull request

Automated tests such as ESLint are an essential part of code quality and a reliable codebase. They helped to make the code more maintainable by ensuring it is safe to reorganise, otherwise refactor the code in various ways.

While Continuous Integrations will always run for you, it is best to still run tests on your own as it helps you to be more certain that your changes are valid and ready for merge.

• Make sure no one has worked on the same pull request

Please always remember to check whether someone has not yet worked on the same feature. Though, feel free to participate by testing their pull request by ensuring that everything is working as intended. This will help us and vice versa.

• Refrain from asking for your code to be reviewed and merged

We highly appreciate and value your effort in improving the library. However, we have a basic standard to keep the library stable by prioritising critical pull requests. It can take several days or weeks for your pull request to be reviewed, or otherwise merged, depending on how important it is deemed to be.

If on any occasion your pull request received no status after weeks, you are allowed to bump by leaving a comment.

• Feel free to reach out for help

We would love to help you, too, in various ways. Therefore, if you are uncertain about several parts of the codebase, or some core workings of the library, feel free to reach out by joining the official Guilded Server for general things. You may also leave a comment on a relevant issue or pull request for crucial or longer-form discussion.

With that being said, please remember to keep a single discussion in its origin place instead of cross-posting.