{"id":13572881,"url":"https://github.com/openshift/enhancements","last_synced_at":"2025-04-04T22:06:56.435Z","repository":{"id":37396676,"uuid":"203647456","full_name":"openshift/enhancements","owner":"openshift","description":"Enhancements tracking repository for OKD","archived":false,"fork":false,"pushed_at":"2024-05-22T21:42:27.000Z","size":25978,"stargazers_count":175,"open_issues_count":37,"forks_count":448,"subscribers_count":61,"default_branch":"master","last_synced_at":"2024-05-22T22:41:26.768Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/openshift.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":"ROADMAP.md","authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-08-21T19:02:57.000Z","updated_at":"2024-05-29T23:24:26.267Z","dependencies_parsed_at":"2023-10-14T18:02:40.624Z","dependency_job_id":"477df8b1-b1ad-48c7-bc28-4535f765fa5a","html_url":"https://github.com/openshift/enhancements","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fenhancements","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fenhancements/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fenhancements/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/openshift%2Fenhancements/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/openshift","download_url":"https://codeload.github.com/openshift/enhancements/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247256112,"owners_count":20909240,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T15:00:23.062Z","updated_at":"2025-04-04T22:06:56.416Z","avatar_url":"https://github.com/openshift.png","language":"Go","readme":"# Enhancements Tracking and Backlog\n\nEnhancement tracking repository for OpenShift, including OKD and OCP.\n\nInspired by the [Kubernetes enhancement](https://github.com/kubernetes/enhancements) process.\n\nThis repository provides a rally point to discuss, debate, and reach consensus\nfor how OpenShift [enhancements](./enhancements) are introduced.  OpenShift combines\nKubernetes container orchestration services with a broad set of ecosystem\ncomponents in order to provide an enterprise ready Kubernetes distribution built\nfor extension.  OpenShift assembles innovation across a wide array of repositories and\nupstream communities.  Given the breadth of the distribution, it is useful to\nhave a centralized place to describe OpenShift enhancements via an actionable design\nproposal.\n\nEnhancements may take multiple releases to ultimately complete and thus provide\nthe basis of a community roadmap.  Enhancements may be filed from anyone in the\ncommunity, but require consensus from domain specific project maintainers in\norder to implement and accept into the release.\n\nFor an overview of the whole project, see [the roadmap](ROADMAP.md).\n\nFor a quick-start, FAQ, and template references, see [the guidelines](guidelines/README.md).\n\n## Why are Enhancements Tracked?\n\nAs the project evolves, its important that the OpenShift community understands how we\nbuild, test, and document our work.  Individually it is hard to understand how\nall parts of the system interact, but as a community we can lean on each other\nto build the right design and approach before getting too deep into an\nimplementation.\n\n## Is My Thing an Enhancement?\n\nA rough heuristic for an enhancement is anything that:\n\n- impacts how a cluster is operated including addition or removal of significant\n  capabilities\n- impacts upgrade/downgrade\n- needs significant effort to complete\n- requires consensus/code across multiple domains/repositories\n- proposes adding a new user-facing component\n- has phases of maturity (Dev Preview, Tech Preview, GA)\n- demands formal documentation to utilize\n\nIt is unlikely to require an enhancement if it:\n\n- fixes a bug\n- adds more testing\n- internally refactors a code or component only visible to that components\n  domain\n- minimal impact to distribution as a whole\n\nIf you are not sure if the proposed work requires an enhancement, file an issue\nand ask!\n\n## When to Create a New Enhancement\n\nEnhancements should be related to work to be implemented in the near\nfuture. If you have an idea, but aren't planning to implement it right\naway, the conversation should start somewhere else like the mailing\nlist or Slack.\n\nCreate an enhancement here once you:\n\n- have circulated your idea to see if there is interest\n- (optionally) have done a prototype in your own fork\n- have identified people who agree to work on and maintain the enhancement\n  - many enhancements will take several releases to complete\n\nAlthough you should probably not start your new idea's journey by writing an \nenhancement up front, it's worth perusing [the enhancement template](guidelines/enhancement_template.md) to understand the \nkinds of details that will ultimately be required, so you can keep them in mind as \nyou explore your new idea.\n\n## How are Enhancements Reviewed and Approved?\n\nThe author of an enhancement is responsible for managing it through\nthe review and approval process, including soliciting feedback on the pull request\nand in meetings, if necessary.\n\nEach enhancement should have at least one \"approver\" and several\nreviewers designated in the header of the document.\n\nThe approver assists authors who may not be familiar with the process,\nthe project, or the maintainers. They may provide advice about who\nshould review a specific proposal and point out deadlines or other\ntime-based criteria for completing work. The approver is responsible\nfor recognizing when consensus among reviewers has been reached so that a proposal is\nready to be approved, or formally rejected. In cases where consensus\nis not emerging on its own, the approver may also step in as a\nmediator. The approver does not need to be a subject-matter expert for\nthe subject of the design, although it can help if they are.\n\nChoosing the appropriate approver depends on the scope of an\nenhancement. If it is limited in scope to a given team or component,\nthen a peer or lead on that team or pillar is appropriate.  If an\nenhancement captures something more broad in scope, then a member of\nthe OpenShift staff engineers team or someone they delegate would be\nappropriate.  Examples of broad scope are proposals that change the\ndefinition of OpenShift in some way, add a new required dependency, or\nchange the way customers are supported.  Use your best judgement to\ndetermine the level of approval needed.  If you’re not sure, ask a\nstaff engineer to help find a good approver by posting in\n`#forum-arch` on the RedHat Slack server and tagging\n`@aos-staff-engineers`.  If you are external to RedHat, you can use the\n`#openshift-users` forum on the kubernetes.slack.com instance.\n\nThe set of reviewers for an enhancement proposal can be anyone that\nhas an interest in this work or the expertise to provide a useful\ninput/assessment.  At a minimum, the reviewers must include a\nrepresentative of any team that will need to do work for this EP, or\nwhose team will own/support the resulting implementation. Be mindful\nof the workload of reviewers, however, and the challenge of finding\nconsensus as the group of reviewers grows larger. Clearly indicating\nwhat aspect of the EP you expect each reviewer to be concerned with\nwill allow them to focus their reviews.\n\n## How Can an Author Help Speed Up the Review Process?\n\nEnhancements should have agreement from all stakeholders prior to\nbeing approved and merged. Reviews are not time-boxed (see Life-cycle\nbelow). We manage the rate of churn in OpenShift by asking component\nmaintainers to act as reviewers in addition to everything else that\nthey do.  If it is not possible to attract the attention of enough of\nthe right maintainers to act as reviewers, that is a signal that the\nproject's rate of change is maxed out. With that said, there are a few\nthings that authors can do to help keep the conversation moving along.\n\n1. Respond to comments quickly, so that a reviewer can tell you are\n   engaged.\n2. Push update patches, rather than force-pushing a replacement, to\n   make it easier for reviewers to see what you have changed. Use\n   descriptive commit messages on those updates, or plan to use\n   `/label tide/merge-method-squash` to have them squashed when the\n   pull request merges.\n3. Do not rely solely on the enhancement for visibility of the\n   proposal. For high priority work, or if the conversation stalls\n   out, you can start a thread in `#forum-arch` on the CoreOS Slack\n   server or bring the enhancement to one of the weekly architecture\n   review meetings for discussion. If you aren't sure which meeting to\n   use, work with a staff engineer to find a good fit.\n4. If the conversation otherwise seems stuck, pinging reviewers on\n   Slack can be used to remind them to look at updates. It's generally\n   appropriate to give people at least a business day or two to\n   respond in the GitHub thread first, before reaching out to them\n   directly on Slack, so that they can manage their work queue and\n   disruptions.\n\n## Using Labels\n\nThe following labels may be applied to enhancements to help categorize them:\n\n- `priority/important-soon` indicates that the enhancement is related to a\ntop level release priority. These will be highlighted in the\n[this-week](this-week/) newsletters.\n\n## Life-cycle\n\nPull requests to this repository should be short-lived and merged as\nsoon as there is consensus. Therefore, the normal life-cycle timeouts\nare shorter than for most of our code repositories.\n\nPull requests being actively discussed will stay open\nindefinitely. Inactive pull requests will automatically have the\n`life-cycle/stale` label applied after 28 days. Removing the\nlife-cycle label will reset the clock. After 7 days, stale pull\nrequests are updated to `life-cycle/rotten`. After another 7 days,\nrotten pull requests are closed.\n\nIdeally pull requests with enhancement proposals will be merged before\nsignificant coding work begins, since this avoids having to rework the\nimplementation if the design changes as well as arguing in favor of\naccepting a design simply because it is already implemented.\n\n## Template Updates\n\nFrom time to time the template for enhancement proposals is modified\nas we refine our processes. When that happens, open pull requests may\nstart failing the linter job that ensures that all documents include\nthe required sections.\n\nIf you are working on an enhancement and the linter job fails because\nof changes to the template (not other issues with the markdown\nformatting), handle it based on the maturity of the enhancement pull\nrequest:\n\n* If the only reason to update your pull request is to make the linter job\n  accept it after a template change and there are no substantive\n  content changes needed for approval, override the job to allow the\n  pull request to merge.\n* If your enhancement is still a draft, and consensus hasn't been\n  reached, modify the pull request so the new enhancement matches the updated\n  template.\n* If you are updating an existing (merged) document, go ahead and\n  override the job.\n","funding_links":[],"categories":["Go"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenshift%2Fenhancements","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenshift%2Fenhancements","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenshift%2Fenhancements/lists"}