Adding a contribution workflow description#443
Conversation
| Before starting to work on your PR, please make sure that there is a GitHub issue created | ||
| by you or someone else to describe the bug or feature you’re submitting code or documentation for. |
There was a problem hiding this comment.
What is the reason for reverting this guidance?
There was a problem hiding this comment.
I moved some text around to consolidate/group content with respect to the other changes above.
I also wonder whether or not we would like to have the text as is, in either versions, or rather say that PRs should be tied to bug reports or feature proposals?
There was a problem hiding this comment.
Our process as of the last ~two years (unless that was also voted to be changed on in the community call two weeks ago) is that PRs are not required to have an issue associated with them.
| language](https://ltsi.linuxfoundation.org/software/signed-off-process/) | ||
| used by the Linux kernel project. | ||
|
|
||
| ## GitHub best practices |
There was a problem hiding this comment.
Maybe we should just get rid of this while section as it's outdated, or covered elsewhere now?
There was a problem hiding this comment.
I'm game. I thought about it too, but wasn't exactly sure how to proceed.
I think the '### Submit issues before PRs' section can be removed.
The '### Issue tracking' section refers to the challenge of people not being sure which repo to open the issue in. That note seems a bit outdated to me as development mostly happens in kata-containers now. Is that note still needed here or somewhere else?
And finally, the '### Closing issues' section could just go under '## GitHub workflow'?
There was a problem hiding this comment.
Closing issues isn't accurate as we don't need the Fixes comment in the commit, so I'm not sure there is much extra value beyond standard github practice to mention?
There was a problem hiding this comment.
Was that 'Fixes' label ever set up as a hook to close issues and it just stopped working? Or it's just a manual indicator to trigger closing related issue(s)?
There was a problem hiding this comment.
Fixes is a built-in github feature, nothing that we did.
There was a problem hiding this comment.
Ok, so you're saying that it's a built-in GH feature that Kata doesn't use anymore, or maybe never really did?
There was a problem hiding this comment.
It's a built in feature, but as we've discussed - it's not required to have a fixes in a commit anymore, so I don't understand why we'd want to document that?
| If you’re adding new functionality or feature, you will first need to create a ‘Design proposal’ | ||
| before starting to work on the implementation. |
There was a problem hiding this comment.
Where did this guidance come from?
There was a problem hiding this comment.
This is a new proposal to create a workflow to be a bit more coordinated when adding new features. Having some information about what gets added to the runtime would be helpful for release announcements and general tracking on what has changed and how, without the need to go through git commits and dig into the code.
@zvonkok brought up the Kubernetes Enhancement Process as an example, and noted that we should have something simpler in terms of lifecycle. This is an attempt to find a middle ground.
There was a problem hiding this comment.
Ok, I think a big change like this need to have wider discussions on a community meeting
There was a problem hiding this comment.
Ah ok - it sounds like this was discussion in the meeting whilst I was on vacation, so I guess it's been approved by the rest of the AC, so I'm outvoted, so I withdraw the comment
There was a problem hiding this comment.
The need to create something was discussed, but we haven't outlined the details yet. I created the PR to have a proposal and hash out whether or not this is what folks had in mind in the review.
ildikov
force-pushed
the
feature-contrib-workflow
branch
from
4189621 to
f961b10
Compare
This patch adds a description to outline the process to submit a bug or a feature request. It also makes minor changes in the document flow to accommodate the new sections that were added. Signed-off-by: Ildiko Vancsa <ildiko.vancsa@gmail.com>
ildikov
force-pushed
the
feature-contrib-workflow
branch
from
f961b10 to
de8c657
Compare
2 participants
This patch adds a description to outline the process to submit a bug or a feature request. It also makes minor changes in the document flow to accommodate the new sections that were added.