If you are interested in getting involved in the open source community we would love to hear from you!We are always looking for new contributors to help out with the broad spectrum of enhancements and features we are looking to add to our project.

The best approach to take is to have a look at our Jira instance: https://issues.jboss.org/browse/JBTM and see if there are any items on there that you would like to see added to the project.

Once you have picked out a dev task to work on, feel free to have a chat with us on our developer space over here: Narayana Development or in our chatroom hosted on Freenode (ping one of the dev team as per this) then if you haven't done so already, you can fork one of our projects over on github to work with:

• If its core related it will be: https://github.com/jbosstm/narayana/
• If its docs related it will be: https://github.com/jbosstm/documentation/
• If its quickstart related it will be: https://github.com/jbosstm/quickstart

Once you have developed your contribution,

1. First make sure you have signed the JBoss Contributor License Agreement over here: https://cla.jboss.org/,
2. Ensure that the code builds (ideally clean your .m2/repo, then "./build.sh clean install")
3. Ensure you have a pull request for the documentation change if it affects existing behavior or adds a new feature/enhancement
   
4. Raise a Pull Request on our of our repos
   1. Make sure that you include a full URL to the issue in the description
   2. The tests that are ran can be controlled as per PULL_DESCRIPTION here.
   3. One of our team of "buildbots" will take a look over it and run our comprehensive test suite over it. It will update your pull request with comments as it executes the various phases of test and hopefully at the end will have indicated a complete build success!
   4. Please verify that all relevant tests pass (comments will appear on your pull request)
   5. Request a review using the GitHub mechanism from one of the dev team: Community · Narayana (for example myself, tomjenkinson). You can add more than one reviewer if you require better coverage.

The pull request review process we are using is:

• Verify that the change looks sane and is well documented
• Verify that the pull references a documentation JBTM for the work and that is complete or a documentation PR is available.
  
• Reviewer reviews and:
  • If the PR reviewer wants changes to the PR they add clear comments describing the required changes and reassign back to PR raiser.
  • Or if its ready to merge:
    • If the contributor is not part of the development team, merges the PR using the GitHub interface
      • Your place in history as a contributor on the project is secured!
    • If the contributor is part of development team, reassign the PR to raiser to merge the issue
• If a reviewer hasn't reviewed the PR after one day then either prompt him/her or if there are other reviews and you think that they are adequate then remove the tardy reviewer from the PR.

Post-merge:

Reviewer or assignee should note whether a blog article is recommended and if so the blog article should appear as soon as possible.

Trivial fixes suitable for merging without review (development team only):

• Minor test fixes only
• Minor documentation fixes
• Minor/micro upgrades of the dependency artifacts
• Comments added to the main code base