Add style guide and code quality standards
What would you like to be added:
As the functionality and number of packages in krel continues to grow, we are starting to see divergence in how new features are implemented, tested, and maintained. We should add style guidelines and quality standards so that someone is completely new to the project can make contributions that are easily reviewed and integrated without degrading quality.
Why is this needed:
There are a few key areas that we have determined as important to maintain quality and consistency:
- Exposing the minimum required public API in packages (i.e. bias towards private fields in structs and interfaces)
- Follow pattern of "accepting interfaces, returning structs" (i.e Robustness principle)
- Avoid "testing through" (i.e. make your interfaces easily mockable)
- Generate mocks in a consistent manner (we use counterfeiter)
- Establish and measure a (potentially flexible) threshold for unit test coverage
- Establish what types of features require integration / e2e testing
This is not an all-inclusive list, but can serve as a good starting point for a document that we can continually iterate on.
/assign @hasheddan @saschagrunert
Thanks for opening this, Dan! /priority important-soon /milestone v1.21
+1 Thanks for pointing this out dan, I certainly would like to get some some of these well established (and understood!) to start implementing them. Sometimes I get lost and I feel waste too much time reinventing the wheel.
@hasheddan when do we want to work on this issue? Seems not part of our roadmap planning but we may wire it into some side-effort.
Fun discussion w/ @wilsonehusin and some of the team on Twitter: https://twitter.com/stephenaugustus/status/1359354950019657730?s=20
Let's try and tackle this as a priority for v1.21.
/assign @puerco @wilsonehusin /unassign @hasheddan @saschagrunert /milestone v1.22
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue or PR with
/reopen - Mark this issue or PR as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closing this issue.
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue or PR with
/reopen- Mark this issue or PR as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I was thinking about this again, thanks to @helayoty! (ref: https://twitter.com/helayoty/status/1497366986841460738) /reopen
@kubernetes/release-engineering -- Thoughts here?
@justaugustus: Reopened this issue.
In response to this:
I was thinking about this again, thanks to @helayoty! (ref: https://twitter.com/helayoty/status/1497366986841460738) /reopen
@kubernetes/release-engineering -- Thoughts here?
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
These are probably a good start:
- https://www.kubernetes.dev/docs/guide/coding-convention/
- https://www.pullrequest.com/blog/create-a-programming-style-guide/
- https://google.github.io/styleguide/
- https://github.com/golang/go/wiki/CodeReviewComments
- https://go.dev/doc/effective_go
/unassign @wilsonehusin @puerco /assign @justaugustus @helayoty
Heba, I'm going to take an initial pass using the awesome Crossplane one @hasheddan linked: https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md
From there, we can iterate on improvements together!
/unassign @wilsonehusin @puerco /assign @justaugustus @helayoty
Heba, I'm going to take an initial using the awesome Crossplane one @hasheddan linked: https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md
From there, we can iterate on improvements together!
While it's so hard now to top this amazing work, I totally agree.
Heba, I'm going to take an initial pass using the awesome Crossplane one @hasheddan linked: https://github.com/crossplane/crossplane/blob/master/CONTRIBUTING.md
First pass: https://github.com/kubernetes/sig-release/pull/1862
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@justaugustus the first pass form your last comment is merged.
Would a follow up for this be to reference the k/sig-release contributing doc on all sig release repos in the CONTRIBUTING.md so its clear there is sort of one central contributing guide for sig release.
Would that be basically every project in https://github.com/kubernetes/community/tree/master/sig-release#subprojects?