Skip to content

Files

Latest commit

ZachyFoxxZachyFoxx
feat: add more commit guidelines
Jun 11, 2021
6364c48 · Jun 11, 2021

History

History
172 lines (108 loc) · 8.87 KB

CONTRIBUTING.md

File metadata and controls

172 lines (108 loc) · 8.87 KB

Dumb Dog Diner Contribution Guidelines

The following is a set of guidelines for contributing to plugins used on the dddMC, which are hosted in the DDD Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Table Of Contents

Code of Conduct

What should I know before I get started?

How Can I Contribute?

Styleguides

Additional Notes

What should I know before I get started?

APIs We Utilise

StickyAPI

This is our in-house code library for all of our plugins, it helps make our codebase more consistent and easier to work together with.

Placeholder API

We use Placeholder API for all of our placeholders in our plugins.

Vault API

Packets and Protocols

experienced devs may use NMS packets

There is, however, a slightly easier to use alternative called ProtocolLib

MySQL and PostgreSQL

We use MySQL and PostgreSQL for our SQL Databases

(It is prefered that you use PostgreSQL where possible)

Package Manager

It is highly recommended to use a package manager for your project. We recommend Gradle

Suggesting Enhancements

This section guides you through submitting an enhancement suggestion for DumbDogDiner plugins, including completely new features and minor improvements to existing functionality. Following these guidelines helps maintainers and the community understand your suggestion 📝 and find related suggestions 🔎.

Before creating enhancement suggestions, please check this list as you might find out that you don't need to create one. When you are creating an enhancement suggestion, please include as many details as possible. Fill in the template, including the steps that you imagine you would take if the feature you're requesting existed.

Before Submitting An Enhancement Suggestion

  • Determine which repository the enhancement should be suggested in.
  • 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.

How Do I Submit A (Good) Enhancement Suggestion?

Enhancement suggestions are tracked as GitHub issues. After you've determined which repository your enhancement suggestion is related to, create an issue on that repository and provide the following information:

  • Use a clear and descriptive title for the issue to identify the suggestion.
  • Provide a step-by-step description of the suggested enhancement in as many details as possible.
  • Provide specific examples to demonstrate the steps. Include copy/pasteable snippets which you use in those examples, as Markdown code blocks.
  • Describe the current behavior and explain which behavior you expected to see instead and why.
  • Include screenshots and animated GIFs which help you demonstrate the steps or point out what the suggestion is related to. You can use this tool to record GIFs on macOS and Windows, and this tool or this tool on Linux.
  • Explain why this enhancement would be useful.
  • List some other plugins where this enhancement exists.

Local development

All DumbDogDiner plugins and backend software can be developed locally. Contributions should be worked on in your own branches as described in

For Kotlin projects, we use Gradle for compiling code and building jars. For Typescript projects, we use Yarn as our package manager.

Branch Naming Convention

To help everyone understand what you are currently working on in your branch, we ask you to abide by the following branch naming convention:

  • For a feature you are adding, use: feat/<your username>/<short feature name> e.g. feat/skye/mail.
  • For a bugfix, use: bugfix/<your username>/<short bug name> e.g. bugfix/skye/overflow.
  • For a critical patch to master, use hotfix/master.

Pull Requests

The process described here has several goals:

  • Maintain the quality of DumbDogDiner's plugins
  • Fix problems that are important to players
  • Engage the community in working toward the best possible gameplay experience

Please follow these steps to have your contribution considered by the maintainers:

  1. Follow all instructions in the template
  2. Follow the styleguides
  3. 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.

Styleguides

Git Commit Messages

  • Be descriptive ("feat: Add x, y, and z" not "added stuff")
  • Prefix all commits with feat:, fix:, refactor:, or misc: ("fix: Move cursor to..." not "Move cursor to...")
  • Use the present tense ("feat: Add x, y, and z" not "Added x, y, and z")
  • Use the imperative mood ("fix: Move cursor to..." not "fix: Moves cursor to...")
  • Limit the first line to 72 characters or less
  • Reference issues and pull requests liberally after the first line

Kotlin Styleguide

All Kotlin code is linted with Prettier, using prettier-plugin-kotlin.

Typescript Styleguide

All TypeScript code is formatted with Prettier, and is compliant with our ESLint Style Configuration.

  • Prefer the object spread operator ({ ...anotherObj }) to Object.assign()

  • Inline exports with expressions whenever possible

    // Use this:
export class ClassName {}

// Instead of:
class ClassName {}
export { ClassName };

  • Place requires in the following order - we recommend the use of Typescript Import Sorter:

    • Built in Node Modules (such as path)
    • Local Modules (using relative paths)

  • Place class properties in the following order:

    • Class methods and properties (methods starting with static)
    • Instance methods and properties

  • Avoid platform-dependent code

Documentation Styleguide