Create a pleasant developer workflow experience

[awgreene]

A bit of a catch-all for issues related to creating a good developer experience.

Brainstorming:

• Create a PR template that defines what steps a reviewer should take | Completed in Introduce Pull Request Template operator-controller#124
  --Check for unit or e2e tests.
  -- API Documentation
  -- Commits are prefixed with one of (Bug Fix, Feature, Doc). Example.
  -- Commits properly convey what changes are being introduced.
  -- Format is left to the contributor's and reviewer's discretion.
  -- Commits are signed (git commit --signoff) | Completed by enabling DCO in the repo
  --- Why do we need this?
  ---- https://github.com/cncf/foundation/blob/main/dco-guidelines.md
  ---- https://drewdevault.com/2021/04/12/DCO.html

Create a Makefile
-Consistent across projects.

• RukPak's existing Makefile should be referenced when generating this list.
  -- Existing makefile targets should be re-evaluated.
  -- The Makefile and GitHub workflows should first be implemented in RukPak and then mirrored in the other projects.

• Standardize the developer experience across Deppy, RukPak, and Operator-Controller.

• Running make prints out available targets. | Changed to make help, completed

• run: If applicable, spins up a kind cluster and runs the container. | Completed

• test-e2e: Runs a set of e2e tests. | Completed

• test-unit: Runs a set of unit tests. | Completed

• RukPak's existing Makefile should be referenced when generating this list.
  -- Existing makefile targets should be re-evaluated.
  -- The Makefile and GitHub workflows should first be implemented in RukPak and then mirrored in the other projects.

• Standardize the developer experience across Deppy, RukPak, and Operator-Controller.

Nice to have:

• Support remote debugging.
• The version of the Go compiler is loosely enforced by the go.mod file's go compatibility version, and we have the github actions configured to use the go version aligned with the go.mod file.

[joelanford]

Context: Rukpak has a relatively good developer experience, and we want to use it as a model for the other OLMv1 repositories. With that in mind, this task is about making whatever adjustments (if any) that are necessary to make Rukpak's setup a model we can replicate in other projects.

Some of the thoughts in the description are already happening in rukpak. For those, are there any improvements we could make?

On this list, what are must-haves and what are nice-to-haves?

[github-actions]

This issue has become stale because it has been open 60 days with no activity. The maintainers of this repo will remove this label during issue triage or it will be removed automatically after an update. Adding the lifecycle/frozen label will cause this issue to ignore lifecycle events.