Separating proposals and architecture related items from community

[timothysc]

IMO proposals and architecture related items probably belong in their own repo now, this repo is starting to become overloaded.

/cc @jbeda @kubernetes/sig-architecture-bugs

[thockin]

+1 - I subscribed to this repo to keep track of KEPs but am overwhelmed by everything else

…

On Mon, Aug 20, 2018 at 6:31 PM Timothy St. Clair ***@***.***> wrote: IMO proposals and architecture related items probably belong in their own repo now, this repo is starting to become overloaded. /cc @jbeda <https://github.com/jbeda> @kubernetes/sig-architecture-bugs <https://github.com/orgs/kubernetes/teams/sig-architecture-bugs> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2565>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVKiuYn3hlIm3V563RzcN-Aa1eW8Eks5uS2L1gaJpZM4WE9Ry> .

[parispittman]

+1

[bgrant0607]

I'd want design-proposals and some docs that are currently in devel to move, as well.

Any move needs to preserve git history and leave behind forwarding links for a fair bit of time.

There's no way to move PR comments AFAIK.

[mdlinville]

You can copy and close an issue with Zenhub, which installs itself as a browser plugin and overlays some additional functionality into the Github UI. This is used in Docker and Moby repos, for instance, to move mis-filed issues to the correct repo. Of course, a PR is quite different as it actually represents a comparison between two Git objects. You probably just have to open a new PR in the new repo (which presumably has different history and file structure / locations), and link back to the original PR. It's difficult to understand how you'd automate or script this, even using Github APIs.

[justaugustus]

+1 -- I think this might be a good fit for https://github.com/kubernetes-sigs/architecture-tracking, as tracking for KEPs, API reviews, and conformance testing is already happening there.

/assign @jdumars

---

@MistyHacks -- w.r.t. Zenhub, I've used it in the past and dig it, but it requires write access across the kubernetes org, which we're not excited about.

rel:

• https://github.com/ZenHubIO/support/issues/910
• https://kubernetes.slack.com/archives/C1TU9EB9S/p1530651276000365

[justaugustus]

Alternatively, we could move the KEPs to k/features and maybe rename to k/keps.
A lot of the tracking work for enhancement delivery already lives in that repo.

[nikhita]

Federation was moved out from k/k to k/federation with all issue comments still intact. Example: kubernetes/kubernetes#38893 and kubernetes-retired/federation#88.

I'm not sure if some custom tool was used for this or if this was done manually (I hope not because that would be such a huge task!). @irfanurrehman can you elaborate on what you used to make sure all comments migrate so cleanly? :)

[irfanurrehman]

@nikhita I used a hacky, custom version of https://github.com/IQAndreas/github-issues-import.
The not so nicely done hacky commits are available for reference at https://github.com/irfanurrehman/github-issues-import.

It worked as:

1. List commits with needed labels from src repo using ./list-sig-multicluster-only-issues.py --all.
2. Migrate issues using the actual script, for example: ./gh-issues-import.py --issues 25 26 29.

I remember facing some issues, and fixing some, and then further using some hard coded stuff specific to my job.
I recommend trying it out, one issue at a time first to see everything works fine before submitting the batch, given that its not really a maintained code.

[jdumars]

Big +1 on this. It's definitely time.

[justaugustus]

Adding myself to this as well.
/sig pm
/assign

[justaugustus]

@bgrant0607 -- in an attempt to level up my git-fu, I took a whack at moving keps/ and design-proposals/, while maintaining the history. PR is here: kubernetes/enhancements#613

If we're happy with moving them to k/features and renaming the repo to k/keps, then there are some additional things that would need to happen as well (not necessarily in perfect order)...

• announce the forthcoming change
• merge the k/features PR
• set up blockade to prevent pushes to either dir in k/community
• rename k/features to k/keps
• migrate KEP / design proposal PRs to k/keps
• create tombstones for files in both dirs in k/community
• fix KEP / proposal links in k/keps issues
• update docs in k/keps to clarify process
• figure out the best way to reconcile the multiple OWNERS files between the two repos

Additionally, you wanted to move some of the files in contributors/devel out. Any ones specifically? A lot of them seem like they'd be good additions to a developer's guide, while others might fit in a dir like k/community/architecture.

Let me know what you think! :)

[bgrant0607]

From a quick scan of devel, I'd move:

https://github.com/kubernetes/community/blob/master/contributors/devel/api-conventions.md
https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md (or at least parts of it)
https://github.com/kubernetes/community/blob/master/contributors/devel/arch-roadmap-1.png (which needs to be updated, but is what we have)
https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md (ditto)
https://github.com/kubernetes/community/blob/master/contributors/devel/component-config-conventions.md
https://github.com/kubernetes/community/blob/master/contributors/devel/conformance-tests.md (or at least test requirements)
https://github.com/kubernetes/community/blob/master/contributors/devel/strategic-merge-patch.md

cc @spiffxp

[timothysc]

Can we enqueue this for the @kubernetes/sig-architecture-feature-requests call this week to discuss?

[spiffxp]

Most of the docs @bgrant0607 lists above I wouldn't envision moving out of this repo. Aspirational docs, design proposals and roadmaps, yes, move to a keps/features repo.

Stated conventions developers should follow and reasons why, no, those should stay here IMO. Like @justaugustus said, those make more sense to me in a developers guide, which I would prefer to keep in close proximity to the contributor's guide.

@justaugustus you'll want to merge tombstones before you turn on blockade

We've been getting less traffic against design-proposals than we have historically, so it may be worth considering whether it's time to deprecate them, and move fully to KEPs. This seems like a good trigger for that conversation.

[justaugustus]

We've been getting less traffic against design-proposals than we have historically, so it may be worth considering whether it's time to deprecate them, and move fully to KEPs. This seems like a good trigger for that conversation.

@spiffxp -- this is exactly the effect I was hoping for.
(thanks for the tip on the tombstones!)

---

@timothysc -- I've put up an agenda item for the 9/6 SIG Arch meeting.

While I won't be able to attend most of the SIG Arch meetings for September, I intend to drive this with @jdumars, as it would fall under the scope of maturing the enhancement delivery process (an initiative the two of us are undertaking), which cross-cuts Arch, PgM, and PdM.

[mrbobbytables]

@justaugustus -- This issue came up up at this weeks contribex meeting with regard to the contributor site (site | project). KEPs are currently displayed there along with other content from the k/community repo after being converted to a hugo friendly format. When the KEPs do relocate, the site-generation script will need to be updated to pull the additional repo and do some minor conversion. This should not be difficult, but should be coordinated with the migration.

[bgrant0607]

@spiffxp On my proposed docs to move:

I agree that some contributor-focused docs on these topics need to land in the contributor doc site.

One problem right now is that most of our docs don't have a sense of who the audience is, so they mix many topics -- part design doc, part policy, part contributor instructions, part user documentation, etc. The API conventions is one example. We need user-facing docs on kubernetes.io to explain to operators and to client developers (2 audiences/personas) what common behaviors and patterns they can expect and rely on. We need a design doc (or multiple docs) to explain why things are the way they are. We need policy: MUST, SHOULD, MAY, NOT, etc. And we need a how-to guide. And a check list. And a linter. And probably other things.

If we leave these where they are for now, we should at least ensure that docs containing policy have proper OWNERS.

[justaugustus]

@bgrant0607 @jdumars -- I've created a KEP to capture the feedback provided here and across the last few SIG Architecture meetings about KEP process improvement: #2655
Open for comments!

To the devel docs discussion, I think we should drive that down as a separate effort, with Brian's suggestion of ensuring OWNERS are in place for all subdirectories being a good first step.

[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

[mrbobbytables]

/remove-lifecycle stale

I think the remaining item on this is for arch to do a review to see what items should be moved over to devel (e.g. resource-management) before we can migrate the rest to live with enhancements.

/assign @dims @johnbelamaric @derekwaynecarr

[dims]

@navidshaikh do you want to take this on and help with?

[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

[nikhita]

/remove-lifecycle stale

…

On Thu, 27 May 2021 at 08:37, fejta-bot ***@***.***> wrote: 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 <https://github.com/kubernetes/community>. /lifecycle stale — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD24BUCNPZRPIG5GSTEM2ATTPWZOBANCNFSM4FQT2RZA> .

[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

[nikhita]

/remove-lifecycle stale

…

On Wed, 25 Aug 2021 at 09:32, Kubernetes Triage Robot < ***@***.***> wrote: 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 <https://www.kubernetes.dev/docs/guide/issue-triage/> Please send feedback to sig-contributor-experience at kubernetes/community <https://github.com/kubernetes/community>. /lifecycle stale — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD24BUA7MCP62QWORSEG75TT6RTMXANCNFSM4FQT2RZA> .

[mrbobbytables]

As an FYI - we keep getting people opening up issues/PRs to update the design-proposals. It'd be nice to move this along and then we can finally put them some place to be permanently archived.

[MadhavJivrajani]

@mrbobbytables fyi - #6055
created a tracking issue for this after discussing it with sig-arch in yesterday's meeting

[MadhavJivrajani]

The relevant k/community PRs are merged:
#6259
#6258

And the repo has been updated and archived: https://github.com/kubernetes/design-proposals-archive

Closing!
/close

[k8s-ci-robot]

@MadhavJivrajani: Closing this issue.

In response to this:

The relevant k/community PRs are merged:
#6259
#6258

And the repo has been updated and archived: https://github.com/kubernetes/design-proposals-archive

Closing!
/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.