chore(xfer): update contributing (#588)

Post-transfer update of `CONTRIBUTING.md`.

Signed-off-by: Ryan Johnson <ryan.johnson@broadcom.com>

Author: tenthirtyam

.github/CONTRIBUTING.md

@@ -1,271 +1,151 @@
-# Contributing to vSphere Plugin
+# Contributing Guidelines
 
-**First:** if you're unsure or afraid of _anything_, just ask or submit the
-issue or pull request anyway. You won't be yelled at for giving your best
-effort. The worst that can happen is that you'll be politely asked to change
-something. We appreciate any sort of contributions, and don't want a wall of
-rules to get in the way of that.
+Thank you for your interest in contributing to our project. Whether it's a bug
+report, new feature, correction, or additional documentation, we greatly value
+feedback and contributions from our community.
 
-However, for those individuals who want a bit more guidance on the best way to
-contribute to the project, read on. This document will cover what we're looking
-for. By addressing all the points we're looking for, it raises the chances we
-can quickly merge or address your contributions.
+Please read through this document before submitting any issues or pull requests
+to ensure we have all the necessary information to effectively respond to your
+bug report or contribution.
 
-When contributing in any way to the Packer project (new issue, PR, etc), please
-be aware that our team identifies with many gender pronouns. Please remember to
-use nonbinary pronouns (they/them) and gender neutral language ("Hello folks")
-when addressing our team. For more reading on our code of conduct, please see the
-[HashiCorp community guidelines](https://www.hashicorp.com/community-guidelines).
+## Reporting Bugs and Suggesting Enhancements
 
-## Issues
+We welcome you to use the [GitHub issues][gh-issues] to report bugs or suggest
+enhancements.
 
-### Reporting an Issue
+When filing an issue, please check existing open, or recently closed, issues to
+make sure someone else hasn't already reported.
 
-- Make sure you test against the latest released version. It is possible we
-  already fixed the bug you're experiencing.
+Please try to include as much information as you can using the issue form.
+Details like these are incredibly useful:
 
-- Run packer with debug output with the environment variable `PACKER_LOG`.
-  For example: `PACKER_LOG=1 packer build template.pkr.hcl`. Take the _entire_
-  output and create a [gist](https://gist.github.com) for linking to in your
-  issue. Packer should strip sensitive keys from the output, but take a look
-  through just in case.
+- A reproducible test case or series of steps.
+- Any modifications you've made relevant to the bug.
+- Anything unusual about your environment or deployment.
 
-- Provide a reproducible test case. If a contributor can't reproduce an issue,
-  then it dramatically lowers the chances it'll get fixed. And in some cases,
-  the issue will eventually be closed.
+## Contributing via Pull Requests
 
-- Respond promptly to any questions made by the Packer team to your issue. Stale
-  issues will be closed.
+Contributions using pull requests are appreciated.
 
-### Issue Lifecycle
+**Before** sending us a pull request, please ensure that:
 
-1. The issue is reported.
+1. You [open a discussion][gh-discussions] to discuss any significant work with
+   the maintainer(s).
+2. You [open an issue][gh-issues] and link your pull request to the issue for
+   context.
+3. You are working against the latest source on the `main` branch.
+4. You check existing open, and recently merged, pull requests to make sure
+   someone else hasn't already addressed the problem.
 
-2. The issue is verified and categorized by a Packer collaborator.
-   Categorization is done via tags. For example, bugs are marked as "bugs" and
-   simple fixes are marked as "good first issue".
+To open a pull request, please:
 
-3. Unless it is critical, the issue is left for a period of time (sometimes many
-   weeks), giving outside contributors a chance to address the issue.
+1. Fork the repository.
+2. Modify the source; please focus on the **specific** change you are
+   contributing.
+3. Ensure local tests pass.
+4. Update the documentation, if required.
+5. Sign-off and commit to your fork
+   [using clear commit messages][git-commit]. Please use
+   [Conventional Commits][conventional-commits].
+6. Open a pull request, answering any default questions in the pull request.
+7. Pay attention to any automated failures reported in the pull request, and
+   stay involved in the conversation.
 
-4. The issue is addressed in a pull request or commit. The issue will be
-   referenced in the commit message so that the code that fixes it is clearly
-   linked.
+GitHub provides additional documentation on [forking a repository][gh-forks] and
+[creating a pull request][gh-pull-requests].
 
-5. Sometimes, if you have a specialized environment or use case, the maintainers
-   may ask for your help testing the patch.
+### Contributor Flow
 
-6. The issue is closed.
+This is an outline of the contributor workflow:
 
+- Create a topic branch from where you want to base your work.
+- Make commits of logical units.
+- Make sure your commit messages are
+  [in the proper format][conventional-commits].
+- Push your changes to the topic branch in your fork.
+- Submit a pull request. If the pull request is a work in progress, please open
+  as draft.
 
+Example:
 
-## Setting up Go
+```shell
+git remote add upstream https://github.com/<org-name>/<repo-name>.git
+git checkout -b feat/add-x main
+git commit --signoff --message "feat: add support for x
+  Added support for x.
 
-If you have never worked with Go before, you will have to install its
-runtime in order to build packer with the vSphere plugin.
-
-1. This project always releases from the latest version of golang.
-[Install go](https://golang.org/doc/install#install) To properly build from
-source, you need to have golang >= 1.21
-
-## Setting up vSphere plugin for dev
-
-With Go installed, you can already `go get` the vSphere plugin and `make dev` in
-order to compile and test it. These instructions target
-POSIX-like environments (macOS, Linux, Cygwin, etc.) so you may need to
-adjust them for Windows or other shells.
-
-1. Download the vSphere plugin source (and its dependencies) by running
-   `go get github.com/hashicorp/packer-plugin-vsphere`. This will download the source to
-   `$GOPATH/src/github.com/hashicorp/packer-plugin-vsphere`.
-
-2. When working on the vSphere plugin, first `cd $GOPATH/src/github.com/hashicorp/packer-plugin-vsphere`
-   so you can run `make dev` and easily access other files. `make dev` will build the packer-plugin-vsphere binary and install it under `$HOME/.packer.d/plugins/`.
-
-3. Make your changes to the vSphere plugin source. You can run `make dev` to build and install locally, and `make test` to run unit tests.
-   Any compilation errors will be shown when the binaries are rebuilding. If you don't have `make` you can simply run `go build -o packer-plugin-vsphere` from the project root, and `mv packer-plugin-vsphere ~/.packer.d/plugins/packer-plugin-vsphere` to install the plugin.
-
-4. After building the vSphere plugin successfully, use the latest version of Packer to build a machine and verify your changes. In the [example folder](https://github.com/hashicorp/packer-plugin-vsphere/blob/main/example) we provide a basic template. Comment out the `packer {}` block to force Packer use the development binary installed in the previous step.
-
-5. If everything works well and the tests pass, run `go fmt ./...` on your code before
-   submitting a pull-request.
-
-
-### Opening a Pull Request
-
-Thank you for contributing! When you are ready to open a pull-request, you will
-need to [fork the vSphere plugin](https://github.com/hashicorp/packer-plugin-vsphere#fork-destination-box), push your
-changes to your fork, and then open a pull-request.
-
-For example, my github username is `myuser`, so I would do the following:
+  Signed-off-by: Jane Doe <jdoe@example.com>
 
+  Ref: #123"
+git push origin feat/add-x
 ```
-git checkout -b f-my-feature
-# Develop a patch.
-git push https://github.com/myuser/packer-plugin-vsphere f-my-feature
-```
-
-From there, open your fork in your browser to open a new pull-request.
-
-### Pull Request Lifecycle
-
-1. You are welcome to submit your pull request for commentary or review before
-   it is fully completed. Please prefix the title of your pull request with
-   "[WIP]" to indicate this. It's also a good idea to include specific questions
-   or items you'd like feedback on.
-
-2. Once you believe your pull request is ready to be merged, you can remove any
-   "[WIP]" prefix from the title and a core team member will review.
-
-3. One of vSphere plugin's core team members will look over your contribution and
-   either merge, or provide comments letting you know if there is anything left
-   to do. We do our best to provide feedback in a timely manner, but it may take
-   some time for us to respond. We may also have questions that we need answered
-   about the code, either because something doesn't make sense to us or because
-   we want to understand your thought process.
-
-4. If we have requested changes, you can either make those changes or, if you
-   disagree with the suggested changes, we can have a conversation about our
-   reasoning and agree on a path forward. This may be a multi-step process. Our
-   view is that pull requests are a chance to collaborate, and we welcome
-   conversations about how to do things better. It is the contributor's
-   responsibility to address any changes requested. While reviewers are happy to
-   give guidance, it is unsustainable for us to perform the coding work necessary
-   to get a PR into a mergeable state.
-
-5. Once all outstanding comments and checklist items have been addressed, your
-   contribution will be merged! Merged PRs will be included in the next
-   Packer release. The core team takes care of updating the
-   [CHANGELOG.md](../CHANGELOG.md) as they merge.
-
-6. In rare cases, we might decide that a PR should be closed without merging.
-   We'll make sure to provide clear reasoning when this happens.
-
-### Tips for Working on Packer
-
-#### Getting Your Pull Requests Merged Faster
 
-It is much easier to review pull requests that are:
+### Formatting Commit Messages
 
-1. Well-documented: Try to explain in the pull request comments what your
-   change does, why you have made the change, and provide instructions for how
-   to produce the new behavior introduced in the pull request. If you can,
-   provide screen captures or terminal output to show what the changes look
-   like. This helps the reviewers understand and test the change.
+We follow the conventions on [How to Write a Git Commit Message][git-commit] and
+[Conventional Commits][conventional-commits].
 
-2. Small: Try to only make one change per pull request. If you found two bugs
-   and want to fix them both, that's _awesome_, but it's still best to submit
-   the fixes as separate pull requests. This makes it much easier for reviewers
-   to keep in their heads all of the implications of individual code changes,
-   and that means the PR takes less effort and energy to merge. In general, the
-   smaller the pull request, the sooner reviewers will be able to make time to
-   review it.
+Be sure to include any related GitHub issue references in the commit message.
 
-3. Passing Tests: Based on how much time we have, we may not review pull
-   requests which aren't passing our tests. (Look below for advice on how to
-   run unit tests). If you need help figuring out why tests are failing, please
-   feel free to ask, but while we're happy to give guidance it is generally
-   your responsibility to make sure that tests are passing. If your pull request
-   changes an interface or invalidates an assumption that causes a bunch of
-   tests to fail, then you need to fix those tests before we can merge your PR.
+Example:
 
-If we request changes, try to make those changes in a timely manner. Otherwise,
-PRs can go stale and be a lot more work for all of us to merge in the future.
+```markdown
+feat: add support for x
 
-Even with everyone making their best effort to be responsive, it can be
-time-consuming to get a PR merged. It can be frustrating to deal with
-the back-and-forth as we make sure that we understand the changes fully. Please
-bear with us, and please know that we appreciate the time and energy you put
-into the project.
+Added support for x.
 
-#### Working on forks
+Signed-off-by: Jane Doe <jdoe@example.com>
 
-The easiest way to work on a fork is to set it as a remote of the the vSphere plugin
-project. After following the steps in "Setting up Go to work on the vSphere plugin":
-
-1. Navigate to the code:
-
-   `cd $GOPATH/src/github.com/hashicorp/packer-plugin-vsphere`
-
-2. Add the remote by running:
-
-   `git remote add <name of remote> <github url of fork>`
-
-   For example:
-
-   `git remote add myuser https://github.com/myuser/packer-plugin-vsphere.git`
-
-3. Checkout a feature branch:
-
-   `git checkout -b new-feature`
-
-4. Make changes.
-5. (Optional) Push your changes to the fork:
-
-   `git push -u <name of remote> new-feature`
-
-This way you can push to your fork to create a PR, but the code on disk still
-lives in the spot where the go cli tools are expecting to find it.
-
-#### Go modules & go vendor
-
-If you are submitting a change that requires new or updated dependencies,
-please include them in `go.mod`/`go.sum`. This
-helps everything get tested properly in CI.
-
-Note that you will need to use [go
-mod](https://github.com/golang/go/wiki/Modules) to do this. This step is
-recommended but not required.
-
-Use `go get <project>` to add dependencies to the project. See [go mod quick
-start](https://github.com/golang/go/wiki/Modules#quick-start) for examples.
-
-Please only apply the minimal vendor changes to get your PR to work. The vSphere plugin
-does not attempt to track the latest version for each dependency.
-
-#### HCL2 Spec code generation
-
-Packer relies on `go generate` to generate HCL2's bridging code. First you should install the command with `go install github.com/hashicorp/packer-plugin-sdk/cmd/packer-sdc@latest`, then you generate with
-`go generate ./...`. This should update/create `*.hcl2spec.go` file(s).
+Ref: #123
+```
 
-#### Running Unit Tests
+### Staying In Sync With Upstream
 
-To run unit tests, simply call
+When your branch gets out of sync with the `upstream/main` branch, use the
+following to update:
 
+```shell
+git checkout feat/add-x
+git fetch --all
+git pull --rebase upstream main
+git push --force-with-lease origin feat/add-x
 ```
-make test
-```
-
-from the plugin's project root.
 
-#### Running Builder Acceptance Tests
+### Updating Pull Requests
 
-If the vSphere Plugin has [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing), these probably have some requirements such as environment variables to be set for API tokens and keys. Each test should error and tell you what are missing, so those are not documented here.
+If your pull request fails to pass or needs changes based on code review, you'll
+most likely want to squash these changes into existing commits.
 
-If you're working on a feature and want to verify it is functioning (and also hasn't broken anything else), we recommend creating or running the acceptance tests.
+If your pull request contains a single commit or your changes are related to the
+most recent commit, you can simply amend the commit.
 
-**Warning:** The acceptance tests create/destroy/modify _real resources_, which
-may incur costs for real money. In the presence of a bug, it is possible that
-resources may be left behind, which can cost money even though you were not
-using them. We recommend running tests in an account used only for that purpose
-so it is easy to see if there are any dangling resources, and so production
-resources are not accidentally destroyed or overwritten during testing.
+```shell
+git add .
+git commit --amend
+git push --force-with-lease origin feat/add-x
+```
 
-To run the acceptance tests, invoke `make testacc`:
+If you need to squash changes into an earlier commit, you can use:
 
-```
-make testacc
-...
+```shell
+git add .
+git commit --fixup <commit>
+git rebase --interactive --autosquash upsstream/main
+git push --force-with-lease origin feat/add-x
 ```
 
-The `TEST` variable lets you narrow the scope of the acceptance tests to a
-specific package / folder.
+Be sure to add a comment to the pull request indicating your new changes are
+ready to review, as GitHub does not generate a notification when you `git push`.
 
-#### Debugging Plugins
+## Finding Contributions to Work On
 
-Each packer plugin runs in a separate process and communicates via RPC over a
-socket therefore using a debugger will not work (be complicated at least).
+Looking at the existing issues is a great way to find something to contribute
+on. If you have an idea you'd like to discuss,
+[open a discussion][gh-discussions].
 
-The Packer and plugins code provides more detailed logs when ran with PACKER_LOG
-turned on. If that doesn't work, adding some extra debug print outs when you have
-homed in on the problem is usually enough.
+[conventional-commits]: https://conventionalcommits.org
+[gh-discussions]: https://github.com/vmware/packer-plugin-vsphere/discussions
+[gh-forks]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo
+[gh-issues]: https://github.com/vmware/packer-plugin-vsphere/issues
+[gh-pull-requests]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request
+[git-commit]: https://cbea.ms/git-commit