From ff64cf8b77a81ecc7aa052e585e4646d6a7d280a Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 10:55:13 -0700 Subject: [PATCH 01/12] First draft --- rfcs/63-nursery.md | 169 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 rfcs/63-nursery.md diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md new file mode 100644 index 00000000..b06b5251 --- /dev/null +++ b/rfcs/63-nursery.md @@ -0,0 +1,169 @@ +# Feature Name: `bevy-nursery` + +## Summary + +Work done within the [broader Bevy ecosystem](https://bevyengine.org/assets/) is sometimes a good fit as part of the core engine. +These crates should live in a **nursery** owned by the Bevy org for a period of time, +where they can be polished and refined by the broader community, +before eventually being merged in completely. + +## Motivation + +Third-party crates, commonly plugins, are often used to extend the engine in ways that are broadly applicable. +Polished crates that are a good fit for the engine should eventually be merged in wholesale, +rather than reimplemented, to avoid the [second system effect](https://en.wikipedia.org/wiki/Second-system_effect) +and minimize breakage for their users. + +However, merging in these crates directly will result in very large, unreviewable PRs, +and may compromise Bevy standards for quality. +But if we delay, critical ecosystem crates may go stale, pointlessly splitting efforts, or making it hard for beginners to discover the de-facto standards. + +## User-facing explanation + +In addition to the core crates included within `bevy` itself, there are a number of **nursery** crates, +which are being prepared for inclusion in the engine. + +These crates follow exactly the same technical rules as any other third-party crate, but: + +1. Live in the [`bevyengine` organization](https://github.com/bevyengine) on GitHub. +2. Follow Bevy's standards for code quality and project management. +3. Explicitly welcome community contributions to help get them ready for release. +4. Will have a branch prepared for the newest release of Bevy before we release a new major version. + +You can find these crates by looking for the special `Nursery` tag on [Bevy Assets](https://bevyengine.org/assets/), +or by browsing the [`bevyengine` organization](https://github.com/bevyengine)'s list of repositories. + +### Submitting a crate to the nursery + +If you would like to submit a crate for inclusion in the nursery, please open an issue in the `bevy-nursery` repository. +While you do not need to be the crate's maintainer to do so, the following criteria must be met before it will be accepted to the nursery: + +1. The existing code must be MIT + Apache 2 licensed. +2. The crate maintainers must consent. + 1. While this is not strictly necessary due to licenses, buy-in and consent is important to us. +3. The Bevy maintainers must collectively agree to accept the crate as a nursery crate. + +A crate is a good fit for the nursery if: + +1. The crate covers functionality that we eventually want to include in the engine itself. Factors include: + 1. Broadly useful to engine users. + 2. A direct replacement or improvement for an existing engine feature. +2. The crate is reasonably mature. +3. The crate is well-loved. +4. The crate follows a high standard for testing, code quality and documentation. + +Very small or uncontroversial crates may be suitable for a direct PR via the ordinary mechanism. + +### Setting up a nursery crate + +Once accepted, the repository will be transferred to the Bevy organization under the same name and `crates.io` identity. + +The existing crate maintainers will have complete admin permissions over the new crate, +and any other Bevy maintainers will be granted write permissions (or the `bors` equivalent). + +A new milestone will be created, called `upstreaming`, which will track the work that needs to be completed before the crate can be submitted as a PR to `bevy` itself. + +Finally, the issues and PRs from that crate will be added to the `#bevy-nursery` channel on Discord to improve discoverability. + +### Preparing a crate to be upstreamed + +Before a nursery crate can be accepted to Bevy itself, the following conditions must be met: + +1. All items in the `upstreaming` milestone must be complete. +2. A final release must be published, encompassing all PRs merged to date. +3. The Bevy maintainers must collectively agree to accept the crate upstream in its current form. + +This checklist may be helpful when considering issues for the `upstreaming` milestone: + +- [] are the examples and documentation helpful and complete? +- [] do all features work as intended? +- [] is the code quality acceptable? +- [] is there any urgent highly-experimental work that should be completed before attempting to integrate more closely with the rest of the engine? + +Crates **do not have to be complete** to be merged into Bevy itself: merely polished and clearly useful. + +The PR to merge the crate into Bevy itself should be very simple, and contain only the bare minimum change set required to enable interoperability. +Further integration work should be done in follow-up PRs. +If you are an interested community member, raise issues and submit fixes on the nursery repository **before** the crate is being upstreamed. + +Once the upstreaming PR is merged, the nursery crate's repo will be archived and any still-relevant issues will be migrated to the main Bevy repo. + +### Maintaining upstreamed crates + +When a nursery crate is upstreamed into the main engine, +the core maintainer team of the nursery crate will be offered (but do not need to accept) +**scoped merge rights** for the Bevy project. + +Nursery crate maintainers have shown themselves to have the judgement and reliability needed to manage part of the core engine: +upstreaming a crate should not impose any additional barriers to the crate's development and maintenance. +Following the standard rules for community reviews, they will be able to merge PRs that affect their nursery crate and directly related areas of the engine. +Controversial PRs in their area will require either the sign-off of the project lead *or* the nursery crate maintainer, although like always, consulting experts is always wise! + +Like always, the project lead may choose to hand out (or revoke) additional permissions on a case-by-case basis where warranted, but the expansion of merge rights outlined above is the default process when a nursery crate is upstreamed. + +## Drawbacks + +1. Clearly picks winners within the crate ecosystem. + 1. These winners typically already exist, but it's hard for beginners to discover that critical information. +2. Hands out additional merge rights to the engine. + 1. May increase chaos and dilute product direction. + 2. Tracking areas of expertise may get onerous. + 3. Marginally increases security risks (2FA + only write permissions) reduce this risk substantially. +3. Likely to increase the scope of the core engine. + 1. Feature flags, template games and plugin sets help ensure users only compile and ship the features they care about. + 2. Adding maintainers ensures that the workload does not increase significantly. + +## Rationale and alternatives + +### Why should we upstream crates? + +In other modular ecosystems, it's very common to have critical functionality outside of the core project. +This is unfortunate because: + +1. It's very challenging for beginners to discover these essential tools. +2. These tools cannot readily be used in official documentation. +3. These tools may suddenly go unmaintained. +4. Work may be divided across competitors (including work done by the core). +5. Integration with the core may be poor, or suddenly break. + +By upstreaming essential tools, we can avoid these problems, and gracefully scale the core organization. + +### Why do we need a "nursery" stage? + +Ecosystem crates are huge, complex endeavours. +We want to ensure that the appropriate quality bar is met, but still signal early once a clear candidate has been identified. + +The nursery stage serves as a distributed PR review process for the entire crate, breaking down the necessary changes into manageable units of work. +The added attention helps ensure that community stakeholders have a chance to weigh in before the crate itself is upstreamed. + +Finally, as Bevy stabilizes, nursery crates can be rapidly iterated on without following Bevy's stability guarantees. + +### Why shouldn't we rename the crate to `bevy_nursery_*` for improved discoverability? + +This results in significant bureaucratic work (transferring issues and PRs), risks user confusion and adds pointless migration pain. +The discoverability issue can be tackled via the Discord channel and the prominent label on Bevy Assets. + +### Why do we need to grant merge rights to nursery crate maintainers? + +If we do not: + +1. Maintainers of popular ecosystem crates are reluctant to submit their crates to the nursery due to the reduced ability to iterate on and fix their projects. +2. Maintainers of the core engine may become overloaded with work as the scope of the engine grows. + +The maintainers of nursery crates have shown their ability to identify, create and lead a high-value project: they're natural candidates for additional responsibility in the core engine. + +### Why not use GitHub's Code Owners feature to help scope merge rights? + +While [bors has code owners integration](https://bors.tech/rfcs/0357-bors-support-for-codeowners.html), +it's not clear that it's a useful tool over simple social contract. + +Setting up (and maintaining) these lists is tedious bureaucracy. +This approach would also encourage a less-integrated architecture for organizational reasons, rather than technical ones. + +## Prior art + +The [rust-nursery](https://github.com/rust-lang-nursery) exists for similar reasons, although there is a greater emphasis on stability. + +Unity has a long history of buying out important ecosystem tools, +which are then often left to rot. +By bringing on the existing maintainer team and allowing for direct community contributions we can hopefully avoid this fate. From 1fda144dfef542d4ab7cf6862bd02afc021ac232 Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 11:04:28 -0700 Subject: [PATCH 02/12] Add maintainership info to intro --- rfcs/63-nursery.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index b06b5251..b916feb3 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -6,6 +6,7 @@ Work done within the [broader Bevy ecosystem](https://bevyengine.org/assets/) is These crates should live in a **nursery** owned by the Bevy org for a period of time, where they can be polished and refined by the broader community, before eventually being merged in completely. +When this occurs, nursery crate maintainers will be granted scoped merge rights to the main engine. ## Motivation From 6ad12ff76a5b895d8127683bbc417cf6999f5fb5 Mon Sep 17 00:00:00 2001 From: Alice Cecile Date: Mon, 8 Aug 2022 14:34:52 -0400 Subject: [PATCH 03/12] Add Druid to prior art list --- rfcs/63-nursery.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index b916feb3..830e57aa 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -165,6 +165,8 @@ This approach would also encourage a less-integrated architecture for organizati The [rust-nursery](https://github.com/rust-lang-nursery) exists for similar reasons, although there is a greater emphasis on stability. +[Druid](https://github.com/linebender/druid) has a similar [widget nursery](https://github.com/linebender/druid-widget-nursery), and explicitly follows a policy of [optimistic merging](http://hintjens.com/blog:106) within that repo. + Unity has a long history of buying out important ecosystem tools, which are then often left to rot. By bringing on the existing maintainer team and allowing for direct community contributions we can hopefully avoid this fate. From a4d032840e47736d76f13ace6e982f5772b15adb Mon Sep 17 00:00:00 2001 From: Alice Cecile Date: Mon, 8 Aug 2022 15:30:02 -0400 Subject: [PATCH 04/12] Checklist rendering Co-authored-by: TimJentzsch --- rfcs/63-nursery.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 830e57aa..4246abcd 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -76,10 +76,10 @@ Before a nursery crate can be accepted to Bevy itself, the following conditions This checklist may be helpful when considering issues for the `upstreaming` milestone: -- [] are the examples and documentation helpful and complete? -- [] do all features work as intended? -- [] is the code quality acceptable? -- [] is there any urgent highly-experimental work that should be completed before attempting to integrate more closely with the rest of the engine? +- [ ] are the examples and documentation helpful and complete? +- [ ] do all features work as intended? +- [ ] is the code quality acceptable? +- [ ] is there any urgent highly-experimental work that should be completed before attempting to integrate more closely with the rest of the engine? Crates **do not have to be complete** to be merged into Bevy itself: merely polished and clearly useful. From c1b0a66a1eb5ad747205b0a5e8a25bb0fb15caeb Mon Sep 17 00:00:00 2001 From: Alice Cecile Date: Mon, 8 Aug 2022 15:30:17 -0400 Subject: [PATCH 05/12] Typo Co-authored-by: TimJentzsch --- rfcs/63-nursery.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 4246abcd..2a666727 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -109,7 +109,7 @@ Like always, the project lead may choose to hand out (or revoke) additional perm 2. Hands out additional merge rights to the engine. 1. May increase chaos and dilute product direction. 2. Tracking areas of expertise may get onerous. - 3. Marginally increases security risks (2FA + only write permissions) reduce this risk substantially. + 3. Marginally increases security risks (2FA + only write permissions reduce this risk substantially). 3. Likely to increase the scope of the core engine. 1. Feature flags, template games and plugin sets help ensure users only compile and ship the features they care about. 2. Adding maintainers ensures that the workload does not increase significantly. From d1dcdebe0a6d0f0395bc6fbd1a908c38c9362dec Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 12:42:51 -0700 Subject: [PATCH 06/12] Don't override rules for controversial PRs --- rfcs/63-nursery.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 2a666727..50266a44 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -98,7 +98,8 @@ the core maintainer team of the nursery crate will be offered (but do not need t Nursery crate maintainers have shown themselves to have the judgement and reliability needed to manage part of the core engine: upstreaming a crate should not impose any additional barriers to the crate's development and maintenance. Following the standard rules for community reviews, they will be able to merge PRs that affect their nursery crate and directly related areas of the engine. -Controversial PRs in their area will require either the sign-off of the project lead *or* the nursery crate maintainer, although like always, consulting experts is always wise! +Controversial PRs in their area will still require following the standard `bevy` protocol. +At the time of writing, this means sign-off from the project lead. Like always, the project lead may choose to hand out (or revoke) additional permissions on a case-by-case basis where warranted, but the expansion of merge rights outlined above is the default process when a nursery crate is upstreamed. From 68445e815ebe024b009ad108371ab68cf65c6fb4 Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 12:46:45 -0700 Subject: [PATCH 07/12] Mention possibility of merging of competing crates --- rfcs/63-nursery.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 50266a44..6de2d102 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -107,6 +107,7 @@ Like always, the project lead may choose to hand out (or revoke) additional perm 1. Clearly picks winners within the crate ecosystem. 1. These winners typically already exist, but it's hard for beginners to discover that critical information. + 2. Competing crates may end up being merged as part of the nursery process. 2. Hands out additional merge rights to the engine. 1. May increase chaos and dilute product direction. 2. Tracking areas of expertise may get onerous. From a330a4144b5cbaf987295338484a73ea3bc6cfaf Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 12:51:00 -0700 Subject: [PATCH 08/12] Nursery crates should not expand planned scope --- rfcs/63-nursery.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 6de2d102..bce79ece 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -49,6 +49,7 @@ A crate is a good fit for the nursery if: 1. The crate covers functionality that we eventually want to include in the engine itself. Factors include: 1. Broadly useful to engine users. 2. A direct replacement or improvement for an existing engine feature. + 3. Nursery crates should never expand the planned scope; the choice is between upstreaming and rewriting, not upstreaming vs. leaving in the third party ecosystem forever. 2. The crate is reasonably mature. 3. The crate is well-loved. 4. The crate follows a high standard for testing, code quality and documentation. @@ -112,9 +113,10 @@ Like always, the project lead may choose to hand out (or revoke) additional perm 1. May increase chaos and dilute product direction. 2. Tracking areas of expertise may get onerous. 3. Marginally increases security risks (2FA + only write permissions reduce this risk substantially). -3. Likely to increase the scope of the core engine. - 1. Feature flags, template games and plugin sets help ensure users only compile and ship the features they care about. - 2. Adding maintainers ensures that the workload does not increase significantly. +3. Might increase the scope of the core engine. + 1. Nursery crates should never expand the planned scope of the engine; merely avoid reimplementation of planned work. + 2. Feature flags, template games and plugin sets help ensure users only compile and ship the features they care about. + 3. Adding maintainers ensures that the workload does not increase significantly. ## Rationale and alternatives From 827e913bfd122fb5b9d50ba5eb148c294b708fd2 Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 13:01:49 -0700 Subject: [PATCH 09/12] Naming / versioning strategy details --- rfcs/63-nursery.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index bce79ece..12a873c9 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -58,9 +58,23 @@ Very small or uncontroversial crates may be suitable for a direct PR via the ord ### Setting up a nursery crate -Once accepted, the repository will be transferred to the Bevy organization under the same name and `crates.io` identity. - -The existing crate maintainers will have complete admin permissions over the new crate, +Once accepted, the repository will be transferred to the Bevy organization. +The name, version and `crates.io` identity may change at this time on a case-by-case basis. + +There are three strategies here: + +1. Keep the existing crate name and versioning, then synchronize at the final step. + 1. Avoids breaking end users, very simple. + 2. Well-suited to crates that are likely to be absorbed into other existing `bevy` crates during the integration process to avoid any renaming at all. +2. Change to a temporary `bevy_nursery_*` name, retaining the original versioning and then synchronize at the final step. + 1. Ensures consistent branding and communicates intent to users. + 2. Allows for breaking changes without being synchronized with Bevy's own release schedule. +3. Change directly to the final name and synchronize with Bevy's latest version. + 1. This will limit breaking changes to Bevy's release schedule. + 2. Avoids another rename. + 3. Should only be used for extremely mature crates. + +In this repo, the existing crate maintainers will have complete admin permissions over the new crate, and any other Bevy maintainers will be granted write permissions (or the `bors` equivalent). A new milestone will be created, called `upstreaming`, which will track the work that needs to be completed before the crate can be submitted as a PR to `bevy` itself. @@ -81,6 +95,7 @@ This checklist may be helpful when considering issues for the `upstreaming` mile - [ ] do all features work as intended? - [ ] is the code quality acceptable? - [ ] is there any urgent highly-experimental work that should be completed before attempting to integrate more closely with the rest of the engine? +- [ ] does the crate need to be renamed / re-versioned as part of the integration process? Crates **do not have to be complete** to be merged into Bevy itself: merely polished and clearly useful. From eb8cedd57cc4d81b9f945351e1b8574fb9946f75 Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 13:13:03 -0700 Subject: [PATCH 10/12] Add more opinionated guidance to the upstreaming criteria --- rfcs/63-nursery.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 12a873c9..3933f048 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -95,6 +95,13 @@ This checklist may be helpful when considering issues for the `upstreaming` mile - [ ] do all features work as intended? - [ ] is the code quality acceptable? - [ ] is there any urgent highly-experimental work that should be completed before attempting to integrate more closely with the rest of the engine? +- [ ] do the decisions that the crate has made align with [Bevy's general philosophy](https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md#what-were-trying-to-build)? +- [ ] if we were to start from scratch, what would we have changed? + - [ ] can we get there without requiring a full rewrite? +- [ ] are there any dependencies to third-party plugins? +- [ ] can we reduce our dependency tree by standardizing with `bevy` itself or rewriting small dependencies? +- [ ] does the crate contain any features that we have explicitly relegated to the third-party ecosystem? +- [ ] can niche functionality be split out into ecosystem crates that builds on the foundation established by the new core engine crate? - [ ] does the crate need to be renamed / re-versioned as part of the integration process? Crates **do not have to be complete** to be merged into Bevy itself: merely polished and clearly useful. From dbecf57d4da313fab46d030d2820a2d5be87f6f1 Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 13:23:38 -0700 Subject: [PATCH 11/12] Use code owners to request reviews --- rfcs/63-nursery.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index 3933f048..d80ede24 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -119,12 +119,16 @@ the core maintainer team of the nursery crate will be offered (but do not need t **scoped merge rights** for the Bevy project. Nursery crate maintainers have shown themselves to have the judgement and reliability needed to manage part of the core engine: -upstreaming a crate should not impose any additional barriers to the crate's development and maintenance. +upstreaming a crate should not impose serious additional barriers to the crate's development and maintenance. Following the standard rules for community reviews, they will be able to merge PRs that affect their nursery crate and directly related areas of the engine. Controversial PRs in their area will still require following the standard `bevy` protocol. At the time of writing, this means sign-off from the project lead. -Like always, the project lead may choose to hand out (or revoke) additional permissions on a case-by-case basis where warranted, but the expansion of merge rights outlined above is the default process when a nursery crate is upstreamed. +Like always, the project lead may choose to hand out (or revoke) additional permissions on a case-by-case basis where warranted, +but the expansion of merge rights outlined above is the default process when a nursery crate is upstreamed. + +Nursery crate maintainers will be added as [`CODEOWNERS`](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the areas that cover their now-upstreamed crates. +This will be used for automatically soliciting reviews, but will not be [used to require reviews](https://bors.tech/rfcs/0357-bors-support-for-codeowners.html). ## Drawbacks @@ -179,14 +183,6 @@ If we do not: The maintainers of nursery crates have shown their ability to identify, create and lead a high-value project: they're natural candidates for additional responsibility in the core engine. -### Why not use GitHub's Code Owners feature to help scope merge rights? - -While [bors has code owners integration](https://bors.tech/rfcs/0357-bors-support-for-codeowners.html), -it's not clear that it's a useful tool over simple social contract. - -Setting up (and maintaining) these lists is tedious bureaucracy. -This approach would also encourage a less-integrated architecture for organizational reasons, rather than technical ones. - ## Prior art The [rust-nursery](https://github.com/rust-lang-nursery) exists for similar reasons, although there is a greater emphasis on stability. From 4e65ff870c22781d95ed94b1a3b20922ba294cdf Mon Sep 17 00:00:00 2001 From: Alice Date: Mon, 8 Aug 2022 18:23:42 -0700 Subject: [PATCH 12/12] Remove automatic merge rights --- rfcs/63-nursery.md | 42 ++++++++---------------------------------- 1 file changed, 8 insertions(+), 34 deletions(-) diff --git a/rfcs/63-nursery.md b/rfcs/63-nursery.md index d80ede24..b1cf7f1b 100644 --- a/rfcs/63-nursery.md +++ b/rfcs/63-nursery.md @@ -6,7 +6,6 @@ Work done within the [broader Bevy ecosystem](https://bevyengine.org/assets/) is These crates should live in a **nursery** owned by the Bevy org for a period of time, where they can be polished and refined by the broader community, before eventually being merged in completely. -When this occurs, nursery crate maintainers will be granted scoped merge rights to the main engine. ## Motivation @@ -112,37 +111,21 @@ If you are an interested community member, raise issues and submit fixes on the Once the upstreaming PR is merged, the nursery crate's repo will be archived and any still-relevant issues will be migrated to the main Bevy repo. -### Maintaining upstreamed crates - -When a nursery crate is upstreamed into the main engine, -the core maintainer team of the nursery crate will be offered (but do not need to accept) -**scoped merge rights** for the Bevy project. - -Nursery crate maintainers have shown themselves to have the judgement and reliability needed to manage part of the core engine: -upstreaming a crate should not impose serious additional barriers to the crate's development and maintenance. -Following the standard rules for community reviews, they will be able to merge PRs that affect their nursery crate and directly related areas of the engine. -Controversial PRs in their area will still require following the standard `bevy` protocol. -At the time of writing, this means sign-off from the project lead. - -Like always, the project lead may choose to hand out (or revoke) additional permissions on a case-by-case basis where warranted, -but the expansion of merge rights outlined above is the default process when a nursery crate is upstreamed. - -Nursery crate maintainers will be added as [`CODEOWNERS`](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) to the areas that cover their now-upstreamed crates. -This will be used for automatically soliciting reviews, but will not be [used to require reviews](https://bors.tech/rfcs/0357-bors-support-for-codeowners.html). - ## Drawbacks 1. Clearly picks winners within the crate ecosystem. 1. These winners typically already exist, but it's hard for beginners to discover that critical information. 2. Competing crates may end up being merged as part of the nursery process. -2. Hands out additional merge rights to the engine. - 1. May increase chaos and dilute product direction. - 2. Tracking areas of expertise may get onerous. - 3. Marginally increases security risks (2FA + only write permissions reduce this risk substantially). -3. Might increase the scope of the core engine. +2. Might increase the scope of the core engine. 1. Nursery crates should never expand the planned scope of the engine; merely avoid reimplementation of planned work. 2. Feature flags, template games and plugin sets help ensure users only compile and ship the features they care about. - 3. Adding maintainers ensures that the workload does not increase significantly. +3. Upstreaming additional parts of the engine without adding more maintainers will increase the workload and may slow down progress. + 1. This can be addressed independently. + 2. PR contributors and nursery contributors should be treated equally. +4. The authors of upstreamed crates will lose some creative control over their crates. + 1. They will still be able to make PRs to the core engine, and their opinion will be weighed heavily. + 2. Nursery crate authors may eventually become maintainers in their own right, in no small part due to their work creating and refining the nursery crate. + 3. This is ultimately no worse than a hard fork or reimplementation, which is the direct alternative. ## Rationale and alternatives @@ -174,15 +157,6 @@ Finally, as Bevy stabilizes, nursery crates can be rapidly iterated on without f This results in significant bureaucratic work (transferring issues and PRs), risks user confusion and adds pointless migration pain. The discoverability issue can be tackled via the Discord channel and the prominent label on Bevy Assets. -### Why do we need to grant merge rights to nursery crate maintainers? - -If we do not: - -1. Maintainers of popular ecosystem crates are reluctant to submit their crates to the nursery due to the reduced ability to iterate on and fix their projects. -2. Maintainers of the core engine may become overloaded with work as the scope of the engine grows. - -The maintainers of nursery crates have shown their ability to identify, create and lead a high-value project: they're natural candidates for additional responsibility in the core engine. - ## Prior art The [rust-nursery](https://github.com/rust-lang-nursery) exists for similar reasons, although there is a greater emphasis on stability.