We'd love to have you join the community! Below summarizes the processes that we follow.

• Reporting Issues
• Submitting Pull Requests
• Communications

Before reporting an issue, check our backlog of open issues to see if someone else has already reported it. If so, feel free to add your scenario, or additional information, to the discussion. Or simply "subscribe" to it to be notified when it is updated.

If you find a new issue with the project we'd love to hear about it! The most important aspect of a bug report is that it includes enough information for us to reproduce it. So, please include as much detail as possible and try to remove the extra stuff that doesn't really relate to the issue itself. The easier it is for us to reproduce it, the faster it'll be fixed!

Please don't include any private/sensitive information in your issue!

No Pull Request (PR) is too small! Typos, additional comments in the code, new testcases, bug fixes, new features, more documentation, ... it's all welcome!

While bug fixes can first be identified via an "issue", that is not required. It's ok to just open up a PR with the fix, but make sure you include the same information you would have included in an issue - like how to reproduce it.

PRs for new features should include some background on what use cases the new code is trying to address. When possible and when it makes sense, try to break-up larger PRs into smaller ones - it's easier to review smaller code changes. But only if those smaller ones make sense as stand-alone PRs.

Regardless of the type of PR, all PRs should include:

• well documented code changes
• additional testcases. Ideally, they should fail w/o your code change applied
• documentation changes

Squash your commits into logical pieces of work that might want to be reviewed separate from the rest of the PRs. Ideally, each commit should implement a single idea, and the PR branch should pass the tests at every commit. GitHub makes it easy to review the cumulative effect of many commits; so, when in doubt, use smaller commits.

PRs that fix issues should include a reference like Closes #XXXX in the commit message so that github will automatically close the referenced issue when the PR is merged.

The sign-off is a line at the end of the explanation for the patch. Your signature certifies that you wrote the patch or otherwise have the right to pass it on as an open-source patch. The rules are 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.
660 York Street, Suite 102,
San Francisco, CA 94110 USA

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 <[email protected]>

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.

Dependencies are managed via standard go modules.

In order to add a new dependency to this project:

• use go get -d path/to/dep@version to add a new line to go.mod
• run make vendor

In order to update an existing dependency:

• use go get -d -u path/to/dep@version to update the relevant dependency line in go.mod
• run make vendor

When new PRs for containers/image break skopeo (i.e. containers/image tests fail in make test-skopeo):

• create out a new branch in your skopeo checkout and switch to it
• find out the version of containers/image you want to use and note its commit ID. You might also want to use a fork of containers/image, in that case note its repo
• use go get -d github.com/$REPO/image/v5@$COMMIT_ID to download the right version. The command will fetch the dependency and then fail because of a conflict in go.mod, this is expected. Note the pseudo-version (eg. v5.13.1-0.20210707123201-50afbf0a326)
• use go mod edit -replace=github.com/containers/image/v5=github.com/$REPO/image/v5@$PSEUDO_VERSION to add a replacement line to go.mod (e.g. replace github.com/containers/image/v5 => github.com/moio/image/v5 v5.13.1-0.20210707123201-50afbf0a3262)
• run make vendor
• make any other necessary changes in the skopeo repo (e.g. add other dependencies now required by containers/image, or update skopeo for changed containers/image API)
• optionally add new integration tests to the skopeo repo
• submit the resulting branch as a skopeo PR, marked “DO NOT MERGE”
• iterate until tests pass and the PR is reviewed
• then the original containers/image PR can be merged, disregarding its make test-skopeo failure
• as soon as possible after that, in the skopeo PR, use go mod edit -dropreplace=github.com/containers/image to remove the replace line in go.mod
• run make vendor
• update the skopeo PR with the result, drop the “DO NOT MERGE” marking
• after tests complete successfully again, merge the skopeo PR

For general questions, or discussions, please use the IRC group on irc.freenode.net called container-projects that has been setup.

For discussions around issues/bugs and features, you can use the github issues and PRs tracking system.