Conversation
mpgxvii
left a comment
mpgxvii
left a comment
There was a problem hiding this comment.
This is great, LGTM! This will really help standardise processes, especially with the amount of changes/improvements needed for RADAR-base. I just had a few questions to clarify things. Thanks!
| - type: markdown | ||
| attributes: | ||
| value: | | ||
| Use this to validate that the proposal warrants an RFC and to collect early feedback. |
There was a problem hiding this comment.
Do we have to create a pre-RFC everytime before an RFC and will it follow the same lifecycle?
There was a problem hiding this comment.
no, this is only when you are not sure if you need an RFC. I most cases, if the impact of the change is large and you could use help designing it, then RFC should be opened
| - [ ] Filled all required sections (Summary, Motivation, Design, Security, Migration, Testing) | ||
| - [ ] Added to index table in `README.md` | ||
| - [ ] Considered alternatives and documented open questions | ||
| - [ ] Applied appropriate status label (one of: draft, accepted, rejected, superseded, implemented) |
There was a problem hiding this comment.
How and when do we determine the status/status labels? Is it during the general discussion in the PR?
There was a problem hiding this comment.
yes based on the status of the discussion, these can be updated
| --------- | ||
| - Draft: PR opened, under active review. | ||
| - Accepted: Consensus reached and approved by maintainers. | ||
| - Rejected: Not accepted (with rationale). |
There was a problem hiding this comment.
If rejected, the RFC PR is just closed?
There was a problem hiding this comment.
Yes I think so, but we increment the number
There was a problem hiding this comment.
Should we create issues in RADAR-base Roadmap for merged RFCs or perhaps better each merged RFC gets a project (or similar e.g. JIRA) for decomposition and management of the epic?
There was a problem hiding this comment.
yes an epic could be nice, the common way is once the RFC is accepted, the issue(s) are created in appropriate repositories, which can then be added to the roadmap (depending on the priority)
|
|
||
| Summary | ||
| ------- | ||
| One-paragraph executive summary. What problem is being solved and the high-level solution? |
There was a problem hiding this comment.
Does the background (status quo) also go in here?
There was a problem hiding this comment.
I think it would fall under "context" so would be part of the Motivation section
| Status: Draft | ||
| Created: <YYYY-MM-DD> | ||
| Updated: <YYYY-MM-DD> | ||
| Discussion: <link to issue or discussion> |
There was a problem hiding this comment.
Will the discussion about the RFC be in the PR or in a separate discussion?
There was a problem hiding this comment.
if there is a pre-existing discussion, could be on another issue or discussion or even a Pre-RFC thread.
There was a problem hiding this comment.
Yes, perhaps note in the README to link relevant issues /repo#issue in the RFC?
|
|
||
| Reference-level design | ||
| ---------------------- | ||
| Precise, technical details: architecture, data models, APIs, configuration, migrations, security/privacy considerations, performance characteristics, and failure modes. |
There was a problem hiding this comment.
Will the implementation plan go here?
There was a problem hiding this comment.
Yes, i think main aim is to get the design and technical details right, then develop an implementation plan. If you feel we need more sections in the template please feel free to suggest.
There was a problem hiding this comment.
a few reference example rfcs will help too.
There was a problem hiding this comment.
Yes I plan to make an RFC request soon for the new data architecture, which hopefully gets merged.
afolarin
left a comment
afolarin
left a comment
There was a problem hiding this comment.
few minor comments but otherwise LGTM ... 🙌🏽
| Process | ||
| ------- | ||
| 1. Open a "Pre-RFC discussion" issue to validate scope and gather early feedback. | ||
| 2. Fork and branch. Copy `rfcs/0000-template.md` to `rfcs/NNNN-title.md`. If the RFC clearly belongs to an area, place it under `rfcs/platform/`, `rfcs/backend/`, or `rfcs/mobile/`. |
There was a problem hiding this comment.
Should we provide a formal list of the major domains for some consistency? Outside of the three listed, will we just leave to submitters to decide domain? e.g. analysis (for pipeline) it's not really backend. We could also have a general category.
There was a problem hiding this comment.
Yes added new domains now.
| --------- | ||
| - Draft: PR opened, under active review. | ||
| - Accepted: Consensus reached and approved by maintainers. | ||
| - Rejected: Not accepted (with rationale). |
There was a problem hiding this comment.
Should we create issues in RADAR-base Roadmap for merged RFCs or perhaps better each merged RFC gets a project (or similar e.g. JIRA) for decomposition and management of the epic?
| Status: Draft | ||
| Created: <YYYY-MM-DD> | ||
| Updated: <YYYY-MM-DD> | ||
| Discussion: <link to issue or discussion> |
There was a problem hiding this comment.
Yes, perhaps note in the README to link relevant issues /repo#issue in the RFC?
|
|
||
| Reference-level design | ||
| ---------------------- | ||
| Precise, technical details: architecture, data models, APIs, configuration, migrations, security/privacy considerations, performance characteristics, and failure modes. |
There was a problem hiding this comment.
a few reference example rfcs will help too.
…r, CODEOWNERS, workflows, templates
3 participants
This will make sure we have a concrete process to plan any major changes to RADAR-Base.