Plans for 1.14 API reviews and shadowing process

[Jordan Liggitt]

As discussed, we have a number of items in 1.14 that will need attention from API reviewers.

For API reviewers:

1. Comment and self-assign 1.14 api-change issues you have domain knowledge and bandwidth to review. We'll assign reviewers to untaken issues by the end of next week.
2. Try out a shadowing process if you get interest in your assigned issues

For people wanting to get involved in API review and participate in the shadowing process:

1. Comment in a 1.14 api-change issue indicating interest
2. Work through the shadowing prep items
3. Coordinate a time with the API reviewer
   

Notes, questions, and issues captured during the reviews will be folded back into improved guidelines and checklists for different types of API changes (tracking issue)

Jordan

[Jordan Liggitt]

The API review project board is hopefully useful once again:

• it now reflects all enhancements issues targeting 1.14 labeled as having API changes.
• open PRs for those issues were added to their description as tasks, which you can see from the project board
• you can filter that board to issues assigned to you with assignee:<handle>

I also started https://github.com/kubernetes/community/pull/3261 to describe how we're actually keeping track of items needing review, and think of some simple things the bot could do to make common workflows easier/more discoverable.

[Jordan Liggitt]

Summary:

I think it would actually be very beneficial to put the API Review project under the kubernetes org.

Any objections to relocating it there and updating the process doc to be based on labels on existing issues/PRs for most items?

Details:

I spent a while playing around with different options for the github project. Benefits to being in the same org:

1. Visibility improvements:

• The vast majority of the things needing review already have tracking issues in the kubernetes org (under kubernetes/enhancements and/or kubernetes/kubernetes repos), even more so with the "everything has a KEP" approach
• Same-org projects surface membership in an issue or PR's sidebar so it is immediately visible (and if we name our columns well, makes it clear the current status, e.g. "Assigned in API Review", "In progress in API Review")

2. Project management:

• You can use issue search within the project to locate issues in the org by milestone/label/status/type and drag them into the board, and things already on the board are hidden (makes adding issues matching a query super quick for project managers)
• You can use issue search within the repo for queries like this: kind/api-change enhancements in the 1.14 milestone that aren't in the project
• I set up https://github.com/orgs/kubernetes/projects/13/ as an experiment and replicated the other board's issue list (which took about 30 minutes of manual setup and comparison) in about a minute.
  

3. Permissions management:

• We can tie write permissions to the project to the same groups api-reviewers/api-approvers groups we already have

Some bot improvements could make this even lower friction and add more in the future:

• an "api-review-needed" label org members could add (which a project manager could search on, or the bot could use to auto-add labeled PRs/issues to the project backlog)
• auto-adding a blurb with a link to the process doc and/or the steps to initiate an API review (have a KEP, get agreement from subproject owner, read the API conventions, label with "api-review-needed")

[Brian Grant]

SGTM.

Do you just want to create a new org-level project board?

--
You received this message because you are subscribed to the Google Groups "kubernetes-api-reviewers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-api-rev...@googlegroups.com.
To post to this group, send email to kubernetes-a...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-api-reviewers/CAMBP-pKUU-KuVa3Nw%2Bv5k1KLGLFF0iOzeQxCfxBd3H%2BLyBYJNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Tim Hockin]

I don't object to this.  k-sigs should be a staging ground for things that may become "real" - this seems clear

On Fri, Feb 15, 2019 at 8:16 AM 'Jordan Liggitt' via kubernetes-api-reviewers <kubernetes-a...@googlegroups.com> wrote:

--

[Jordan Liggitt]

Yes, that's what I was testing with https://github.com/orgs/kubernetes/projects/13/ and it seemed to work really well.

Future bot improvements like https://github.com/kubernetes/test-infra/issues/9925 could make backlog population even more automatic.

[Jordan Liggitt]

Opened https://github.com/kubernetes/community/pull/3261 updating the described API review workflow to reference the in-org project and (hopefully) fit more naturally with our existing review process

[Brian Grant]

On Fri, Feb 15, 2019 at 8:25 AM Jordan Liggitt <lig...@google.com> wrote:

Yes, that's what I was testing with https://github.com/orgs/kubernetes/projects/13/ and it seemed to work really well.

+1. Looks great. When there were small numbers of things in flight and only manual assignees, simple github queries were good enough. We're way beyond that point now.

I assume/hope that most of the 104 PRs tagged kind/api-change either aren't active or aren't relevant? Do we need to triage them?

https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Akind%2Fapi-change

[Jordan Liggitt]

I assume/hope that most of the 104 PRs tagged kind/api-change either aren't active or aren't relevant? Do we need to triage them?

https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+label%3Akind%2Fapi-change 

Yes, that's on my list to burn through once the course for 1.14 stuff is set.

Excluding PRs marked hold, wip (stand-ins for "not reviewable") or needs-rebase (stand-ins for "not up to date"), the list is down to 44.

That label also gets applied somewhat gratuitously (any mention of a `kubernetes/sig-foo-api` team adds it, any file touched under API packages adds it), so I'd guess the count of actual proposed API changes is smaller than that.