Merge pull request #9 from teamhava/repo-standards

Repo standards

.github/workflows/release.yml

@@ -112,9 +112,6 @@ jobs:
         uses: actions/setup-go@v4
         with:
           go-version: '1.20.7'
-      -
-        name: Set up Go
-        uses: actions/setup-go@v4
 
       - name: Set up QEMU
         uses: docker/setup-qemu-action@v2

CONTRIBUTING.md

@@ -0,0 +1,117 @@
+# Contributing to Hava
+
+If you are looking to contribute to this project and want to open a GitHub pull request ("PR"), there are a few guidelines of what we are looking for in patches. Make sure you go through this document and ensure that your code proposal is aligned.
+
+## Fork the repo
+
+You should fork the Hava repo using the "Fork" button at the top right of the Hava GitHub [site](https://github.com/teamhava/hava-ui-cli). You will be doing your development in your fork, then submit a pull request to Hava. There are many resources how to use GitHub effectively, we will not cover those here.
+
+## Adding a feature or fix
+
+If you look at the Hava [Issue](https://github.com/teamhava/hava-ui-cli/issues) there are plenty of bugs and feature requests. 
+
+## Commit guidelines
+
+In the Hava project we like commits and pull requests (PR) to be easy to understand and review. Open source thrives best when everything happening is over documented and small enough to be understood.
+
+### Granular commits
+
+Please try to make every commit as simple as possible, but no simpler. The idea is that each commit should be a logical unit of code. Try not to commit too many tiny changes, for example every line changed in a file as a separate commit. And also try not to make a commit enormous, for example committing all your work at the end of the day.
+
+Rather than try to follow a strict guide on what is or is not best, we try to be flexible and simple in this space. Do what makes the most sense for the changes you are trying to include.
+
+### Commit title and description
+
+Remember that the message you leave for a commit is for the reviewer in the present, and for someone (maybe you) changing something in the future. Please make sure the title and description used is easy to understand and explains what was done. Jokes and clever comments generally don't age well in commit messages. Try to stick to the facts surrounding the problem or request.
+
+## Sign off your work
+
+The `sign-off` is an added line at the end of the explanation for the commit, certifying that you wrote it or otherwise have the right to submit it as an open-source patch. By submitting a contribution, you agree to be bound by the terms of the DCO Version 1.1 and Apache License Version 2.0.
+
+Signing off a commit certifies the below Developer's Certificate of Origin (DCO):
+
+```text
+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.
+```
+
+All contributions to this project are licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/).
+
+When committing your change, you can add the required line manually so that it looks like this:
+
+```text
+Signed-off-by: John Doe <john.doe@example.com>
+```
+
+Creating a signed-off commit is then possible with `-s` or `--signoff`:
+
+```text
+$ git commit -s -m "this is a commit message"
+```
+
+To double-check that the commit was signed-off, look at the log output:
+
+```text
+$ git log -1
+commit 37ceh170e4hb283bb73d958f2036ee5k07e7fde7 (HEAD -> issue-35, origin/main, main)
+Author: John Doe <john.doe@example.com>
+Date:   Mon Aug 1 11:27:13 2020 -0400
+
+    this is a commit message
+
+    Signed-off-by: John Doe <john.doe@example.com>
+```
+
+## Test your changes
+
+This project has a `Makefile` which includes many helpers running both unit and integration tests. Although PRs will have automatic checks for these, it is useful to run them locally, ensuring they pass before submitting changes. Ensure you've bootstrapped once before running tests:
+
+```text
+$ make build-local
+```
+
+
+## Pull Request
+
+If you made it this far and all the tests are passing, it's time to submit a Pull Request (PR) for Hava. Submitting a PR is always a scary moment as what happens next can be an unknown. The Hava project strives to be easy to work with, we appreciate all contributions. Nobody is going to yell at you or try to make you feel bad. We love contributions and know how scary that first PR can be.
+
+### PR Title and Description
+
+Just like the commit title and description mentioned above, the PR title and description is very important for letting others know what's happening. Please include any details you think a reviewer will need to more properly review your PR.
+
+A PR that is very large or poorly described has a higher likelihood of being pushed to the end of the list. Reviewers like PRs they can understand and quickly review.
+
+### What to expect next
+
+Please be patient with the project. We try to review PRs in a timely manner, but this is highly dependent on all the other tasks we have going on. It's OK to ask for a status update every week or two, it's not OK to ask for a status update every day.
+
+It's very likely the reviewer will have questions and suggestions for changes to your PR. If your changes don't match the current style and flow of the other code, expect a request to change what you've done.
+
+## Document your changes
+
+And lastly, when proposed changes are modifying user-facing functionality or output, it is expected the PR will include updates to the documentation as well. Hava is not a project that is heavy on documentation. This will mostly be updating the README and help for the tool.
+
+If nobody knows new features exist, they can't use them!

RELEASE.md

@@ -0,0 +1,102 @@
+# Release
+
+## Creating a release
+
+This release process itself should be as automated as possible, and has only a few steps:
+
+1. **Trigger a new release by pushing a new `tag`**. 
+
+Ideally releasing should be done often with small increments when possible. Unless a
+breaking change is blocking the release, or no fixes/features have been merged, a good
+target release cadence is between every 1 or 2 weeks.
+
+
+## Retracting a release
+
+If a release is found to be problematic, it can be retracted with the following steps:
+
+- Deleting the GitHub Release
+- Add a new `retract` entry in the go.mod for the versioned release
+
+**Note**: do not delete release tags from the git repository since there may already be references to the release
+in the go proxy, which will cause confusion when trying to reuse the tag later (the H1 hash will not match and there
+will be a warning when users try to pull the new release).
+
+
+## Background
+
+A good release process has the following qualities:
+
+1. There is a way to plan what should be in a release
+1. There is a way to see what is actually in a release
+1. Allow for different kinds of releases (major breaking vs backwards compatible enhancements vs patch updates)
+1. Specify a repeatable way to build and publish software artifacts
+
+
+### Planning a release
+
+To indicate a set of features to be released together add each issue to an in-repository
+Milestone named with major-minor version to be released (e.g. `v0.1`). It is OK for other
+features to be in the release that were not originally planned, and these issues and PRs
+do not need to be added to the Milestone in question. Only the set of features that, when
+completed, would allow the release to be considered complete. A Milestone is only used to:
+
+- Plan what is desired to be in a release
+- Track progress to indicate when we may be ready to cut a new release
+
+Not all releases need to be planned. For instance, patch releases for fixes should be
+released when they are ready and when releasing would not interfere with another current
+release (where some partial or breaking features have already been merged).
+
+Unless necessary, feature releases should be small and frequent, which may obviate the
+need for regular release planning under a Milestone.
+
+
+### What is in a release
+
+Milestones are specifically for planning a release, not necessarily tracking all changes
+that a release may bring (and more importantly, not all releases are necessarily planned
+either).
+
+This is one of the (many) reasons for a Changelog. A good Changelog lists changes grouped
+by the type of change (new, enhancement, deprecation, breaking, bug fix, security fix), in
+chronological order (within groups), linking the PR where the change was made in the
+Changelog line. Furthermore, there should be a place to see all released versions, the
+release date for each release, the semantic version of the release, and the set of changes
+for each release.
+
+**This project auto-generates the Changelog contents for each current release and posts the
+generated contents to the GitHub Release page**. Leveraging the GitHub Releases feature
+allows GitHub to manage the Changelog on each release outside of the git source tree while
+still being hosted with the released assets.
+
+The Changelog is generated from the metadata from in-repository issues and PRs, using
+labels to guide what kind of change each item is (e.g. breaking, new feature, bug fix,
+etc). Only issues/PRs with select labels are included in the Changelog, and only if the
+issue/PR was created after the last release. Additional labels are used to exclude items
+from the Changelog.
+
+The above suggestions imply that we should:
+
+- Ensure there is a sufficient title for each PR and issue title to be included in the
+  Changelog
+- The appropriate label is applied to PRs and/or issues to drive specific change type
+  sections (deprecated, breaking, security, bug, etc)
+
+**With this approach as we cultivate good organization of PRs and issues we automatically
+get an equally good Changelog.**
+
+
+### Major, minor, and patch releases
+
+The latest version of the tool is the only supported version, which implies that multiple
+parallel release branches will not be a regular process (if ever). Multiple releases can
+be planned in parallel, however, only one can be actively developed at a time. That is, if
+PRs attached to a release Milestone have been merged into the main branch, that release is
+now the "next" release. **This implies that the source of truth for release lies with the
+git log and Changelog, not with the release Milestones** (which are purely for planning and
+tracking).
+
+Semantic versioning should be used to indicate breaking changes, new features, and fixes.
+The exception to this is `< 1.0`, where the major version is not bumped for breaking changes,
+instead the minor version indicates both new features and breaking changes.