You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for your interest in contributing to our project. Whether it's a bug
4
-
report, new feature, correction, or additional documentation, we greatly value
5
-
feedback and contributions from our community.
6
-
7
-
Please read through this document before submitting any issues or pull requests
8
-
to ensure we have all the necessary information to effectively respond to your
9
-
bug report or contribution.
10
-
11
-
## Reporting Bugs and Suggesting Enhancements
12
-
13
-
We welcome you to use the [GitHub issues][gh-issues] to report bugs or suggest
14
-
enhancements.
15
-
16
-
When filing an issue, please check existing open, or recently closed, issues to
17
-
make sure someone else hasn't already reported.
18
-
19
-
Please try to include as much information as you can using the issue form.
20
-
Details like these are incredibly useful:
21
-
22
-
- A reproducible test case or series of steps.
23
-
- Any modifications you've made relevant to the bug.
24
-
- Anything unusual about your environment or deployment.
25
-
26
-
## Contributing via Pull Requests
27
-
28
-
Contributions using pull requests are appreciated.
29
-
30
-
**Before** sending us a pull request, please ensure that:
31
-
32
-
1. You [open a discussion][gh-discussions] to discuss any significant work with
33
-
the maintainer(s).
34
-
2. You [open an issue][gh-issues] and link your pull request to the issue for
35
-
context.
36
-
3. You are working against the latest source on the `main` branch.
37
-
4. You check existing open, and recently merged, pull requests to make sure
38
-
someone else hasn't already addressed the problem.
39
-
40
-
To open a pull request, please:
41
-
42
-
1. Fork the repository.
43
-
2. Modify the source; please focus on the **specific** change you are
44
-
contributing.
45
-
3. Ensure local tests pass.
46
-
4. Update the documentation, if required.
47
-
5. Sign-off and commit to your fork
48
-
[using clear commit messages][git-commit]. Please use
49
-
[Conventional Commits][conventional-commits].
50
-
6. Open a pull request, answering any default questions in the pull request.
51
-
7. Pay attention to any automated failures reported in the pull request, and
52
-
stay involved in the conversation.
53
-
54
-
GitHub provides additional documentation on [forking a repository][gh-forks] and
55
-
[creating a pull request][gh-pull-requests].
3
+
We greatly value feedback and contributions from our community.
4
+
5
+
Please review this document before submitting any issues or pull requests to ensure we
6
+
have all the necessary information to effectively collaborate on your contribution.
7
+
8
+
> [!TIP]
9
+
If you need help or have questions about using the plugin, please refer to the
10
+
[documentation](https://github.com/vmware/packer-plugin-vsphere/tree/main/docs) or open
11
+
a [discussion][gh-discussions].
12
+
13
+
## Issues
14
+
15
+
Use [GitHub issues][gh-issues] to report bugs or suggest enhancements using the
16
+
following guidelines.
17
+
18
+
> [!WARNING]
19
+
> Issues that do not follow the guidelines may be closed by the maintainers without
20
+
> further investigation.
21
+
22
+
Before opening an issue, please [search existing issues](https://github.com/vmware/packer-plugin-vsphere/issues?q=is%3Aissue+is%3Aopen+label%3Abug)
23
+
to avoid duplicates.
24
+
25
+
When opening an issue, use the provided issue form to ensure that you provide all the
26
+
necessary details. These details are important for maintainers to understand and
27
+
reproduce the issue.
28
+
29
+
> [!IMPORTANT]
30
+
> - Ensure that you are using a recent version of the plugin.
31
+
> - Ensure that you are using a supported version of VMware vSphere. The plugin supports versions in accordance with the [Broadcom Product Lifecycle][product-lifecycle].
32
+
33
+
> [!TIP]
34
+
> - Learn about [formatting code on GitHub](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#quoting-code).
35
+
> - Learn about [referencing issues](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#referencing-issues-and-pull-requests).
36
+
> - Learn about [creating a GitHub Gist](https://docs.github.com/en/get-started/writing-on-github/editing-and-sharing-content-with-gists/creating-gists).
37
+
38
+
## Pull Requests
39
+
40
+
Use GitHub pull requests to propose changes to the codebase using the following guidelines.
41
+
42
+
> [!WARNING]
43
+
> Pull requests that do not follow the guidelines may be closed by the maintainers
44
+
> without further review.
45
+
46
+
**Before** submitting a pull request, ensure that:
47
+
48
+
1. You have [opened a discussion][gh-discussions] to discuss any **significant** work with
49
+
the maintainer(s). This ensures that your contribution is aligned with the
50
+
project's direction and avoids unnecessary work.
51
+
2. You have identified or [open an issue][gh-issues]. This ensures that your contribution
52
+
focuses on a specific topic and avoids duplicating effort.
53
+
3. You have forked the repository. Refer to the [GitHub documentation][gh-forks] for help.
54
+
3. You are working against the latest source on the `main` branch. You may need to
55
+
rebase your branch against the latest `main` branch.
56
+
4. You have created a topic branch based on `main`. Do not work directly on the `main` branch.
57
+
5. You have modified the source based on logical units of work. Focus on the specific change
58
+
you are contributing. Pull requests that contain multiple unrelated changes will be
59
+
rejected.
60
+
4. You have followed the existing style and conventions of the project.
61
+
5. You have added tests for your changes.
62
+
5. You have generated the updated documentation and associated assets by running `make generate`.
63
+
5. You have tested building the plugin by running `make build`.
64
+
7. You have tested your changes with a local build of the plugin by running `make dev`.
65
+
9. You have verified all new and existing tests are passing by running `make test`.
66
+
10. You have used [Conventional Commits][conventional-commits] format for commit messages.
67
+
11. You have signed-off and committed your changes [using clear commit messages][git-commit].
68
+
69
+
When opening a pull request, ensure that:
70
+
71
+
1. You title your pull request using the [Conventional Commits][conventional-commits] format.
72
+
2. You provide a detailed description of the changes in the pull request template.
73
+
2. You open any work-in-progress pull requests as a draft.
74
+
3. You mark the pull request as ready for review when you are ready for it to be reviewed.
75
+
4. You follow the status checks for the pull request to ensure that all checks are passing.
76
+
5. You stay involved in the conversation with the maintainers to ensure that your contribution
77
+
can be reviewed.
78
+
79
+
> [!TIP]
80
+
> If you have any questions about the contribution process, open a [discussion][gh-discussions].
56
81
57
82
### Contributor Flow
58
83
59
84
This is an outline of the contributor workflow:
60
85
61
-
- Create a topic branch from where you want to base your work.
62
-
- Make commits of logical units.
63
-
- Make sure your commit messages are
64
-
[in the proper format][conventional-commits].
65
-
- Push your changes to the topic branch in your fork.
66
-
- Submit a pull request. If the pull request is a work in progress, please open
67
-
as draft.
68
-
69
86
Example:
70
87
71
88
```shell
@@ -82,7 +99,7 @@ git push origin feat/add-x
82
99
83
100
### Formatting Commit Messages
84
101
85
-
We follow the conventions on [How to Write a Git Commit Message][git-commit] and
102
+
Follow the conventions on [How to Write a Git Commit Message][git-commit] and use
86
103
[Conventional Commits][conventional-commits].
87
104
88
105
Be sure to include any related GitHub issue references in the commit message.
@@ -99,7 +116,7 @@ Signed-off-by: Jane Doe <jdoe@example.com>
99
116
Ref: #123
100
117
```
101
118
102
-
### Staying In Sync With Upstream
119
+
### Stay In Sync With Upstream
103
120
104
121
When your branch gets out of sync with the `upstream/main` branch, use the
105
122
following to update:
@@ -130,22 +147,20 @@ If you need to squash changes into an earlier commit, you can use:
130
147
```shell
131
148
git add .
132
149
git commit --fixup <commit>
133
-
git rebase --interactive --autosquash upsstream/main
150
+
git rebase --interactive --autosquash upstream/main
134
151
git push --force-with-lease origin feat/add-x
135
152
```
136
153
137
-
Be sure to add a comment to the pull request indicating your new changes are
138
-
ready to review, as GitHub does not generate a notification when you `git push`.
139
-
140
-
## Finding Contributions to Work On
154
+
When resolving review comments, mark the conversation as resolved and note the commit
155
+
SHA that addresses the review comment. This helps maintainers verify the issue has been
156
+
resolved.
141
157
142
-
Looking at the existing issues is a great way to find something to contribute
143
-
on. If you have an idea you'd like to discuss,
144
-
[open a discussion][gh-discussions].
158
+
Request a review from the maintainers when you are ready for a follow-up review.
0 commit comments