Skip to content

Latest commit

 

History

History
121 lines (80 loc) · 4.5 KB

CONTRIBUTING.md

File metadata and controls

121 lines (80 loc) · 4.5 KB
Raw

How to contribute to Dolibarr

Bug reports and feature requests

Note: Issues are not a support forum. If you need help using the software, please use the forums.

Issues are managed on GitHub.

  1. Please use the search engine to check if nobody's already reported your problem.
  2. Create an issue. Choose an appropriate title. Prepend appropriately with Bug or Feature Request.
  3. Tell us the version you are using!
  4. Write a report with as much detail as possible (Use screenshots or even screencasts and provide logging and debugging informations whenever possible).

We're still figuring out how to migrate old issues to GitHub. In the meantime, they are still available at Doliforge.

Code

Basic workflow

  1. Fork the GitHub repository.
  2. Clone your fork.
  3. Choose a branch(See the Branches section below).
  4. Commit and push your changes.
  5. Make a pull request.

Branches

Unless you're fixing a bug, all pull requests should be made against the develop branch.

If you're fixing a bug, it is preferred that you cook your fix and pull request it against the oldest version affected that's still supported.

We officially support versions N, N − 1 and N − 2 for N the latest version available.

Choose your base branch accordingly.

General rules

Please don't edit the ChangeLog file. A project manager will update it from your commit messages.

Commits

Use clear commit messages with the following structure:

[KEYWORD] [ISSUENUM] DESC

LONGDESC

Keyword

In uppercase to appear in ChangeLog when generated.

The keyword can be ommitted if your commit does not fit in any of the following categories:

  • Fix: for a bug fix
  • Close: for closing a referenced feature request
  • New: for an unreferenced new feature (Opening a feature request and using close is prefered)

Issuenum

If your commit fixes a referenced bug or feature request.

In the form of a # followed by the GitHub issue number.

Desc

A short description of the commit content.

This should ideally be less than 50 characters.

LongDesc

A long description of the commit content.

You can really go to town here and explain in depth what you've been doing.

Feel free to express technical details, use cases or anything relevant to the current commit.

This section can span multiple lines.

Try to keep lines under 72 characters.

Samples

FIX|Fix #456 Short description (where #456 is number of bug fix, if it exists. In upper case to appear into ChangeLog)
or
CLOSE|Close #456 Short description (where #456 is number of feature request, if it exists. In upper case to appear into ChangeLog)
or
NEW|New Short description (In upper case to appear into ChangeLog, use this if you add a feature not tracked, otherwise use CLOSE #456)
or
Short description (when the commit is not introducing feature nor closing a bug)

Long description (Can span accross multiple lines).

Pull Requests

When submitting a pull request, use same rule as Commits for the message.

If your pull request only contains one commit, GitHub will be smart enough to fill it for you. Otherwise, please be a bit verbose about what you're providing.

Resources

Developer documentation

Translations

The source language (en_US) is maintained in the repository. See the Code section above.

All other translations are managed online at Transifex.

Join an existing translation team or create your own and translate into the interface.

Your translations will be available in the next major release.

Resources

Translator documentation

Documentation

The project's documentation is maintained on the Wiki.

Note: to help prevent spam, you need to create an account before being able to edit.