Feature submission template updated #204
Conversation
k8s-ci-robot
added
the
cncf-cla: yes
idvoretskyi
changed the title
|
cc @kubernetes/kubernetes-pm @kubernetes/features-maintainers |
ISSUE_TEMPLATE.md
Outdated
| - Reviewer(s) (at least one from code-area OWNERS file): | ||
| - Approver (for LGTM, likely from SIG to which feature belongs): | ||
| - Which stage does the feature target (alpha/beta/stable): | ||
| - Which release does the feature target (x.y): |
There was a problem hiding this comment.
Seems like we should do it like this to ensure clarity.
- Alpha release target (x.y)
- Beta release target (x.y)
- Stable release target (x.y)
There was a problem hiding this comment.
@philips the idea is avoiding the necessity to update the heading message in a thread - if a feature owner has decided to promote the feature to a more stable stage (alpha -> beta; beta -> stable), he has to update the labels and milestones.
Or, as an alternative - we may simplify the template more and delete the "stage" and "release" lines. In this case, feature owner has to define the stage and release with the labels and milestones only.
There was a problem hiding this comment.
Probably good to doc that expectation.
|
cc @kubernetes/sig-contributor-experience-misc |
ISSUE_TEMPLATE.md
Outdated
| - Responsible SIG: | ||
| - Design proposal link (community repo): | ||
| - Reviewer(s) (at least one from code-area OWNERS file): | ||
| - Approver (for LGTM, likely from SIG to which feature belongs): |
There was a problem hiding this comment.
Reviewers are for LGTM, no? I'd expect this to be someone who can /approve or, better, the area TL.
There was a problem hiding this comment.
Correct; to be fixed.
ISSUE_TEMPLATE.md
Outdated
| - When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label. | ||
|
|
||
| # Feature Description | ||
| - One-line feature description (will be used as a release note): |
There was a problem hiding this comment.
Some features require longer release notes.
I don't want to gate this PR on it, but we need to change our release-note processes, agree on a user-friendly release-note structure, make it clearer what release notes should contain (e.g., actionable information, links to docs about new features, names of fields or flags added/removed/changed, remediating actions), examples of good release notes, removal of the release-note template in the kubernetes repo, bot support to prompt for appropriate release notes and/or removal of the release-note gate in the kubernetes repo.
We also need to distinguish features targeted for specific releases and multi-release roadmap placeholders for larger areas of work, which we do need to track somehow.
Examples of the former might be:
- PDB beta and GA: Requirements for PodDisruptionBudget, /eviction subresource, and PreferAvoidPods to graduate to Beta and then v1 kubernetes#25321
- Taints/tolerations GA: Requirements for taints, tolerations, dedicated nodes to graduate to Beta and then v1 kubernetes#25320
Examples of the latter are:
- Workloads APIs GA: Workload API v1 requirements umbrella issue kubernetes#42752
- Moving kubectl logic to the system: Move kubectl client logic into server kubernetes#12143
There was a problem hiding this comment.
@bgrant0607 agree, noted.
PS. As discussed at 3/14 PM group meeting, the new features procedure has to be developed; and I'm working on it right now.
|
@idvoretskyi What's blocking us from merging this now? |
|
@bgrant0607 I'd like to adjust this a bit today; let's discuss the final version tomorrow (4/11) on SIG-PM meeting. |
|
The template looks fine to me @idvoretskyi and I think that the simplified template is a good incremental improvement. I would really like to see the issue of how to make changes to the project tackled as a general governance issue. Personally I believe an RFC (Rust) or PEP (Python) process may be more helpful in the medium term to collect all "major" changes to the project. I also feel like it would be nice to move away from GitHub Issues as a way of tracking "features" in favor of maintaining files under source control which would a) reduce our reliance on GitHub and b) allow for contributors to look at historical changes to the project more easily and c) associate design documentation with the change proposal. Again, Rust or Python provide interesting prior art in this area. cc: @bgrant0607, @grodrigues3, @philips |
I agree that some work is needed in this area; I disagree that we should move away from GitHub (if GitHub is able to solve our questions). I would prefer to use as fewer instruments as possible (without quality and efficiency reducing). I suppose we should start moving to GitHub projects consuming for this area - as we have already discussed at one of the previous SIG-PM meetings. |
|
+1 to tracking features in source control instead of issues. Github issues pretty much guarantee incoherency for any non-trivial conversation. @idvoretskyi I'm not sure what your concerns are here. Feature proposals would still evolve through github, just in successive PRs instead of a single issue. To me the clear advantage would be that each PR merge would result in a new and coherent version of the proposal. |
|
The features repo wasn't originally intended to be a replacement for the proposal process (which also needs to be formalized/improved). It was supposed to be a tracking system. |
|
@marun I second @bgrant0607. The feature proposal lands to https://github.com/kubernetes/community/tree/master/contributors/design-proposals - under the source control. We need to have the easiest way to track and visualize the features, that's why we have created the dedicated features repo and been using it for almost four release iterations. @calebamiles and I have started looking at the possible areas to enhance the area regarding visualization (GitHub projects that I've mentioned above), but it's not about the source control - it's a different story. |
ISSUE_TEMPLATE.md
Outdated
| # Feature Description | ||
| - One-line feature description (can be used as a release note); | ||
| - Primary contact (assignee); | ||
| - Responsible SIG; |
There was a problem hiding this comment.
SIG(s)
since there might be more than one area of the codebase touched by a review
ISSUE_TEMPLATE.md
Outdated
| - One-line feature description (can be used as a release note); | ||
| - Primary contact (assignee); | ||
| - Responsible SIG; | ||
| - Design proposal link (community repo); |
There was a problem hiding this comment.
Just thinking aloud: why have design proposals in kubernetes/community rather than in kubernetes/features? My understanding was that all new feature work should be consolidated in 1 place and the community repo is for detailing SIGs and documenting contributor workflows.
ISSUE_TEMPLATE.md
Outdated
| - Design proposal link (community repo); | ||
| - Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred; | ||
| - Approver (likely from SIG/area to which feature belongs); | ||
| - Initial target stage (alpha/beta/stable) and release (x.y); |
There was a problem hiding this comment.
Will all new features be expected to go through the alpha/beta/stable release cycle? For example, adding a new flag to kubectl is a relatively minor addition that probably doesn't need additional, long-term testing.
If that's the case, should such a feature be submitted through this workflow? I don't see an explanation as to when a contributor should submit a feature request here or through a normal feature PR. The only reference is in the README which says it's provisional.
|
Since we are rapidly approaching features repo freeze, I'd really like to get this merged (today if possible). I realize there are still outstanding policy discussions (why features repo vs community, version controlled vs issues, and what exactly constitutes a feature). Can we save those for the next sig-pm meeting and get this merged for now. |
|
@grodrigues3 sounds good to me. @bgrant0607 any objections? |
grodrigues3
force-pushed
the
idvoretskyi-feature-template-v2
branch
from
55137d5 to
700742f
Compare
|
Squashed and merging. |
Update file-integrity-operator enhancement
Following the discussion, happened at the SIG PM regular meeting 2017-03-14, agreed in the document, feature submission template is much simplified and enhanced.