Skip to content

Latest commit

 

History

History
85 lines (64 loc) · 5.89 KB

CONTRIBUTING.md

File metadata and controls

85 lines (64 loc) · 5.89 KB
Raw



diep custom

Contribution Guideline



First off, thanks for taking the time to contribute! ❤️

All types of contributions are encouraged and valued. See the Table of Contents for different ways to help and details about how diep custom handles and implements them. Please make sure to read the relevant section before making your contribution. It will make it a lot easier for us maintainers and smooth out the experience for all involved. The community looks forward to your contributions.

And if you like the project, but just don't have time to contribute, that's fine. There are other easy ways to support the project and show your appreciation, which we would also be very happy about:

  • Star the project and put it on your watchlist to receive updates
  • Fork the repository to create your own diep custom version
  • Join our community discord server to discuss your ideas and creations with likeminded people

Table of Contents

I Have a Question

Before you ask a question, it is best to search for existing Issues that might help you. In case you have found a suitable issue and still need clarification, you can write your question in this issue. It is also advisable to search the internet for answers first.

If you then still feel the need to ask a question and need clarification, we recommend the following:

  • Open an Issue.
  • Provide as much context as you can about what you're running into.
  • Provide project and platform versions (nodejs, npm, buildhash, etc...), depending on what seems relevant.

We will then take care of the issue as soon as possible.

I want To Contribute

Reporting Bugs / Inconsistencies / Un- & Misdefined Behavior

Before Submitting a Bug Report

A good bug report shouldn't leave others needing to chase you up for more information. Therefore, we ask you to investigate carefully, collect information and describe the issue in detail in your report. Please complete the following steps in advance to help us fix any potential bug as fast as possible.

  • Make sure that you are using the latest version.
  • Determine if your bug is really a bug and not an error on your side. If you are looking for support, you might want to check this section.
  • To see if other users have experienced (and potentially already solved) the same issue you are having, check if there is not already a bug report existing for your bug or error in the bug tracker.
  • Also make sure to search the internet (including Stack Overflow) to see if users outside of the GitHub community have discussed the issue.
  • Collect information about the bug:
    • Stack trace (Traceback)
    • OS, Platform, Versions, etc...
    • Possibly your input and the output
    • Can you reliably reproduce the issue? And can you also reproduce it with older versions?

How Do I Submit a Good Bug Report?

We use GitHub issues to track bugs and errors. If you run into an issue with the project (discussing the issue with us beforehand eg. over the discord server is appreciated but not required):

  • Open an Issue. (Since we can't be sure at this point whether it is a bug or not, we ask you not to talk about a bug yet and not to label the issue.)
  • Explain the behavior you would expect and the actual behavior.
  • Please provide as much context as possible and describe the reproduction steps that someone else can follow to recreate the issue on their own. This usually includes your code.
  • Provide the information you collected in the previous section.

Improving The Documentation

In order to constantly improve our api's accessability to beginners (and everyone else) we strive to deliver a documentation everyone can understand. When making changes to the documentation please follow this step by step guideline:

  1. Understand the purpose (and audience eg. developers & users) of the function, variable, etc... you are documenting
  2. Try to answer any questions that may arise preemptively
  3. Follow the general documentation style while writing
  4. Open a pull request and follow the commit style policy

Documentation Commit Style

This styling policy describes how a pull request addressing documentation changes should be formatted

  • Title - "fix documentation ..."
  • Why - Explain why there is an issue with the existing documentation
  • Summarize - Explain how you resolved the issue

Code Contributions

When submitting your own code please stick to our issue policy as well, only inconsistencies, bugs and un- & misdefined behavior should be addressed. If you feel the need to submit any changes not following this policy please discuss this matter with us beforehand (community discord server). When sharing you own creations using our project consider making a fork so we can keep this repository simple enough to be easily accessable to everyone.

Code Commit Style

This styling policy describes how a pull request addressing code changes should be formatted

  • Title - "fix issue#<issueNumber> ..."
  • Why - Explain why there is an issue (necessary if there is no matching open issue)
  • Summarize - Explain how you resolved the issue
  • Confirmation - Confirm that you tested the changes by compiling, running and playing and didn't observe any unwanted side effects during gameplay