Open lavalamp opened 6 years ago
Not sure who to tag-- maybe @spiffxp ? @cblecker?
/sig contributor-experience
yeah, there are some updates that are going to have to be made to the generator to accommodate the new structures in https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md
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
/remove-lifecycle stale
/area github-management
Yeah I agree until there's a single source of truth this is going to be perpetually stale. It started in sigs.yaml because it's easier to try and change everything in one place while getting started.
@lavalamp @spiffxp -- I have a PR up that allows you to specify subproject by repo, instead of specifically with an OWNERS file.
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
/remove-lifecycle stale
/kind bug /priority important-soon
/assign ref: https://github.com/kubernetes/community/issues/1808 for owners management
/remove-priority important-soon /priority important-longterm
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
/remove-lifecycle stale /lifecycle frozen
Due to important long term label.
/committee steering This is similar to https://github.com/kubernetes/community/issues/4125 - should this be rolled into the annual sig/wg checks?
/assign (from 12/6 Steering public meeting)
see new tool for ensuring urls are still valid ( https://github.com/kubernetes/community/issues/4125#issuecomment-1000412060 )
with the annual report checks and the new tool above that dims linked, @lavalamp do you think we are in a better place now and ok to close this?
/assign @palnabarun
Anytime anyone moves a directory, the entry in sigs.yaml will suddenly be wrong.
Wouldn't it make more sense for OWNERS files to instead declare the owning sig and subproject, and then we generate sigs.yaml from that?