-
-
Notifications
You must be signed in to change notification settings - Fork 318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add issue template + improve contributor help docs #699
Conversation
.github/ISSUE_TEMPLATE/bug_report.md
Outdated
List the versions and features of any `kube` and `k8s-openapi` crates you are using. | ||
Output of `grep kube Cargo.toml` | ||
Output of `grep k8s-openapi Cargo.toml` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably want to look at Cargo.lock instead (since that contains the actual versions used). But that is a bit more annoying to parse...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was on the fence about doing what tracing does to just ask users to install cargo-tree to parse that better. But when using cargo tree
you don't get feature information..
Don't want to make the process too convoluted either - i'd rather get a bug report with most of the info than no bug report at all. Maybe an alternative here for cargo tree -i k8s-openapi
will point users towards giving us something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah makes sense.
@@ -0,0 +1,34 @@ | |||
--- | |||
name: 💡 Feature Request | |||
about: I have a suggestion (and may want to implement it 🙂)! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth asking about whether this is a request (for someone else to implement) or a proposal (to implement themselves)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a dropdown for whether or not they would like to contribute (checkbox caused a 1/1 task complete on the issue and looks ugly + dropdown allows for a tentative maybe answer).
Signed-off-by: clux <[email protected]>
- clean up bad docs on integration tests - rename tests folder to integration (tiny part of tests here) - classify tests with/without kubernetes access - clean up makefile - advocate for k3d everywhere - remove dead references to circleci - add more pr template + issue template config Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
2705fc0
to
869418a
Compare
Have changed it around a bit. I actually quite like babels issue forms using the public form beta: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms To verify that it works, i have a test repo here that mirrors how it would look: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The form looks great!
Signed-off-by: clux <[email protected]>
Signed-off-by: clux <[email protected]>
pr + issue templates
not going super deep. here. there are tons of things we could do. See for instance
That stuff feels like it's going too far. But it might be good to auto-add something like a
triage
label in the future (which is something we can specify in the templates)cleanups
As I was adding to the contributing.md, saw things that ought to have clarification and ended up: