Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Governance docs per CE PR 1226 #51

Merged
merged 2 commits into from
Oct 10, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
167 changes: 167 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,167 @@
# Contributing to CloudEvents' PHP SDK

:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:

We welcome contributions from the community! Please take some time to become
acquainted with the process before submitting a pull request. There are just
a few things to keep in mind.

# Pull Requests

Typically, a pull request should relate to an existing issue. If you have
found a bug, want to add an improvement, or suggest an API change, please
create an issue before proceeding with a pull request. For very minor changes
such as typos in the documentation this isn't really necessary.

## Pull Request Guidelines

Here you will find step by step guidance for creating, submitting and updating
a pull request in this repository. We hope it will help you have an easy time
managing your work and a positive, satisfying experience when contributing
your code. Thanks for getting involved! :rocket:

* [Getting Started](#getting-started)
* [Branches](#branches)
* [Commit Messages](#commit-messages)
* [Staying current with main](#staying-current-with-main)
* [Submitting and Updating a Pull Request](#submitting-and-updating-a-pull-request)
* [Congratulations!](#congratulations)

## Getting Started

When creating a pull request, first fork this repository and clone it to your
local development environment. Then add this repository as the upstream.

```console
git clone https://github.com/mygithuborg/sdk-php.git
cd sdk-php
git remote add upstream https://github.com/cloudevents/sdk-php.git
```

## Branches

The first thing you'll need to do is create a branch for your work.
If you are submitting a pull request that fixes or relates to an existing
GitHub issue, you can use the issue number in your branch name to keep things
organized.

```console
git fetch upstream
git reset --hard upstream/main
git checkout FETCH_HEAD
git checkout -b 48-fix-http-agent-error
```

## Commit Messages

We prefer that contributors follow the
[Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/#summary).
The first line of your commit should be prefixed with a type, be a single
sentence with no period, and succinctly indicate what this commit changes.

All commit message lines should be kept to fewer than 80 characters if possible.

An example of a good commit message.

```log
docs: remove 0.1, 0.2 spec support from README
```

### Signing your commits

Each commit must be signed. Use the `--signoff` flag for your commits.

```console
git commit --signoff
```

This will add a line to every git commit message:

Signed-off-by: Joe Smith <[email protected]>

Use your real name (sorry, no pseudonyms or anonymous contributions.)

The sign-off is a signature line at the end of your commit message. Your
signature certifies that you wrote the patch or otherwise have the right to pass
it on as open-source code. See [developercertificate.org](http://developercertificate.org/)
for the full text of the certification.

Be sure to have your `user.name` and `user.email` set in your git config.
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 <[email protected]>
Date: Thu Feb 2 11:41:15 2018 -0800

Update README

Signed-off-by: Joe Smith <[email protected]>
```

Notice the `Author` and `Signed-off-by` lines match. If they don't your PR will
be rejected by the automated DCO check.

## Staying Current with `main`

As you are working on your branch, changes may happen on `main`. Before
submitting your pull request, be sure that your branch has been updated
with the latest commits.

```console
git fetch upstream
git rebase upstream/main
```

This may cause conflicts if the files you are changing on your branch are
also changed on main. Error messages from `git` will indicate if conflicts
exist and what files need attention. Resolve the conflicts in each file, then
continue with the rebase with `git rebase --continue`.


If you've already pushed some changes to your `origin` fork, you'll
need to force push these changes.

```console
git push -f origin 48-fix-http-agent-error
```

## Submitting and Updating Your Pull Request

Before submitting a pull request, you should make sure that all of the tests
successfully pass.

Once you have sent your pull request, `main` may continue to evolve
before your pull request has landed. If there are any commits on `main`
that conflict with your changes, you may need to update your branch with
these changes before the pull request can land. Resolve conflicts the same
way as before.

```console
git fetch upstream
git rebase upstream/main
# fix any potential conflicts
git push -f origin 48-fix-http-agent-error
```

This will cause the pull request to be updated with your changes, and
CI will rerun.

A maintainer may ask you to make changes to your pull request. Sometimes these
changes are minor and shouldn't appear in the commit log. For example, you may
have a typo in one of your code comments that should be fixed before merge.
You can prevent this from adding noise to the commit log with an interactive
rebase. See the [git documentation](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History)
for details.

```console
git commit -m "fixup: fix typo"
git rebase -i upstream/main # follow git instructions
```

Once you have rebased your commits, you can force push to your fork as before.

## Congratulations!

Congratulations! You've done it! We really appreciate the time and energy
you've given to the project. Thank you.
5 changes: 5 additions & 0 deletions MAINTAINERS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,5 @@
# Maintainers

Current active maintainers of this SDK:

- [John Laswell](https://github.com/jlaswell)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the process to get @GrahamCampbell onto this list as well, @duglin ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you. Sorry, I should have spotted this.

7 changes: 7 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -117,3 +117,10 @@ how SDK projects are
for how PR reviews and approval, and our
[Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
information.

## Additional SDK Resources

- [List of current active maintainers](MAINTAINERS.md)
- [How to contribute to the project](CONTRIBUTING.md)
- [SDK's License](LICENSE)
- [SDK's Release process](RELEASING.md)
3 changes: 3 additions & 0 deletions RELEASING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
To create a new release:
- Create a new Github release via the Github UI, making sure to prefix it
with `v`