Skip to content

Latest commit

 

History

History
152 lines (122 loc) · 6.11 KB

CONTRIBUTING.md

File metadata and controls

152 lines (122 loc) · 6.11 KB
Raw

Contributing to Zanata

We would love for you to contribute to our source code and to make Zanata even better than it is today! To make sure we see your feedback contributions straight away, please follow these guidelines:

Feedback or Issues

If you find a bug, want a feature or improvement, have an idea for how to make Zanata better, or just want to tell us what you think of something in Zanata, please let us know using our issue system

Pull Requests

See Zanata Development Guidelines more for information.

Pull request review checklist

  • Code quality
    • Code passes style check (checkstyle/eslint)
    • Code is clear and concise
    • UI code is internationalised
    • Code has adequate comments where appropriate
    • Code is in an appropriate place
      • Classes are in appropriate packages
      • Code fits with class's responsibilities (SRP)
    • Configuration files are documented enough
    • If code is removed
      • No remaining code references the removed code
        • No orphaned rewrite rules
        • No orphaned config settings
      • No remaining comments refer to the removed code
      • Unused imports and libraries are removed
  • Testing
    • New code has tests
    • Changed code has tests
    • All tests pass
    • Test coverage stable or increased
  • Documentation
    • New features are documented
    • Docs removed for deleted features
    • Docs updated for all changed features
    • Developer/sysadmin docs updated if appropriate
  • If there are new dependencies

Setup

The Developer Setup Guide shows the dependencies and how to setup Java, Maven, MySQL, JBoss, and IDE.

Branches

The branches that should be targeted in pull requests

  • master: New features, bug fixes and enhancements should target this branch. If you are unsure which branch to target pull request, use this branch.
  • release: Only urgent bug fixes and documentation should target this branch.

Test against Wildfly

To run all tests against WildFly (takes about 1 hour):

mvn clean verify -Dappserver=wildfly8 -DstaticAnalysis -Dchromefirefox

Commit Message Format

We follow the [angular commit message format] (https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit), that is:

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

Type

Must be one of the following:

  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests
  • chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
  • revert: reverts a previous commit. The subject should be the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Scope

The scope could be anything specifying place of the commit change. If the pull requrest is targeting an issue, use issue ID like ZNAT-1234. Otherwise you can use the component or element name like translation memory statistics and glossary, as well as the purposes of pull requests, like dependency, cleanup.

Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • do not capitalize first letter
  • no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Live Examples

Submit a Pull Request

  1. Make your changes in a new git branch.
  2. Create your patch, including appropriate test cases.
  3. Commit your changes using a descriptive commit message that follows our commit message format.
  4. Push your branch to GitHub.
  5. In GitHub, target the pull request to zanata:master.
  6. If we suggest changes then: a. Make the required updates. b. Commit your changes to your branch (e.g. my-pr-branch).
    • Push the changes to your GitHub repository (this will update your Pull Request).

For pull request detail, read GitHub using pull request.

That is it! Thank you for your contribution!

After your pull request is merged

After your pull request is merged, you may safely delete your branch and pull the changes from the master (or release branch if you were working with it) branch of main (upstream) repository.