Skip to content
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

🌱 improve how do we perform issue triage and milestone management #6828

Conversation

fabriziopandini
Copy link
Member

What this PR does / why we need it:
Proposing a change to how we perform issue triage and milestone management:

  • Stop assigning issues to the current milestone as a signal for "triaged", and start using the triage labels instead
  • Start adding issues to milestones only when there is someone who expressed intent to work on it before the deadline
  • Drop Milestone Next

/hold
for community discussion

/cc @CecileRobertMichon @enxebre @vincepri @sbueringer

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 5, 2022
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Jul 5, 2022
Copy link
Contributor

@killianmuldoon killianmuldoon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

This should be a big improvement for signalling what's coming in a new release - big +1

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 6, 2022
- Code freeze is in effect 72 hours (3 days) before a release.
- Cluster API uses [GitHub milestones](https://github.com/kubernetes-sigs/cluster-api/milestones) to track work
for minor releases.
- Adding an issue to a milestone provides forward visibility on what the next release will be, so, as soon as there
Copy link
Contributor

@CecileRobertMichon CecileRobertMichon Jul 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, are we aiming to only release when everything in the milestone is done, or are we going to continue to drive toward a release cadence as discussed previously? My only concern here would be committing to a changeset (by saying what the release "will be", as opposed to maybe what the release "might contain") since the work actually getting done by the release deadline will be out of the maintainers' control.

Copy link
Member

@sbueringer sbueringer Jul 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion we shouldn't wait, except something has been explicitly defined as release-blocking (but this should be only done when really necessary)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. In that case, it might be worth making this explicit so it's clear to contributors and users that an issue being in the milestone doesn't guarantee inclusion in the release.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to not wait

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated:

  • Adding an issue to the release only imply the issue will be tracked
  • We should add to milestone/track only major features/bug fixes specifically targeting a release; everything else will simply merge when ready without additional toil
  • There is an item calling out that an issue being in the milestone doesn't guarantee inclusion in the release

CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
CONTRIBUTING.md Outdated Show resolved Hide resolved
@sbueringer
Copy link
Member

Thx for tackling this. I think it's a good step to reduce toil for maintainers

Copy link
Member

@vincepri vincepri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vincepri

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jul 27, 2022
Copy link
Contributor

@CecileRobertMichon CecileRobertMichon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@fabriziopandini
Copy link
Member Author

As per 27th July office hours discussion lazy consensus set for EOW (29th of July)

@k8s-ci-robot k8s-ci-robot removed the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 28, 2022
@fabriziopandini fabriziopandini force-pushed the improve-issue-triage-and-milestone-management branch from 37c0279 to 8984cd2 Compare July 29, 2022 12:03
@fabriziopandini
Copy link
Member Author

Commit squashed
/hold cancel
As per community meeting discussion

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 29, 2022
Copy link
Member

@vincepri vincepri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 29, 2022
@k8s-ci-robot k8s-ci-robot merged commit a6405b0 into kubernetes-sigs:main Jul 29, 2022
@k8s-ci-robot k8s-ci-robot added this to the v1.3 milestone Jul 29, 2022
@sbueringer
Copy link
Member

Thx for tackling this! Big improvement in my opinion

/lgtm

@fabriziopandini fabriziopandini deleted the improve-issue-triage-and-milestone-management branch September 1, 2022 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants