A CLA is a document that specifies how a project is allowed to use your contribution. We want a CLA that is simple and as clear as possible so that it doesn't impede contributions to the Alfresco Bulk Import project.
When you make a contribution to the Alfresco Bulk Import project, you agree:
- Your contribution is your original work (you own the copyright) or you otherwise have the right to submit the work.
- You grant the Alfresco Bulk Import project a nonexclusive, irrevocable license to use your submitted contribution in any way.
- You are capable of granting these rights for the contribution.
By submitting a contribution to the Alfresco Bulk Import project you agree to the above statements.
- Have you reviewed the troubleshooting guide?
- Have you searched for duplicates? A simple search for exception error messages or a summary of the unexpected behaviour should suffice.
- Have you confirmed you're running the Bulk Import Tool, and not the embedded fork? See the troubleshooting guide for details on validating this.
- Are you running the latest release of the Bulk Import Tool?
- Are you sure this is a bug or missing capability? If unsure, please ask on the mailing list first.
- Create your issue here.
- New issues contain two templates in the description: bug report and enhancement request. Please pick the most appropriate for your issue, and delete the other.
- Please also tag the new issue with either "Bug" or "Enhancement".
- Please use Markdown formatting
liberally to assist in readability.
- Code fences for exception stack traces and log entries, for example, massively improve readability.
To make review of PRs easier, please:
- Please make sure your PRs will merge cleanly - PRs that don't are unlikely to be accepted.
- For code contributions, follow Alfresco's coding standards.
- For documentation contributions, follow the general structure, language, and tone of the existing docs.
- Keep PRs small and cohesive - if you have multiple contributions, please submit them as independent PRs.
- Reference issue #s if your PR has anything to do with an issue (even if it doesn't address it).
- Minimise "spurious" changes (e.g. whitespace shenanigans).
- Ensure all new files include a header comment block containing the Apache License v2.0 and your copyright information.
- Add yourself to the CONTRIBUTORS file
- If necessary (e.g. due to 3rd party dependency licensing requirements), update the NOTICE file with any new attribution notices
- Reference issues, wiki pages, and pull requests liberally!
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move button left..." not "Moves button left...")
- Limit the first line to 72 characters or less
- Please start the commit message with one or more applicable emoji:
- Frequently used:
- 🐛
:bug:when fixing a bug - 🆕
:new:when implementing an enhancement - ☑️
:ballot_box_with_check:when completing a task - 📝
:memo:when writing docs - 🐎
:racehorse:when improving performance - 🎨
:art:when improving the format/structure of the code
- 🐛
- Infrequently used:
- 🔒
:lock:when dealing with security - 🔥
:fire:when removing code or files - ⬆️
:arrow_up:when upgrading dependencies - ⬇️
:arrow_down:when downgrading dependencies - 🐧
:penguin:when fixing something on Linux - 🍎
:apple:when fixing something on Mac OS - 🏁
:checkered_flag:when fixing something on Windows - ✅
:white_check_mark:when adding tests - 💚
:green_heart:when fixing the CI build
- 🔒
- Unlikely to ever be used in this project (but listed, just in case):
- 🚱
:non-potable_water:when plugging memory leaks
- 🚱
- Frequently used: