You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 

4.8 KiB

Contributing

First of all, thank you for being interested in contributing! You rock!

In this document, you will find some guidelines for contributing to org-unique-id. These are more guidelines than rules, so don’t try too hard to follow them.

How Can I Contribute?

Submitting Bugs and Errors

The easiest way to contribute is to the project is if you encounter a bug or an error. If you encounter one, check whether there is an issue already opened. If not, you can open one! Try to provide as much information as possible:

  • Are you running the latest version of the package?
  • Which version of Emacs are you running? On what system?
  • What is your configuration for this package?
  • What is the error message? Do you have a debug trace for the error?
  • Can you reproduce it consistently? If so, how?
  • What would the expected behavior be?

As you are collecting these pieces of information, try to come up with a short and clear issue title –it should describe quickly your issue without being too vague (e.g. avoid stuff like “error when opening Eshell” or “doesn’t work”).

Submitting New Code

If you are submitting new code through a pull request, make sure of the following:

  • Your code doesn’t do something already implemented in the package
  • Your code follows the Emacs Lisp style guide presented here as best as you can
  • All new functions and variables declared through defvar, defcustom, and defconst have docstrings
  • If you introduced new dependencies in your code, you also added them to the list of dependencies in the file’s headers
  • And obviously, your code works (I include that because I myself sometimes push commits that don’t work)

Git Commit Messages

Your commits should also follow Spacemacs’ guidelines on this matter, especially:

  • Lines no longer than 72 characters
  • Explain what you did
  • Use the imperative in your summary
  • Use present tense and imperative for what your commit changes

Describing the Pull Request

When opening a new pull request, check that its title is short and clear as to what it is meant to do. Its description should:

  • Provide the current behavior of the package, and how it will modify it
  • If it is linked to an open issue, mention it
  • If you are submitting an enhancement pull request, describe why this code suggestion would be useful

Finding Something To Do

Not sure where to begin? Take a look at the list of open issues, especially the ones with one of the following labels:

good first issue
These issues indicate easy to fix issues and easy to implement enhancements. If you are a beginner or if you want to familiarize yourself with the package, look for these issues.
help wanted
These issues might require some more work than good first issue issues and might be a bit more interesting.

If you want to work on an open issue, leave a comment saying so. However, you can directly submit a pull request if you are simply adding support for a non-standard Linux distribution.

Issue Labels

Label Description
enhancement Feature request
good first issue easy to fix issue
bug Confirmed bug or something very likely to be a bug
help wanted This bug might not be my priority, so feel to give it a try!
documentation There is something wrong with the documentation
duplicate The issue has already been reported
invalid Issue isn’t valid (not the package’s fault)
wontfix It’s either working as intended, or I decided not to fix it for now