Simplified PR template #826
Conversation
|
I believe it is the "/kind" that associates the right reviewers with code ownership. is it your expectation that we don't use kind any more? or that committers should commit that to memory? or? |
|
/kind infrastructure |
|
@kensipe that is a prow feature, we lost that. Also I think most people were not using it. You can (and should) still assign labels via github labels as you would normally without typing it into comments :) |
| @@ -32,15 +15,3 @@ https://github.com/kudobuilder/kudo/blob/master/RELEASE.md | |||
| Usage: `Fixes #<issue number>`, or `Fixes (paste link of issue)`. | |||
| --> | |||
| Fixes # | |||
There was a problem hiding this comment.
Which issue(s) this PR fixesandFixes #are the same and we should keep one.Does this PR introduce a user-facing change?- I'd keep this one too. It would be easy to copy-paste it for the release notes.
There was a problem hiding this comment.
I can pull you some stats but I did not see people using that release notes column so far or it was something you would not put to release notes directly. We need to have that automation or I feel like it's waste of time even for me to fill that part and if it's waste of time, I don't need to have it in the PR template 🙂
nobody is really manually going through the PRs when the release happens to copy this out because we have automatic changelog done by the go releaser from commit messages
which of course is not perfect 🙂 but I am not sure THAT is the part we need to improve the most right now 🙂 So removing that from my point of view does not make things worse - we don't write the release notes there and we don't collect them. I am 100% for adding it back when we have that automation.
and re: fixes - that need to be there because that is a keyword to github. The other is a heading - the PR is splitted into several sections, this one is for related tickets. I can drop the heading if we don't want to have the separation. That part I don't care about that much 🙂
There was a problem hiding this comment.
Ok, you got me convinced there. I'd still remove Which issue(s) this PR fixes: since I don't know what I would put there (issues numbers are already in Fixes #).
There was a problem hiding this comment.
We're also reversing the relationship to have longer-lasting tracking issues and shorter lasting PRs.
|
I let this sit around for longer, I hope everyone had a chance to comment, we can still adjust after the merge |
What this PR does / why we need it:
I've removed all the things that we typically don't use and what is not used by automation (or won't be after dismissing prow). We can always re-introduce.
Which issue(s) this PR fixes:
Fixes #