conda pilot/co-pilot release process #49
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Added draft cep pilot/copilot
kenodegard
reviewed
Apr 20, 2023
Comment on lines
+5
to
+6
| | Status | Draft | | ||
| | Author(s) | Dan Meador [email protected]> | |
There was a problem hiding this comment.
Suggested change
| | Status | Draft | | |
| | Author(s) | Dan Meador [email protected]> | | |
| | Author(s) | Dan Meador <[email protected]> | |
|
|
||
| ## Specification | ||
|
|
||
| * Each bi-monthyl (every two month) release will have a pilot and a co-pilot.(See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md)) |
There was a problem hiding this comment.
Suggested change
| * Each bi-monthyl (every two month) release will have a pilot and a co-pilot.(See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md)) | |
| * Each release will have a pilot and a co-pilot. See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md) for the release schedule. |
|
|
||
| * Each bi-monthyl (every two month) release will have a pilot and a co-pilot.(See [CEP-8](https://github.com/conda-incubator/ceps/blob/main/cep-8.md)) | ||
| * The pilot is the primary person responsible for the release, while the co-pilot provides assistance and fills in for the pilot when they are absent. | ||
| * Team members will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases. |
There was a problem hiding this comment.
Suggested change
| * Team members will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases. | |
| * Release managers will switch roles from pilot to co-pilot from one release to the next, serving for three consecutive releases. This is to encourage knowledge sharing. |
Comment on lines
+26
to
+36
| Release 1: Pilot: **Bob Ross(new)**, Co-pilot: **Jane Doe(new)** | ||
|
|
||
| Release 2: Pilot: Jane Doe, Co-pilot: Bob Ross | ||
|
|
||
| Release 3: Pilot: Jane Doe, Co-pilot: **Tobby Smith(new)** | ||
|
|
||
| Release 4: Pilot: Tobby Smith, Co-pilot: Jane Doe | ||
|
|
||
| Release 5: Pilot: Tobby Smith, Co-pilot: **Elvis Presley(new)** | ||
|
|
||
| [pilots_conda](https://user-images.githubusercontent.com/6708083/233211589-10bca344-141e-407a-8edc-ca39014605eb.png) |
There was a problem hiding this comment.
Mermaid chart!
flowchart TB
%% styles
classDef anna fill:#D0D0D0,stroke:#D0D0D0
classDef bert fill:#ED760E,stroke:#ED760E
classDef clay fill:#64C042,stroke:#64C042
classDef debi fill:#20214F,stroke:#20214F,color:#fff
%% role groups
subgraph pilots
pilot1(Anna):::anna
pilot2(Bert):::bert
pilot3(Bert):::bert
pilot4(Clay):::clay
pilot5(Clay):::clay
pilot6(Debi):::debi
pilot7(Debi):::debi
pilot8(Anna):::anna
end
subgraph co-pilots
copilot1(Bert):::bert
copilot2(Anna):::anna
copilot3(Clay):::clay
copilot4(Bert):::bert
copilot5(Debi):::debi
copilot6(Clay):::clay
copilot7(Anna):::anna
copilot8(Debi):::debi
end
%% Anna flow
pilot1-->copilot2
copilot7-->pilot8
%% Bob flow
copilot1-->pilot2-->pilot3-->copilot4
%% Charlie flow
copilot3-->pilot4-->pilot5-->copilot6
%% Denese flow
copilot5-->pilot6-->pilot7-->copilot8
%% Responsibility flow
pilot1-.->pilot2
pilot3-.->pilot4
pilot5-.->pilot6
pilot7-.->pilot8
copilot1-.->copilot2-.->copilot3-.->copilot4-.->copilot5-.->copilot6-.->copilot7-.->copilot8
Suggested change
| Release 1: Pilot: **Bob Ross(new)**, Co-pilot: **Jane Doe(new)** | |
| Release 2: Pilot: Jane Doe, Co-pilot: Bob Ross | |
| Release 3: Pilot: Jane Doe, Co-pilot: **Tobby Smith(new)** | |
| Release 4: Pilot: Tobby Smith, Co-pilot: Jane Doe | |
| Release 5: Pilot: Tobby Smith, Co-pilot: **Elvis Presley(new)** | |
| [pilots_conda](https://user-images.githubusercontent.com/6708083/233211589-10bca344-141e-407a-8edc-ca39014605eb.png) | |
| ```mermaid | |
| flowchart TB | |
| %% styles | |
| classDef anna fill:#D0D0D0,stroke:#D0D0D0 | |
| classDef bert fill:#ED760E,stroke:#ED760E | |
| classDef clay fill:#64C042,stroke:#64C042 | |
| classDef debi fill:#20214F,stroke:#20214F,color:#fff | |
| %% role groups | |
| subgraph pilots | |
| pilot1(Anna):::anna | |
| pilot2(Bert):::bert | |
| pilot3(Bert):::bert | |
| pilot4(Clay):::clay | |
| pilot5(Clay):::clay | |
| pilot6(Debi):::debi | |
| pilot7(Debi):::debi | |
| pilot8(Anna):::anna | |
| end | |
| subgraph co-pilots | |
| copilot1(Bert):::bert | |
| copilot2(Anna):::anna | |
| copilot3(Clay):::clay | |
| copilot4(Bert):::bert | |
| copilot5(Debi):::debi | |
| copilot6(Clay):::clay | |
| copilot7(Anna):::anna | |
| copilot8(Debi):::debi | |
| end | |
| %% Anna flow | |
| pilot1-->copilot2 | |
| copilot7-->pilot8 | |
| %% Bob flow | |
| copilot1-->pilot2-->pilot3-->copilot4 | |
| %% Charlie flow | |
| copilot3-->pilot4-->pilot5-->copilot6 | |
| %% Denese flow | |
| copilot5-->pilot6-->pilot7-->copilot8 | |
| %% Responsibility flow | |
| pilot1-.->pilot2 | |
| pilot3-.->pilot4 | |
| pilot5-.->pilot6 | |
| pilot7-.->pilot8 | |
| copilot1-.->copilot2-.->copilot3-.->copilot4-.->copilot5-.->copilot6-.->copilot7-.->copilot8 |
|
|
||
| ## Abstract | ||
|
|
||
| This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between team members and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it. |
There was a problem hiding this comment.
Suggested change
| This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between team members and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it. | |
| This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between release managers and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it. |
There was a problem hiding this comment.
@LtDan33 We were also thinking of the a QA member in a piece for release. Do we mention that as well
|
|
||
| * Responsible for certain roles or activities for a given conda (or another project) version. | ||
| * Be an extra set of eyes to help the pilot get to the correct outcome. | ||
| * Help with communication with the team and the broader community. |
There was a problem hiding this comment.
Suggested change
| * Help with communication with the team and the broader community. | |
| * Help with communication across the broader community. |
|
|
||
| ## Rationale | ||
|
|
||
| The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for other team members to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runsthe conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city. |
There was a problem hiding this comment.
Suggested change
| The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for other team members to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runsthe conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city. | |
| The pilot and co-pilot model has been proven to work well in other projects, ensuring that there is always at least one person with the necessary experience and knowledge to handle releases, while also providing opportunities for others to learn and grow. This inspiration came from seeing how PyCon US has run their conference where the same city runs the conference twice in a row, with the second year providing an opportunity for the next years city to learn from the previous years city. |
|
|
||
| ## Alternatives | ||
|
|
||
| 1. Have a dedicated release manager role, but this would limit the opportunities for team members to learn and grow, and it may create a single point of failure if the release manager becomes unavailable. |
There was a problem hiding this comment.
Suggested change
| 1. Have a dedicated release manager role, but this would limit the opportunities for team members to learn and grow, and it may create a single point of failure if the release manager becomes unavailable. | |
| 1. Have a dedicated release manager role, but this would limit the opportunities for the community at large to learn and grow, and it may create a single point of failure if the release manager becomes unavailable. |
Comment on lines
+80
to
+82
| Q) Conda broke on a Saturday due to a late Friday release, who should fix it? | ||
|
|
||
| A) The pilot is accountable for ensuring that critical conda issues due to the release are addressed. We simply have too many users that could be in an unusable state to not address this. Its recommended that we don’t release on a Friday for this reason. |
There was a problem hiding this comment.
Per CEP-8, Friday releases are not allowed, the absolute latest in a week a release can occur is on a Thursday.
| ## FAQ | ||
|
|
||
| Q) Who can be a Pilot/copilot on a release? | ||
| A) Must be a core conda team member. |
There was a problem hiding this comment.
Suggested change
| A) Must be a core conda team member. | |
| A) Must be a maintainer of conda (or other conda project being released). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a CEP that proposes a formal release responsibility cadence.
Abstract:
This proposal aims to establish a clear and efficient release process for conda (and other conda projects) by implementing a pilot and co-pilot system, ensuring a smooth transfer of responsibilities between team members and the continuous improvement of release quality. There will also be one "jump seat" available for those that want to sit in and observe the release process, but not be responsible for any of it.