Pixie welcomes contributions from the community. This document outlines the conventions that should be followed when making a contribution.
Whether you are a user or contributor, official support channels include:
Before opening a new issue or submitting a new pull request, it's helpful to search the project - it's likely that another user has already reported the issue you're facing, or it's a known issue that we're already aware of. It is also worth asking on the Slack channels.
You can contribute to Pixie in many ways. This includes, but is not limited to:
- Bug and feature reports
- Documentation
- Development of features and bug fixes
If you are interested in helping us shape our community, you can also apply here to be a Pixienaut.
Reporting bugs is one of the most helpful ways to contribute to Pixie. Bugs may be reported by filing a Github issue in the appropriate repository. For bugs regarding Pixie, file an issue in the pixie repo. For reporting inaccurate documentation, file an issue in the docs.px.dev repo, etc. Please follow the template when filing an issue and provide as much information as possible.
Before reporting a bug, we encourage you to search the existing Github issues to ensure that the bug has not already been filed.
The project is still in its early stages, and we are a small team actively working on delivering our roadmap. For all changes, regardless of size, please create a Github issue that details the bug or feature being addressed before submitting a pull request. In the Github issue, contributors may discuss the viability of the solution, alternatives, and considerations.
- Steps to making a code contribution to Pixie will generally look like the following:
- Fork the repository on Github.
- Create a new branch.
- Make your changes in organized commits.
- Push your branch to your fork.
- Submit a pull request to the original repository.
- Make any changes as requested by the maintainers.
- Once accepted by a maintainer, it will be merged into the original repository by a maintainer.
When making a contribution to the repository, please ensure that the following is addressed.
- Code follows Pixie’s coding style guide.
- All existing tests must pass, and new tests must be added for the bug/feature in question.
- Commits are signed (see notes below).
Please refer to the style guide directory for more details.
Commit messages should provide enough information about what has changed and why. Please follow the templates for how this information should be detailed.
The sign-off is a simple line at the end of the explanation for a commit. All commits needs to be signed and verified. Your signature certifies that you wrote the patch or otherwise have the right to contribute the material. The rules are pretty simple, if you can certify the below (from developercertificate.org):
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Then you just add a line to every git commit message:
Signed-off-by: Joe Smith <joe.smith@example.com>
Use your real name (sorry, no pseudonyms or anonymous contributions.)
-
If you set your
user.nameanduser.emailgit configs, you can sign your commit withgit commit -s.Note: If your git config information is set properly then viewing the
git loginformation for your commit will look something like this:Author: Joe Smith <joe.smith@example.com> Date: Thu Feb 2 11:41:15 2018 -0800 Update README Signed-off-by: Joe Smith <joe.smith@example.com>Notice the
AuthorandSigned-off-bylines match. If they don't your PR will be rejected by the automated DCO check.
All commit signatures must be verified to ensure that commits are coming from a trusted source. To do so, please follow Github's Signing commits guide.
When signing commits, gpg will need your passphrase to unlock the keyring. It usually uses a GUI pinentry program to do so. However on headless environments, this gets messy, so we highly recommend switching gpg to use a tty based pinentry to ease these problems.
echo "pinentry-program $(which pinentry-tty)" >> ~/.gnupg/gpg-agent.conf
echo "export GPG_TTY=\$(tty)" >> ~/.zshrc
echo "export GPG_TTY=\$(tty)" >> ~/.bashrc
export GPG_TTY=$(tty)
gpg-connect-agent reloadagent /bye
Here we tell gpg to use pinentry-tty when prompting for a passphrase, and export the current TTY to tell gpg which TTY to prompt on.