Skip to content

Latest commit

 

History

History
97 lines (68 loc) · 4 KB

CONTRIBUTING.md

File metadata and controls

97 lines (68 loc) · 4 KB
Raw

Contributing to asdf-markdownlint-cli2

  1. License
  2. Reporting a bug
  3. Requesting or implementing a feature
  4. Submitting your changes
    1. Script Style
    2. Pre- continuous integration
    3. Committing your changes
    4. Pull requests and branching
    5. Credits

License

asdf-markdownlint-cli2 is licensed under The MIT License, for all code.

Reporting a bug

asdf-markdownlint-cli2 is not perfect software and will be buggy.

Bugs can be reported via GitHub issues: bug report.

Some contributors and maintainers may be unpaid developers working on asdf-markdownlint-cli2, in their own time, with limited resources. We ask for respect and understanding, and will provide the same back.

If your contribution is an actual bug fix, we may ask you to perform tests that not only show the issue is solved but help prevent future regressions related to it.

Requesting or implementing a feature

Before requesting or implementing a new feature, do the following:

  • search, in existing issues (open or closed), whether the feature might already be in the works, or has already been rejected,
  • make sure you're using the latest software release (or even the latest code, if you're going for bleeding edge).

If this is done, open up a GitHub issues: feature request.

We may discuss details with you regarding the implementation, and its inclusion within the project.

We try to have as many of asdf-markdownlint-cli2's features tested as possible. Everything that a user can do, and is repeatable in any way, should be tested, to guarantee backwards compatible.

Submitting your changes

Script Style

  • use shfmt on the files you change
    • do not introduce trailing whitespace
    • indentation is 4 spaces, not tabs
    • try not to introduce lines longer than 100 characters
  • write small context element whenever possible, and use descriptive names for functions and variables
  • comment tricky or non-obvious decisions made to explain their rationale

Pre- continuous integration

Be sure to run shellcheck locally to have your pull requests as close to our expectations (in terms of format and static analysis) as possible.

Also, for testing locally use:

# We are aware that _version doesn't show the tool's version, but it hopefully prevents
# it from failing while trying to lint an inexisting file, while allowing it to self-test
# Replace <user> with your GitHub user name
# Replace <branch> with the branch you pushed
asdf plugin test markdownlint-cli2 [email protected]:<user>/asdf-markdownlint-cli2.git "markdownlint-cli2 _version" --asdf-plugin-gitref <branch>

Committing your changes

Merging to the main branch will usually be preceded by a squash.

While it's Ok (and expected) your commit messages relate to why a given change was made, be aware that the final commit (the merge one) will be the issue title, so it's important it is as specific as possible. This will also help eventual automated changelog generation.

Pull requests and branching

All fixes to asdf-markdownlint-cli2 end up requiring a +1 from one or more of the project's maintainers.

During the review process, you may be asked to correct or edit a few things before a final rebase to merge things. Do send edits as individual commits to allow for gradual and partial reviews to be done by reviewers.

Credits

asdf-markdownlint-cli2 has been improved by many contributors!