Welcome to Caikit! This document is the single source of truth for how to contribute to the code base. Feel free to browse the open issues and file new ones, all feedback welcome!
The sign-off is a simple line at the end of the explanation for a commit. All commits needs to be signed. 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.name and user.email git configs, you can sign your commit automatically
with git commit -s.
Note: If your git config information is set properly then viewing the git log information 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 Author and Signed-off-by lines match. If they don't your PR will be rejected by the
automated DCO check.
License information should be included in all source files where applicable. Either full or short version of the header should be used as described at apache.org. It is OK to exclude the year from the copyright notice. For the details on how to apply the copyright, see the next section.
Caikit used "Copyright The Caikit Authors" notice form.
If you are contributing third-party code you will need to retain the original copyright notice.
Any contributed third-party code must originally be Apache 2.0-Licensed or must carry a permisive software license that is compatible when combining with Apache 2.0 License. At this moment, BSD and MIT are the only OSI-approved licenses known to be compatible.
If you make substantial changes to the third-party code, prepend the contributed third party file with Caikit's copyright notice.
If the contributed code is not third-party code and you are the author we strongly encourage to avoid including your name in the notice and use the generic "Copyright The Caikit Authors" notice.
Please make sure to read and observe our Code of Conduct.
Caikit is a community project. Consequently, it is wholly dependent on its community to provide a productive, friendly, and collaborative environment.
- See Community Membership for a list the various responsibilities of contributor roles. You are encouraged to move up this contributor ladder as you gain experience.
Would you like to help drive the community forward? We will help you understand the organization of the project and direct you to the best places to get started. You'll be able to pick up issues, write code to fix them, and get your work reviewed and merged.
Help is always welcome! For example, documentation (like the text you are reading now) can always use improvement. There's always code that can be clarified and variables or functions that can be renamed or commented. There's always a need for more test coverage. You get the idea: if you ever see something you think should be fixed, you should own it.
Those interested in contributing without writing code may help documenting, evangelizing or helping answer questions about Caikit on various forums.
Each repository has beginner-friendly issues that provide a good stepping stone to larger contributions. For example, Caikit has help wanted and good first issue labels for issues that should not need deep knowledge of the system. The good first issue label indicates that members have committed to providing extra assistance for new contributors.
Not ready to contribute code, but see something that needs work? While the community encourages everyone to contribute code, it is also appreciated when someone reports an issue (aka problem). Issues should be filed under the appropriate Caikit subrepository.
Make sure to adhere to the repository specific policies or issue templates to provide detailed information that will help prompt answer and resolution of an issue.
Caikit is open source, but many of the people working on it do so as their day job. In order to avoid forcing people to be "at work" effectively 24/7, we want to establish some semi-formal protocols around development. Hopefully, these rules make things go more smoothly. If you find that this is not the case, please complain loudly.
As a potential contributor, your changes and ideas are welcome at any hour of the day or night, weekdays, weekends, and holidays. Please do not ever hesitate to ask a question or send a pull request.
[TODO: Add comms]
To check out code to work on, please refer to the GitHub Workflow Guide from Kubernetes. Caikit uses the same workflow. One of the main highlights - all the work should happen on forks, to minimize the number of branches on a given repository.
Pull requests are often called simply "PR". Caikit follows the standard github pull request process.
There are two aspects of code review: giving and receiving.
To make it easier for your PR to receive reviews, consider the reviewers will need you to:
- follow the project and repository coding conventions
- write good commit messages
- break large changes into a logical series of smaller patches which individually make easily understandable changes, and in aggregate solve a broader issue
Reviewers, the people giving the review, are highly encouraged to revisit the Code of Conduct and must go above and beyond to promote a collaborative, respectful community.
When reviewing PRs from others The Gentle Art of Patch Review suggests an iterative series of focuses which is designed to lead new contributors to positive collaboration without inundating them initially with nuances:
- Is the idea behind the contribution sound?
- Is the contribution architected correctly?
- Is the contribution polished?
Note: if your pull request isn't getting enough attention, you can explicitly mention approvers or maintainers of this repository.
If you haven't noticed by now, we have a large, lively, and friendly open-source community. We depend on new people becoming members and regular code contributors, so we would like you to come join us! The Community Membership Document covers membership processes and roles.
Contributions of preexisting code fall into two broad categories:
- Small contributions: Some contribution only amount to a single PR and should usually just be contributed as such
- Large or complex contributions: Other contributions are much larger, require ongoing maintenance of their own, and/or introduce nuanced licensing issues
Large contributions – or small contributions that turn up complex issues during PR review – may require an Architecture Decision Record (ADR) to be created.
All contributed code requires a license compatible with the Apache Software License 2.0, and contributed code will require a change of copyright to reflect the Caikit Authors.