We love community input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
As this source code will be widely disseminated please ensure that great care is take to avoid accidental inclusion of Confidential data elements. Secrets referenced from code should be tokenized for substitution during build / deploy.
Ally LEAD principles (particularly Act with Professionalism) and our Diversity and Inclusion ideals already compose a strong Code of Conduct for our community. Please be mindful submitted Pull Requests will receive scrutiny which may result in constructive feedback. Keep an open mind and be objective in receiving and providing feedback.
Excellent open source community references also exist.
We use BitBucket to host code as well as accept pull requests.
We Use Git Flow, So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (we use Git Flow). We actively welcome your pull requests:
- Fork the repo and create your branch from
master
. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- Make sure your code lints.
- Issue that pull request!
Report bugs using Jira Issues
Inner Source projects should use Jira issues to track. Report a bug by creating a new issue and include a label for the Inner Source project.
When creating a Jira Issue please include a label with the exact name of the repo.
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can. Includes sample code that anyone with a base setup can run to reproduce what I was seeing
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
Thorough bug reports are more likely to receive attention and resolution.
Discuss expectations of timelines for issue triage and disposition.
If you need to add new Java classes or methods to implement new steps please follow common Java rules:
When choosing a name, use full words instead of cryptic abbreviations. Doing so will make your code easier to read and understand. In many cases it will also make your code self-documenting.
Classes:
- Should be nouns, in mixed case with the first letter capitalized and the first letter of each next internal word capitalized.
- No spaces allowed. Separate by underscores (“_”).
- Dollar sign ($) not allowed
- Equals sign (=) not allowed
- The name should not start with special characters like & (ampersand), $ (dollar), _ (underscore).
Example: StepsDefinition.java
Methods
- Should be verbs, in mixed case with the first letter lowercase and with the first letter of each internal word capitalised.
- No spaces allowed. Separate by underscores (“_”).
- Dollar sign ($) not allowed
- Equals sign (=) not allowed
- The name should not start with special characters like & (ampersand), $ (dollar), _ (underscore).
Example: getContentType ()
Variables : Variable names should be short yet meaningful.
- Should not start with underscore(‘_’) or dollar sign ‘$’ characters.
- Should be mnemonic i.e, designed to indicate to the casual observer the intent of its use.
- One-character variable names should be avoided except for temporary variables.
- Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.
- No spaces allowed. Separate by underscores (“_”).
- Dollar sign ($) not allowed
- Equals sign (=) not allowed
- Discuss your test harness approach.
This document was adapted from the open-source contribution guidelines for Facebook's Draft