Automate some work for the release-docs/enhancement team

[somtochiama]

What would you like to be added:

This issue is mostly to open discussions about the best way to go about automating part of the work done by the docs/enhancement teams.

krease is a small CLI that filters issues based on issues and milestones, then comment on them with a template as an example of something that could be automated. We could integrate something like this into prow or find an alternative and also broaden the scope of what can be automated.

Please, let me know what you think😊.

[saschagrunert]

We probably can integrate this into krel. Do you have any thoughts on that @justaugustus?

[somtochiama]

@saschagrunert that sounds great! Should I join the release team meetings on of these days so that everyone can discuss on how to move further?

[saschagrunert]

@saschagrunert that sounds great! Should I join the release team meetings on of these days so that everyone can discuss on how to move further?

Yeah that sounds good, feel free to put the item on the agenda for the next release engineering meeting: https://docs.google.com/document/d/16GqCjnEh86w8yADcrUylNoE1y1sqjIMYNC_gdk5WPSQ/edit#

It would be good if you could outline a process to automate in the meanwhile. :)

[somtochiama]

Hey @saschagrunert , Just to double-check, what is the date for the next release engineering meeting?

[saschagrunert]

Hey @saschagrunert , Just to double-check, what is the date for the next release engineering meeting?

Hey, it's tomorrow January 19 at 3:30pm UTC.

[palnabarun]

Just dropping the reference to something related to krease an Enhancements Shadow, Harsha, from the 1.19 RT was working on:
https://github.com/harshanarayana/k8s-enhancements

If we end up having some automation on our interaction with GH during the course of the release cycle, we should also have a look at the above.

[somtochiama]

@palnabarun Yes it looks great! We could definitely combine efforts to work on automating parts of the release cycle.

[saschagrunert]

Docs process automation

It looks like that we can model a state machine around the usual deadlines from a release cycle perspective. In the first iterations we probably have to still manually sync the tracking sheet with the outputs of the tool. Later on we could think about an overall representation in markdown within k/sig-release.

Let's split up the steps

1. After enhancements freeze

   • Linking the information if enhancements needs docs via a label at the tracking issue. (seems a manual step to me)
   • Sync the correct state can be automated:
     • /hold k/website docs PR until k/k feature PR got merged
     • Verify and apply correct milestone at docs PR
     • Verify the base branch of the docs PR and notify if it's not dev-1.xx

   Looks like that we need a representation (maybe via JSON?) to link the PRs from the different repositories k/k k/enhancements and k/website. How is this being done now? Via the tracking sheet?

2. Before placeholder deadline

   • Add a reminder of the upcoming deadline to the enhancement issue if no or k/website PR exists

   Those reminders can be done easily via go templates and GITHUB_TOKENs.

3. After code freeze

   • If the k/k PRs are not merged, close those in k/website and remove from the current milestone
     Note: Is this the workflow or did I miss anything?

4. Before docs ready for review deadline

   • Add a reminder that the deadline is incoming to the k/enhancements issue
     Note: or the k/website one?

5. Before Docs Final deadline

   • Remove labels from the tracking issue when they are merged into the k/website repository
   • Add a reminder of the upcoming deadline

So, to me it looks like that the tool will be an auto-reminder tracking state machine between different repositories and PRs. If the overall process does not change that often, then putting the workflow into source code seems like a valuable addition to me.

---

@somtochiama can you please double-check if I did any understanding mistakes above? If not, then we can move forward and carve-out the more detailed technical aspects. ☺️

[somtochiama]

Linking the information if enhancements needs docs via a label at the tracking issue. (seems a manual step to me)

Yes. Ideally, the owner of the issue should place the label. The comment should say so.

Looks like that we need a representation (maybe via JSON?) to link the PRs from the different repositories k/k k/enhancements and k/website. How is this being done now? Via the tracking sheet?

Yes, Currently through a tracking sheet. We could also create a simple frontend? But the tracking sheet should still work with the tool (if we could use the Sheets API)

Note: Is this the workflow or did I miss anything?

Yes it is.

---

@saschagrunert This looks good! I think we can move forward.
Pinging @annajung in case she has any additions/improvements.

[saschagrunert]

Yes, Currently through a tracking sheet. We could also create a simple frontend? But the tracking sheet should still work with the tool (if we could use the Sheets API)

Yes I think so. I thought about having a rendered markdown document within the sig-release repository some sort of read-only frontend.

If it should be more about a website, then we could think of deploying something via GitHub pages.

The most feature-rich solution would be an angular (or else) website like we have it for the release notes. But this is probably a solution with the highest efforts behind. 🙃

[somtochiama]

The most feature-rich solution would be an angular (or else) website like we have it for the release notes. But this is probably a solution with the highest efforts behind. 🙃

This would probably be the best as the tracking sheets are sort of interactive but we could probably start with a read-only option. Adding the angular frontend could also be a nice project for Google Summer of Code / other mentorship programs where the efforts are defined and concentrated!

[justaugustus]

/assign @somtochiama

[somtochiama]

Sorry for the prolonged silence, I will get started on this.
We are still integrating with krel @saschagrunert right?

[saschagrunert]

Sorry for the prolonged silence, I will get started on this.
We are still integrating with krel @saschagrunert right?

Yes I think this is still the best move forward. 😊

[annajung]

@somtochiama, there is work being done by the enhancement subproject group where they are going to introduce a receipt process for the enhancements, which in short, will track the enhancements and all associated PRs in git. You can read more about it in the proposed kep.

I just wanted to bring that up because I think you can leverage or remove some of the tasks listed above since it may be solved by the receipt process.

For example,

Linking the information if enhancements needs docs via a label at the tracking issue. (seems a manual step to me)

I think we might want to add this as part of the receipt process instead of a separate process and that could help reduce the need of the docs release team pinging all enhancements owners if they need docs or not.

Another example, applying hold label

/hold k/website docs PR until k/k feature PR got merged

I think you can now get the list of PRs from the receipt which will contain the k/k and k/website PR information, this would definitely make it easier to get the correct list of PRs that would be used to label and unlabel hold for k/webiste. (This would only work if the proposed receipt process is being used and used as expected)

Can you take a look at the receipt process being proceeding any further? I think it may help reduce any duplicate work and solve some concerns that were raised before :)

[somtochiama]

Hey @annajung, Thanks for linking the KEP. I took a look and mostly what is going to change is how to get the list of issues / PR (KEP, k/k, k/w) which is great. But we probably don't want to put this work on hold waiting for the KEP to be accepted and implemented.

I think we can proceed with integration with krel bearing in mind that this change is coming and make it easier to switch from getting the data from the tracking sheet to some other mechanism. What do you think?

[annajung]

@somtochiama That works! I didn't want to put this work on hold, just wanted to make sure that you were aware of changes being made to how enhancements and all enhancements related PRs will be tracked in the future which will affect the work related to this issue.

Even though KEP has not merged yet, the plan is to start moving to the new receipt process starting 1.22, maybe not fully but at least partially.

I agree that this shouldn't be blocked by that though and can continue with the expectation that the source of data will change in the future. Thanks!

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[savitharaghunathan]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[palnabarun]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.