Discuss project grooming

[justaugustus]

In recent discussions in Steering and SIG PM, I mention the possibility of having SIG PM assist with backlog grooming for project-wide groups e.g., Steering, PM, Architecture, ContribEx.

Overall, there's been positive reception so far, but I'd like to document the intent and open the floor for comments. This is something that would get added as something in-scope for the forthcoming SIG PM charter.

Some thoughts:

• Socialize the idea (happening now)
• Create a project-board-maintainers team - initially @jdumars and myself - https://github.com/kubernetes/org/pull/496
• Assign the project-board-maintainers team write permissions to the following projects:
  • Steering: https://github.com/kubernetes/steering/projects/1
  • PM
  • SIG PM: https://github.com/orgs/kubernetes/projects/14
  • KEP Implementation Tracking: https://github.com/orgs/kubernetes/projects/5
  • Architecture:
  • KEP Tracking: https://github.com/kubernetes-sigs/architecture-tracking/projects/2
  • API Reviews: https://github.com/orgs/kubernetes/projects/13 (ref: https://github.com/kubernetes/community/pull/3261#pullrequestreview-204503307)
• Expand project-board-maintainers team
• Onboard additional boards

Additionally, there is some chatter around project mgmt improvements in ContribEx. We should work to consolidate that discussion under SIG PM.

/sig pm architecture contributor-experience /committee steering

/assign @jdumars @justaugustus cc: @calebamiles @idvoretskyi @sarahnovotny @bgrant0607 @liggitt @cblecker

[justaugustus]

cc: @parispittman

[justaugustus]

Question for peribolos wizards (@cblecker, @fejta, @cjwagner, @spiffxp): Is it possible to manage project board permissions with peribolos? It would be cool if this project-board-maintainers group was automatically added to org-level boards in the future.

[nikhita]

Is it possible to manage project board permissions with peribolos?

No, this is not possible today.

[cblecker]

Yeah, as Nikhita said, no, this is not possible... but I think that's okay, mostly for the reason of this being "opt-in". Like, a sig should be able to say "yes, I would love sig-pm's help to maintain my board" or "no thank you, we would like to maintain our board ourselves".

The other tricky bit is for boards that are repo-scoped, rather than org-scoped. I wish all boards were just org-scoped, because we can then be explicit with granting perms.. The only way to grant perms to repo-scoped boards is to grant write access to the repo itself (which is not ideal).

[justaugustus]

Yeah, as Nikhita said, no, this is not possible... but I think that's okay, mostly for the reason of this being "opt-in". Like, a sig should be able to say "yes, I would love sig-pm's help to maintain my board" or "no thank you, we would like to maintain our board ourselves".

SGTM. While we're staffing, I'd only want to sign us up for managing a few boards (Steering, SIG PM, KEP Implementation Tracking, API Reviews, KEP Tracking). Those are in-scope for what @jdumars and myself have already been doing. From there, we would probably bring a few more people on and look at helping out SIG ContribEx next.

The other tricky bit is for boards that are repo-scoped, rather than org-scoped. I wish all boards were just org-scoped, because we can then be explicit with granting perms.. The only way to grant perms to repo-scoped boards is to grant write access to the repo itself (which is not ideal).

I'd prefer the boards we manage be org-scoped as well. In addition to being explicit about permissions, org-level boards are more discoverable than the repo-scoped ones. We can look at moving them once we lock this in. API Reviews has already made that move (https://github.com/kubernetes-sigs/architecture-tracking/projects/3 --> https://github.com/orgs/kubernetes/projects/13), as an example.

[idvoretskyi]

@justaugustus

Please, update the OP after the naming changes discussed here - https://github.com/kubernetes/org/pull/496#issuecomment-464932769.

[idvoretskyi]

I'd prefer the boards we manage be org-scoped as well. In addition to being explicit about permissions, org-level boards are more discoverable than the repo-scoped ones. We can look at moving them once we lock this in.

I disagree that org-scope should be mandatory (let's agree that it's a default and preferred behaviour, but not mandatory). There may be cases, when repo-wide boards are a preferred way to go.

[justaugustus]

Not implying that we should mandate org-level boards; they're just easier from the mgmt perspective for horizontal groups. Repo-scoped boards definitely work well for work that is tightly scoped to code.

[bgrant0607]

It looks like it's now possible to access control org-level project boards? The lack of team-based ACLs is what previously drove us to create repos to contain projects, like architecture-tracking. https://help.github.com/articles/project-board-permissions-for-an-organization/

[liggitt]

It looks like it's now possible to access control org-level project boards? The lack of team-based ACLs is what previously drove us to create repos to contain projects, like architecture-tracking.

Yes. Examples for the API review project:

Org members can be scoped to read access:

And specific teams in the org given other levels of access:

[justaugustus]

Yep. I've noticed the defaults for the project boards are:

• visibility: private
• permission: write

I'm thinking these should be:

• visibility: public
• permission: ~read~ write

Opened a separate issue for that: https://github.com/kubernetes/community/issues/3280

[bgrant0607]

Oh, right. Org-level boards also used to only be visible to org members

[mattfarina]

Regarding the KEP board, because we merge early and often the PRs for those are not a useful thing to track on a board. We need to come up with a plan (short and long term) to get these wrangled.

A possible short term plan would be to have an issue for every KEP. Each of the PRs could be associated with the issue. A label could be used to track state (e.g., provisional, etc).

It would be nice of all of this were automated in a custom system. That's a long term goal.

@justaugustus I'm happy to put in time to get this wrangled. If we go with a board/short term solution I'm happy to do the work to get this up and going. The long term solutions is something I'll try to get more info on in the coming week. I'm not completely up to speed on where it is.

[spiffxp]

A possible short term plan would be to have an issue for every KEP

Sounds like the tracking issues that the release team uses. I agree there is much that could be done to improve them, but I would start there.

[mattfarina]

@spiffxp That is a good place to start. We also need to consider the features that are not in a k8s/k8s release but are a KEP. Thanks for the reminder.

[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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[justaugustus]

/remove-lifecycle stale

[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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[markjacksonfishing]

remove-lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

[markjacksonfishing]

/remove-lifecycle rotten

[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-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

[justaugustus]

/remove-lifecycle stale

[spiffxp]

/remove-committee steering For steering, this is the bosun's responsibility

/close All that's happened here over the last year is /remove-lifecycle

If we want to discuss improving the state of project board management, I would suggest opening up more granular well-scoped issues.

[k8s-ci-robot]

@spiffxp: Closing this issue.

In response to [this](https://github.com/kubernetes/community/issues/3267#issuecomment-608154009): >/remove-committee steering >For steering, this is the bosun's responsibility > >/close >All that's happened here over the last year is `/remove-lifecycle` > >If we want to discuss improving the state of project board management, I would suggest opening up more granular well-scoped issues. Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.