docs: add request for maintainership md file #2453
Conversation
charleenfei
requested review from
colin-axner,
AdityaSripal,
crodriguezvega,
seantking,
damiannolan and
chatton
as code owners
There was a problem hiding this comment.
Thanks @charleenfei :) Left some initial thoughts. Very open to differing opinions
|
|
||
|
|
||
| <p align="center"> | ||
| <img src="maintainership.png?raw=true" alt="maintainership" width="80%" /> |
There was a problem hiding this comment.
One question about the image, if there isn't an ICS spec, there should be right? Or is it supposed to imply an ICS spec won't always be necessary?
There was a problem hiding this comment.
some cases (specified in the spec section below) will not require an ics spec -- we can update the image to add the spec process as a dotted box perhaps to suggest it's not always necessary
There was a problem hiding this comment.
"Is there an ICS spec?" I think can be "Is an ICS spec required?" ?
There was a problem hiding this comment.
Thanks @charleenfei :) Everything looks good to me. We can always make modifications as we try this process out
|
|
||
|
|
||
| <p align="center"> | ||
| <img src="maintainership.png?raw=true" alt="maintainership" width="80%" /> |
There was a problem hiding this comment.
"Is there an ICS spec?" I think can be "Is an ICS spec required?" ?
|
|
||
| ## Step 2: Submit spec to the IBC protocol repo | ||
|
|
||
| A detailed review of the specification can be expected **within 2 weeks** of submission of the specification to the repo. Please notify the specification team if this does not occur, so it can be corrected as soon as possible. Please note that this timeline may be subject to amendment based on complexity of the spec and team capacity considering other ongoing reviews, but we will strive to ensure a 2 week turnaround. |
There was a problem hiding this comment.
should we include an email address for the specification team as we need for product?
There was a problem hiding this comment.
good question. @AdityaSripal do you have a preference here?
MAINTAINERSHIP.md
Outdated
|
|
||
| *(this step can be initiated in parallel w/ spec submission, subject to feature complexity)* | ||
|
|
||
| Once the spec has been given initial approval, `ibc-go` engineering will coordinate a code walkthrough in preparation for taking the module into the repo. Any requested changes from the `ibc-go` engineering team after the code walkthrough should be discussed and/or addressd in a timely manner. |
There was a problem hiding this comment.
| Once the spec has been given initial approval, `ibc-go` engineering will coordinate a code walkthrough in preparation for taking the module into the repo. Any requested changes from the `ibc-go` engineering team after the code walkthrough should be discussed and/or addressd in a timely manner. | |
| Once the spec has been given initial approval, `ibc-go` engineering will coordinate a code walkthrough in preparation for taking the module into the repo. Any requested changes from the `ibc-go` engineering team after the code walkthrough should be discussed and/or addressed in a timely manner. |
MAINTAINERSHIP.md
Outdated
|
|
||
| The code that is presented should adhere to our [code contributor guidelines](https://github.com/cosmos/ibc-go/blob/main/CONTRIBUTING.md). | ||
|
|
||
| More details on what code walkthrough should cover will be provided by the `ibc-go` engineering team on a case by case basis. However, the code should be sufficiently unit and E2E tested. Think about preparing for this process similarly to submitting a codebase for audit :) |
There was a problem hiding this comment.
[nit] we are using walkthrough and walk through, we should use one to stay consistent.
[mega-nit] we should keep punctuation consistent (missing full stop)
There was a problem hiding this comment.
Maybe we can link to the E2E Readme here
MAINTAINERSHIP.md
Outdated
|
|
||
| More details on what code walkthrough should cover will be provided by the `ibc-go` engineering team on a case by case basis. However, the code should be sufficiently unit and E2E tested. Think about preparing for this process similarly to submitting a codebase for audit :) | ||
|
|
||
| Please indicate the expected contribution of your team maintainership, if any. This contribution should also include ideas about devrels support and support for product on social media |
There was a problem hiding this comment.
| Please indicate the expected contribution of your team maintainership, if any. This contribution should also include ideas about devrels support and support for product on social media | |
| Please indicate the expected contribution of your team maintainership, if any. This contribution should also include ideas about devrels support and support for product on social media. |
MAINTAINERSHIP.md
Outdated
| @@ -0,0 +1,74 @@ | |||
| # Request For Maintainership | |||
|
|
|||
| This document details the acceptance process for requests from external contributors who require for the `ibc-go` core team to take over **maintainership** of a complex block of code (ie: an application module or a light client implementation). It is the process we also follow internally for features that we develop which will go into the `ibc-go` codebase. | |||
There was a problem hiding this comment.
In the rest of the docs in the repo we write ibc-go in normal text.
| This document details the acceptance process for requests from external contributors who require for the `ibc-go` core team to take over **maintainership** of a complex block of code (ie: an application module or a light client implementation). It is the process we also follow internally for features that we develop which will go into the `ibc-go` codebase. | |
| This document details the acceptance process for requests from external contributors who require for the ibc-go core team to take over **maintainership** of a complex block of code (ie: an application module or a light client implementation). It is the process we also follow internally for features that we develop which will go into the `ibc-go` codebase. |
MAINTAINERSHIP.md
Outdated
|
|
||
| Answer these questions in a requirements doc: | ||
|
|
||
| ``` |
There was a problem hiding this comment.
I would just write this in normal text as an unordered list.
Description
As the Cosmos ecosystem has expanded and flourished, it has become increasingly apparent that along with ecosystem growth, there has been the growth of great development teams working on IBC applications and features. We recognise that having these applications in the ibc-go repo can be valuable for ease of discoverability, "officialness", and of course assurance of seamless performance as updates to the repo continue to be pushed by our team and collaborators.
We've spent a lot of time working on processes to handle inbound requests for maintaining important IBC applications which may be valuable for the entire Interchain ecosystem but developed outside of our engineering team. This document seeks to articulate this process (as well as our our own internal process of developing any new feature).
Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.
docs/) or specification (x/<module>/spec/)godoccomments.Unreleasedsection inCHANGELOG.mdFiles changedin the Github PR explorerCodecov Reportin the comment section below once CI passes