Skip to content

Commit e1da492

Browse files
author
Ryan Johnson
authored
docs: update CONTRIBUTING_DCO.md (#92)
Updated `CONTRIBUTING_DCO.md`. Signed-off-by: Ryan Johnson <[email protected]>
1 parent 09dcb38 commit e1da492

File tree

1 file changed

+99
-44
lines changed

1 file changed

+99
-44
lines changed

Diff for: CONTRIBUTING_DCO.md

+99-44
Original file line numberDiff line numberDiff line change
@@ -1,77 +1,132 @@
11
# Contributing
22

3-
The project team welcomes contributions from the community.
4-
Please read our [Developer Certificate of Origin](https://cla.vmware.com/dco).
3+
The project team welcomes contributions from the community. Whether it is a bug report, an enhancement request, or documentation update, we greatly value feedback and contributions from our community.
54

6-
All contributions to this repository must be signed as described on that page. Your signature certifies that you wrote
7-
the patch or have the right to pass it on as an open-source patch.
5+
Before you start working with project, please read our [Developer Certificate of Origin][vmware-cla-dco].
86

9-
## Contribution Flow
7+
All contributions to this repository must be signed as described on that page. Your signature certifies that you wrote the patch or have the right to pass it on as an open-source patch.
108

11-
This is a rough outline of what a contributor's workflow looks like:
9+
## Issues
1210

13-
- Create a topic branch from where you want to base your work
14-
- Make commits of logical units
15-
- Make sure your commit messages are in the proper format (see below)
16-
- Push your changes to a topic branch in your fork of the repository
17-
- Submit a pull request
11+
We welcome you to use the GitHub issues for bug reports, enhancement requests, feature requests, or documentation updates.
12+
13+
When filing an issue, please check existing open, or recently closed, issues to make sure someone else has not already reported the issue.
14+
15+
Please try to include as much information as you can. Details like these are incredibly useful:
16+
17+
- A reproducible test case or series of steps.
18+
- Any modifications you have made relevant to the bug.
19+
- Anything unusual about your environment or deployment.
20+
21+
You can also start a discussion on the [discussions][gh-discussions] area to ask questions or share ideas.
22+
23+
## Pull Requests
24+
25+
Contributions using pull requests are appreciated. Before opening a pull request, please ensure that:
26+
27+
1. You check existing open, and recently merged, pull requests to make sure it has not already been addressed for an upcoming release.
28+
2. You [open a discussion][gh-discussions] to discuss any significant work with the maintainer(s).
29+
3. You [open an issue][gh-issues] with a clear description of the problem you are trying to solve if one does not already exist.
30+
4. You are working against the latest source on the `develop` branch.
31+
32+
To submit a pull request, please:
33+
34+
1. Fork the repository and clone your fork.
35+
2. Create a topic branch from the `develop` branch. For example, `feat/add-x` or `fix/update-y`.
36+
3. Modify the source. Please focus the scope on the specific change you are contributing.
37+
4. Ensure that local tests, if any, pass.
38+
5. Update the documentation, if required. See the `docs` directory for the documentation source.
39+
6. Commit to your fork [using clear commit messages][git-commit]. Please use [Conventional Commits][conventional-commits].
40+
7. Submit a pull request, answering any default questions in the pull request, and linking to any related issues for context. See [GitHub flavored markdown syntax][gh-markdown] for references.
41+
8. Submit a work in progress pull request as a **draft pull request**. Mark the pull request as **ready for review** when you are ready for feedback.
42+
9. Review any automated checks on the the pull request pass.
43+
10. Stay engaged in the pull request review process.
44+
45+
GitHub provides additional document on [forking a repository][gh-forks] and [creating a pull request][gh-pulls].
46+
47+
### Contributor Workflow
48+
49+
This is a general outline of the workflow for contributing to this project:
50+
51+
- Create a topic branch from where you want to base your work.
52+
- Make commits of logical units.
53+
- Make sure your commit messages are [in the proper format][conventional-commits].
54+
- Push your changes to a topic branch in your fork of the repository.
55+
- Submit a pull request.
1856

1957
Example:
2058

2159
``` shell
22-
git remote add upstream https://github.com/vmware/powershell-module-for-vmware-cloud-foundation-password-management.git
23-
git checkout -b my-new-feature main
24-
git commit -a
25-
git push origin my-new-feature
60+
git remote add upstream https://github.com/<org-name>/<repo-name>.git
61+
git checkout --branch feat/add-x develop
62+
git commit --signoff --message "feat: add support for x
63+
Added support for x.
64+
65+
Signed-off-by: Jane Doe <[email protected]>
66+
67+
Ref: #123"
68+
git push origin feat/add-x
2669
```
2770

28-
### Staying In Sync With Upstream
71+
### Formatting Commit Messages
72+
73+
We follow the conventions on [How to Write a Git Commit Message][git-commit] and [Conventional Commits][conventional-commits].
2974

30-
When your branch gets out of sync with the `vmware/main` branch, use the following to update:
75+
Be sure to include any related GitHub issue references in the commit message.
76+
77+
Example:
78+
79+
```markdown
80+
feat: add support for x
81+
82+
Added support for x.
83+
84+
Signed-off-by: Jane Doe <[email protected]>
85+
86+
Ref: #123
87+
```
88+
89+
See [GitHub flavored markdown syntax][gh-markdown] for referencing issues, pull requests, and commits.
90+
91+
### Rebasing the Pull Request with Upstream
92+
93+
When your branch gets out of sync with the upstream `develop` branch, use the following to update:
3194

3295
``` shell
33-
git checkout my-new-feature
34-
git fetch -a
35-
git pull --rebase upstream main
36-
git push --force-with-lease origin my-new-feature
96+
git checkout feat/add-x
97+
git fetch --all
98+
git pull --rebase upstream develop
99+
git push --force-with-lease origin feat/add-x
37100
```
38101

39-
### Updating Pull Requests
102+
### Updating a Pull Request
40103

41-
If your PR fails to pass CI or needs changes based on code review, you'll most likely want to squash these changes into
42-
existing commits.
104+
If your pull request fails to pass or needs changes based on code review, you will most likely want to squash these changes into existing commits.
43105

44-
If your pull request contains a single commit or your changes are related to the most recent commit, you can simply
45-
amend the commit.
106+
If your pull request contains a single commit or your changes are related to the most recent commit, you can simply amend the commit.
46107

47108
``` shell
48109
git add .
49110
git commit --amend
50-
git push --force-with-lease origin my-new-feature
111+
git push --force-with-lease origin feat/add-x
51112
```
52113

53114
If you need to squash changes into an earlier commit, you can use:
54115

55116
``` shell
56117
git add .
57118
git commit --fixup <commit>
58-
git rebase -i --autosquash main
59-
git push --force-with-lease origin my-new-feature
119+
git rebase --interactive --autosquash develop
120+
git push --force-with-lease origin feat/add-x
60121
```
61122

62-
Be sure to add a comment to the PR indicating your new changes are ready to review, as GitHub does not generate a
63-
notification when you git push.
64-
65-
### Code Style
66-
67-
### Formatting Commit Messages
68-
69-
We follow the conventions on [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/).
70-
71-
Be sure to include any related GitHub issue references in the commit message. See
72-
[GFM syntax](https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown) for referencing issues
73-
and commits.
74-
75-
## Reporting Bugs and Creating Issues
123+
Be sure to add a comment to the pull request indicating your new changes are ready to review. GitHub does not generate a notification when you `git push`.
76124

77-
When opening a new issue, try to roughly follow the commit message format conventions above.
125+
[conventional-commits]: https://www.conventionalcommits.org/en/v1.0.0/
126+
[git-commit]: http://chris.beams.io/posts/git-commit/
127+
[gh-discussions]: https://github.com/vmware/powershell-module-for-vmware-cloud-foundation-password-management/discussions
128+
[gh-forks]: https://help.github.com/articles/fork-a-repo/
129+
[gh-issues]:https://github.com/vmware/powershell-module-for-vmware-cloud-foundation-password-management/issues
130+
[gh-markdown]: https://guides.github.com/features/mastering-markdown/#GitHub-flavored-markdown
131+
[gh-pulls]: https://help.github.com/articles/creating-a-pull-request/
132+
[vmware-cla-dco]: https://cla.vmware.com/dco

0 commit comments

Comments
 (0)