Please note we have a code of conduct, please follow it in all your interactions with the project.
Contributing a feature
In order to contribute a feature you’ll need to go through the following steps:
- Discuss your idea writing a mail to email@example.com
- Once there is general agreement that the feature is useful, create a GitHub issue to track the discussion. The issue should include information about the requirements and use cases that is trying to address. Include a discussion of the proposed design and technical details of the implementation in the issue.
- If the feature is substantial enough:
- Working group leads will ask for a design document; create the design document and add a link to it in the GitHub issue. Don’t forget to send a note to the working group to let everyone know your document is ready for review.
- Depending of the breath of the design and how contentious it is, the working group leads may decide the feature needs to be discussed in one or more working group meetings before being approved.
- Once the major technical issues are resolved and agreed upon, post a note to the working group’s mailing list with the design decision and the general execution plan.
- Submit documentation for your feature, including usage examples when possible. Documentation should consist in HTML+pictures and shall be sent to the email address firstname.lastname@example.org.
- Submit PRs with your code changes.
Note that we prefer bite-sized PRs instead of giant monster PRs. It’s therefore preferable if you can introduce large features in smaller reviewable changes that build on top of one another.
If you would like to skip the process of submitting an issue and instead would prefer to just submit a pull request with your desired code changes then that’s fine. But keep in mind that there is no guarantee of it being accepted and so it is usually best to get agreement on the idea/design before time is spent coding it. However, sometimes seeing the exact code change can help focus discussions, so the choice is up to you.
If you’re working on an existing issue, simply respond to the issue and express interest in working on it. This helps other people know that the issue is active, and hopefully prevents duplicated efforts.
To submit a proposed change:
- Fork the affected repository.
- Create a new branch for your changes.
- Develop the code/fix.
- Add new test cases. In the case of a bug fix, the tests should fail without your code changes. For new features try to cover as many variants as reasonably possible.
- Modify the documentation as necessary.
Verify the entire CI process (building and testing) works.
While there may be exceptions, the general rule is that all PRs should be 100% complete – meaning they should include all test cases and documentation changes related to the change.
When ready, if you have not already done so, sign a contributor license agreements and submit the PR.
See Reviewing and Merging Pull Requests for Istio for the PR review and merge process that we use.
GitHub issues can be used to report bugs or submit feature requests.
When reporting a bug please include the following key pieces of information:
- The version of the project you were using (e.g. version number, or git commit)
- Operating system you are using.
- The exact, minimal, steps needed to reproduce the issue. Submitting a 5 line script will get a much faster response from the team than one that’s hundreds of lines long.
Code of Conduct
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
Examples of behavior that contributes to creating a positive environment include:
-Using welcoming and inclusive language
-Being respectful of differing viewpoints and experiences
-Gracefully accepting constructive criticism
-Focusing on what is best for the community
-Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
-The use of sexualized language or imagery and unwelcome sexual attention or advances
-Trolling, insulting/derogatory comments, and personal or political attacks
-Public or private harassment
-Publishing others’ private information, such as a physical or electronic address, without explicit permission
-Other conduct which could reasonably be considered inappropriate in a professional setting
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at email@example.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq