From 3fad42c88ecc2761c8a0c1cdbeda1e77f3af5ab1 Mon Sep 17 00:00:00 2001 From: davidmirror-ops Date: Wed, 31 Jul 2024 14:46:06 -0500 Subject: [PATCH 1/9] Create RFC for community plugins Signed-off-by: davidmirror-ops --- rfc/system/0008-community-plugins.md | 48 ++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 rfc/system/0008-community-plugins.md diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md new file mode 100644 index 0000000000..cba340ad03 --- /dev/null +++ b/rfc/system/0008-community-plugins.md @@ -0,0 +1,48 @@ +# Management of community-contributed plugins + +**Authors:** + +- @davidmirror-ops + + +## 1 Executive Summary + +The Flyte community as a self-governed and productive collective of individuals, values contributions. This proposal aims to discuss the process community contributors should follow to submit a new `flytekit` plugin, with special attention to mechanisms that ensure stability and maintainability of core flyte code. + +## 2 Motivation + +- With the current "in-tree" approach, plugins developed by the community land on the `flytekit` repo ([example](https://github.com/flyteorg/flytekit/pull/2537)). It results in Flyte maintainers having to take care of CI test failures due to plugin code or flytekit updates incompatible with plugin code, etc. + +- The goal is to agree on a process for contributors to follow when submitting new integrations in a "out-of-tree" way that clearly communicates that it is a community-contributed -and then- community-supported integration. + +## 3 Proposed Implementation + +- Create a `community` folder under `flytekit/plugins` and publish the plugins in that folder as separate `pypi` packages. +- Configure CI to only run tests on `plugins/community` when there are changes. +- Keep releasing plugins alongside flytekit. +- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS), enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `plugins/community`). + +### Promotion process to "core"/"official" plugin + +@pryce-tuner [proposed criteria](https://github.com/flyteorg/flytekit/pull/2615/files#diff-c26d70784719ec01ce402e532a281a3e509d47523c3a1eba9b2c8d02933886a4R21) to promote plugins to be part of core flytekit, including the effects. + +## 4 Drawbacks + +- There's a management overhead associated with this initiative: + - For every new plugin contributor, we may need to update `CODEOWNERS` + - CI configuration changes in flytekit (probably a one-time change) + +## 5 Alternatives + +- Maintain community plugins on a separate repo + - Against the monorepo initiative +- Have community packages be it's own org + - Significantly higher management overhead +- `flytekit` plugins built into their own package + - Potentially heavier development process + +## 6 Open questions + +- Does this apply to Agents? + + From 87a55fa9d94dfffc3ff6cc083ca0dcf578984bbc Mon Sep 17 00:00:00 2001 From: davidmirror-ops Date: Thu, 1 Aug 2024 11:13:33 -0500 Subject: [PATCH 2/9] Apply part of review Signed-off-by: davidmirror-ops --- rfc/system/0008-community-plugins.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index cba340ad03..4364fa7255 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -17,14 +17,15 @@ The Flyte community as a self-governed and productive collective of individuals, ## 3 Proposed Implementation -- Create a `community` folder under `flytekit/plugins` and publish the plugins in that folder as separate `pypi` packages. +- Create a `community` folder under `flytekit/plugins` and keep releasing the plugins in that folder as separate `pypi` packages. - Configure CI to only run tests on `plugins/community` when there are changes. - Keep releasing plugins alongside flytekit. -- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS), enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `plugins/community`). +- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS), enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `flytekit`). ### Promotion process to "core"/"official" plugin @pryce-tuner [proposed criteria](https://github.com/flyteorg/flytekit/pull/2615/files#diff-c26d70784719ec01ce402e532a281a3e509d47523c3a1eba9b2c8d02933886a4R21) to promote plugins to be part of core flytekit, including the effects. +- The supermajority of the TSC should approve publicly before promoting a plugin. ## 4 Drawbacks From 17ed543764876852bf2b2279408d3212f7d5b533 Mon Sep 17 00:00:00 2001 From: davidmirror-ops Date: Wed, 28 Aug 2024 11:14:15 -0500 Subject: [PATCH 3/9] Update promotion process Signed-off-by: davidmirror-ops --- rfc/system/0008-community-plugins.md | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index 4364fa7255..d1d47be75f 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -20,12 +20,22 @@ The Flyte community as a self-governed and productive collective of individuals, - Create a `community` folder under `flytekit/plugins` and keep releasing the plugins in that folder as separate `pypi` packages. - Configure CI to only run tests on `plugins/community` when there are changes. - Keep releasing plugins alongside flytekit. -- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS), enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `flytekit`). +- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS) for the `plugins/community` folder, enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `flytekit`). +- Explicitly mark them as community maintained in the import via `import flytekitplugins.contrib.x` + +### Promotion process to official plugin + +An official plugin is one that is maintained by the core Flyte team and is made part of the official `flytekit` documentation. + +- Plugins maintainers or community members can propose the promotion of a plugin to official by creating an Issue on the `flytekit` repo. +- The supermajority of the TSC must approve publicly before promoting a plugin. + +To consider it for promotion, a plugin must meet the following criteria: + +- Production readiness testing performed by the core Flyte team or documented by plugin users or maintainers +- Evidence of ongoing usage through Github issues or Slack threads -### Promotion process to "core"/"official" plugin -@pryce-tuner [proposed criteria](https://github.com/flyteorg/flytekit/pull/2615/files#diff-c26d70784719ec01ce402e532a281a3e509d47523c3a1eba9b2c8d02933886a4R21) to promote plugins to be part of core flytekit, including the effects. -- The supermajority of the TSC should approve publicly before promoting a plugin. ## 4 Drawbacks From e7efe712f87d7bb47d925ab327475cd00decb832 Mon Sep 17 00:00:00 2001 From: "Fabio M. Graetz, Ph.D." Date: Thu, 29 Aug 2024 20:43:03 +0200 Subject: [PATCH 4/9] Update rfc/system/0008-community-plugins.md Signed-off-by: Fabio M. Graetz, Ph.D. --- rfc/system/0008-community-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index d1d47be75f..21662b03d1 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -34,7 +34,7 @@ To consider it for promotion, a plugin must meet the following criteria: - Production readiness testing performed by the core Flyte team or documented by plugin users or maintainers - Evidence of ongoing usage through Github issues or Slack threads - +- Documented in flytekit's documentation ## 4 Drawbacks From ee2d3974cdd83696f1f31e960323f35a8d200d58 Mon Sep 17 00:00:00 2001 From: davidmirror-ops Date: Wed, 25 Sep 2024 13:24:53 -0500 Subject: [PATCH 5/9] Remove codeowners step Signed-off-by: davidmirror-ops --- rfc/system/0008-community-plugins.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index 21662b03d1..7181ab4d60 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -19,9 +19,9 @@ The Flyte community as a self-governed and productive collective of individuals, - Create a `community` folder under `flytekit/plugins` and keep releasing the plugins in that folder as separate `pypi` packages. - Configure CI to only run tests on `plugins/community` when there are changes. -- Keep releasing plugins alongside flytekit. -- Update [CODEOWNERS](https://github.com/flyteorg/flytekit/blob/master/CODEOWNERS) for the `plugins/community` folder, enabling contributors to merge community plugins (it requires granting Write permissions to contributors on `flytekit`). -- Explicitly mark them as community maintained in the import via `import flytekitplugins.contrib.x` +- Keep releasing community plugins alongside flytekit, even if there are no changes. +- Explicitly mark plugins as community maintained in the import via `import flytekitplugins.contrib.x` +- Plugin authors are responsible for maintaining their plugins, and `flytekit` maintainers are responsible for final approvals and merging into the repo. ### Promotion process to official plugin @@ -37,11 +37,10 @@ To consider it for promotion, a plugin must meet the following criteria: - Documented in flytekit's documentation + ## 4 Drawbacks -- There's a management overhead associated with this initiative: - - For every new plugin contributor, we may need to update `CODEOWNERS` - - CI configuration changes in flytekit (probably a one-time change) +- Potential overhead: CI configuration changes in flytekit (probably a one-time change) ## 5 Alternatives @@ -52,8 +51,8 @@ To consider it for promotion, a plugin must meet the following criteria: - `flytekit` plugins built into their own package - Potentially heavier development process -## 6 Open questions - -- Does this apply to Agents? +- Adding plugin authors as CODEOWNERS won't be considered due to a [Github permission model](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) limitation: +>The people you choose as code owners must have write permissions for the repository. +Getting write permissions in `flytekit` via contributing plugins is not part of the [current Governance model](https://github.com/flyteorg/community/blob/main/GOVERNANCE.md#community-roles-and-path-to-maintainership) for flyte. From a77d103739fc70d5e758447ad21298b48e664783 Mon Sep 17 00:00:00 2001 From: "Fabio M. Graetz, Ph.D." Date: Thu, 26 Sep 2024 20:47:41 +0200 Subject: [PATCH 6/9] Update rfc/system/0008-community-plugins.md Signed-off-by: Fabio M. Graetz, Ph.D. --- rfc/system/0008-community-plugins.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index 7181ab4d60..d827c5b4db 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -23,6 +23,7 @@ The Flyte community as a self-governed and productive collective of individuals, - Explicitly mark plugins as community maintained in the import via `import flytekitplugins.contrib.x` - Plugin authors are responsible for maintaining their plugins, and `flytekit` maintainers are responsible for final approvals and merging into the repo. +This proposal includes agent plugins. ### Promotion process to official plugin An official plugin is one that is maintained by the core Flyte team and is made part of the official `flytekit` documentation. From 4a4cb820d5df3677de17457005f8d97795aac4c9 Mon Sep 17 00:00:00 2001 From: "Fabio M. Graetz, Ph.D." Date: Thu, 26 Sep 2024 20:50:27 +0200 Subject: [PATCH 7/9] Update rfc/system/0008-community-plugins.md Signed-off-by: Fabio M. Graetz, Ph.D. --- rfc/system/0008-community-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index d827c5b4db..7f29ad49a1 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -18,7 +18,7 @@ The Flyte community as a self-governed and productive collective of individuals, ## 3 Proposed Implementation - Create a `community` folder under `flytekit/plugins` and keep releasing the plugins in that folder as separate `pypi` packages. -- Configure CI to only run tests on `plugins/community` when there are changes. +- Configure CI to only run tests on `plugins/community` when there are changes to a respective plugin. - Keep releasing community plugins alongside flytekit, even if there are no changes. - Explicitly mark plugins as community maintained in the import via `import flytekitplugins.contrib.x` - Plugin authors are responsible for maintaining their plugins, and `flytekit` maintainers are responsible for final approvals and merging into the repo. From d7de8de52f1e1437c9044715f4a71595d8b17e30 Mon Sep 17 00:00:00 2001 From: "Fabio M. Graetz, Ph.D." Date: Thu, 26 Sep 2024 20:50:42 +0200 Subject: [PATCH 8/9] Update rfc/system/0008-community-plugins.md Signed-off-by: Fabio M. Graetz, Ph.D. --- rfc/system/0008-community-plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index 7f29ad49a1..dde9581cda 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -28,7 +28,7 @@ This proposal includes agent plugins. An official plugin is one that is maintained by the core Flyte team and is made part of the official `flytekit` documentation. -- Plugins maintainers or community members can propose the promotion of a plugin to official by creating an Issue on the `flytekit` repo. +- Plugin maintainers or community members can propose the promotion of a plugin to official by creating an Issue on the `flytekit` repo. - The supermajority of the TSC must approve publicly before promoting a plugin. To consider it for promotion, a plugin must meet the following criteria: From a72533bb0b0df7cfea6a1c641a511b47982fa3c5 Mon Sep 17 00:00:00 2001 From: David Espejo <82604841+davidmirror-ops@users.noreply.github.com> Date: Thu, 26 Sep 2024 14:42:32 -0500 Subject: [PATCH 9/9] Apply suggestions from code review Co-authored-by: Fabio M. Graetz, Ph.D. Signed-off-by: David Espejo <82604841+davidmirror-ops@users.noreply.github.com> --- rfc/system/0008-community-plugins.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/system/0008-community-plugins.md b/rfc/system/0008-community-plugins.md index dde9581cda..0283657c87 100644 --- a/rfc/system/0008-community-plugins.md +++ b/rfc/system/0008-community-plugins.md @@ -11,7 +11,7 @@ The Flyte community as a self-governed and productive collective of individuals, ## 2 Motivation -- With the current "in-tree" approach, plugins developed by the community land on the `flytekit` repo ([example](https://github.com/flyteorg/flytekit/pull/2537)). It results in Flyte maintainers having to take care of CI test failures due to plugin code or flytekit updates incompatible with plugin code, etc. +- With the current "in-tree" approach, plugins developed by the community land in the `flytekit` repo ([example](https://github.com/flyteorg/flytekit/pull/2537)). It results in Flyte maintainers having to take care of CI test failures due to plugin code or flytekit updates incompatible with plugin code, etc. Flyte maintainers are also expected to provide support about and fix bugs in plugins integrating 3rd party libraries that they might have little knowledge off. - The goal is to agree on a process for contributors to follow when submitting new integrations in a "out-of-tree" way that clearly communicates that it is a community-contributed -and then- community-supported integration. @@ -21,7 +21,7 @@ The Flyte community as a self-governed and productive collective of individuals, - Configure CI to only run tests on `plugins/community` when there are changes to a respective plugin. - Keep releasing community plugins alongside flytekit, even if there are no changes. - Explicitly mark plugins as community maintained in the import via `import flytekitplugins.contrib.x` -- Plugin authors are responsible for maintaining their plugins, and `flytekit` maintainers are responsible for final approvals and merging into the repo. +- Plugin authors are responsible for maintaining their plugins. In case there are PRs to change a community plugin, the plugin maintainers review the PR and give a non-binding approval. Once a community plugin maintainer has given a non-binding approval, a `flytekit` maintainer has to give a binding approval in order for the PR to be merged. This proposal includes agent plugins. ### Promotion process to official plugin