[incubator-pekko-persistence-cassandra] branch main updated: Add link to CLA (#13)

[nv...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

nvollmar pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/incubator-pekko-persistence-cassandra.git


The following commit(s) were added to refs/heads/main by this push:
     new e857e75  Add link to CLA (#13)
e857e75 is described below

commit e857e758e016cd2fb057dbe71be1da8b7c59ec21
Author: Nicolas Vollmar <nv...@gmail.com>
AuthorDate: Thu Jan 12 13:19:52 2023 +0100

    Add link to CLA (#13)
---
 CONTRIBUTING.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2888c9e..3d351a1 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -45,6 +45,7 @@ The steps are exactly the same for everyone involved in the project, including t
 1. Now it's finally time to [submit the pull request](https://help.github.com/articles/using-pull-requests)!
    - Please make sure to include a reference to the issue you're solving *in the comment* for the Pull Request, as this will cause the PR to be linked properly with the issue. Examples of good phrases for this are: "Resolves #1234" or "Refs #1234".
 1. If you are a first time contributor, a core member must approve the CI to run for your pull request.
+1. For non-trivial changes, you will be asked to sign the [CLA](https://www.apache.org/licenses/contributor-agreements.html) if you have not done so before.
 1. Now, both committers and interested people will review your code. This process ensures that the code we merge is of the best possible quality and that no silly mistakes slip through. You're expected to follow-up on these comments by adding new commits to the same branch. The commit messages of those commits can be more loose, for example: `Removed debugging using printline`, as they all will be squashed into one commit before merging into the main branch.
    - The community and core team are really nice people, so don't be afraid to ask follow-up questions if you didn't understand some comment or would like clarification on how to continue with a given feature. We're here to help, so feel free to ask and discuss any questions you might have during the review process!
 1. After the review, you should fix the issues as needed (pushing a new commit for a new review, etc.), iterating until the reviewers give their approval signaled by GitHub's pull-request approval feature. Usually, a reviewer will add an `LGTM` comment, which means "Looks Good To Me".
@@ -59,7 +60,7 @@ The TL;DR; of the above very precise workflow version is:
 2. Hack and test on your feature (on a branch)
 3. Document it
 4. Submit a PR
-5. Sign the CLA if necessary
+5. Sign the [CLA](https://www.apache.org/licenses/contributor-agreements.html) if necessary
 6. Keep polishing it until getting the required number of approvals
 7. Profit!
 


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pekko.apache.org
For additional commands, e-mail: commits-help@pekko.apache.org