First attempt at an RFC process #7
Conversation
|
|
||
| 1. Navigate to the RFC template in the root of the repository. Copy the contents of the template to your clipboard. | ||
| ### When an RFC is Required |
There was a problem hiding this comment.
Just my first ideas. I loosely hold the opinion that these are correct so please share your opinions on what you'd like to see here!
There was a problem hiding this comment.
Required seems strong for a process that has never even been used.
|
|
||
| 1. **Submit Your RFC as a PR**: Create your RFC using the template and submit it as a Pull Request (PR) to this repository. Use the `Summary` section of your RFC as the PR description. Your PR will serve as the primary platform for discussion about your proposal. | ||
| ### When an RFC is Not Required |
There was a problem hiding this comment.
Again, loosely held opinion by me. What would you all like to see here?
| For an RFC to be merged and accepted: | ||
|
|
||
| 1. **Consensus Among Core Contributors**: There must be approval by _at least_ one core contributor from each project/repository that will be impacted by the RFC during the 1 week **Final Decision** period. | ||
| - **Core Contributor**: A core contributor is someone who |
There was a problem hiding this comment.
Okay I have no idea here. Is core contributor even the right word? Maintainer? Something else? We need to define what/who they are.
There was a problem hiding this comment.
I like maintainer, because to me a maintainer feels like it conveys more of a sense of stewardship of the project.
There was a problem hiding this comment.
I like that. How do we define who that is, objectively?
| 1. **Consensus Among Core Contributors**: There must be approval by _at least_ one core contributor from each project/repository that will be impacted by the RFC during the 1 week **Final Decision** period. | ||
| - **Core Contributor**: A core contributor is someone who | ||
| - At the end of the period, if there are no "Request Changes" from a core contributor the RFC will be accepted/merged. | ||
| 1. **Changes Requested**: In the case that changes are requested by a core contributor and a consensus cannot be reached, the decision will be escalated to the Meshtastic administrators for a majority rule final vote. |
There was a problem hiding this comment.
Not sure if we need to define admins, or point to a legal doc somewhere
There was a problem hiding this comment.
I could swear we had this documented somewhere. I know JM wanted to eventually have our .com domain host a separate website that had us all listed with bios and such.
There was a problem hiding this comment.
He asked me to get the .com stood up, I was hoping to work on that this weekend but it didn't happen. I think that could be a good spot to link to!
There was a problem hiding this comment.
I think we use admin in the sense of Discord, we've used the term project lead for the one or two people accountable for the direction of a specific project (eg: Garth for iOS). We do have a group of people who help maintain each project, approve PRs, etc. Maintainer may be a good one.
It may be good to have community managers at some point. Robert would be an excellent good example of this.
The people on the LLC are Members (this is the legal term) and each member may have a different title for how they see their own role play out. The LLC members are unpaid.
We should keep the roles of the LLC separate from the open source project. Right now, not every admin is a member of the LLC.
There was a problem hiding this comment.
Maybe this sort of guide is overdue. @ajmcquilkin has been talking about growing the sense of so things projects can persist.
There was a problem hiding this comment.
Okay, if we go with Maintainer how do we define who these people are?
|
|
||
| 1. Navigate to the `/rfcs` directory within this repository on GitHub. Click the `Add file` button and select `Create new file`. Name this file `YYYY-MM-DD-feature-name.md`, replacing `YYYY-MM-DD` with the current date and `feature-name` with a descriptive name for your proposal. Paste the contents of the template into this file. | ||
| An RFC is required for any significant change to Meshtastic, introduces new features, or has the potential to impact the user experience or ecosystem broadly. This includes, but is not limited to: |
There was a problem hiding this comment.
The scope of this feels vague enough to where someone might assume that any new feature period would require an RFC. Maybe we need to call out that it's really anything with significant implementation impact across the platforms only?
There was a problem hiding this comment.
Yes I agree here, the introduces new features is too broad. How do we define what significant means? Anyone have ideas?
There was a problem hiding this comment.
Yes I agree here, the
introduces new featuresis too broad. How do we define whatsignificantmeans? Anyone have ideas?
Non-backward compatible?
There was a problem hiding this comment.
An RFC is required for any change that breaks backwards compatibility or would broadly impact either the User Experience or Ecosystem of Meshtastic. This includes but is not limited to:
- Changes to the core architecture
- Major UI/UX changes (e.g. Renaming Channels or Nodes)
- Changes affecting backward compatibility
There was a problem hiding this comment.
An RFC is required for any change that breaks backwards compatibility or would broadly impact either the User Experience or Ecosystem of Meshtastic. This includes but is not limited to: - Changes to the core architecture - Major UI/UX changes (e.g. Renaming Channels or Nodes) - Changes affecting backward compatibility
I like it. Maybe use a word like recommended or warranted possibly instead of required? Makes it seem like there could be punitive consequences if something is done that is perceived as a significant change that doesn't go through an RFC.
There was a problem hiding this comment.
This brings up a good question, what would happen if a change goes through that should have been an RFC? Does it get backed out?
|
Generally I am skeptical this process will be useful for anything other than easily creating an interminable delay. Seems like the intention is to slow things down generally, which I am not really in favor of. I really don't see this getting used more than like once a year for a huge breaking change. |
|
thomas.ekstrand seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Update to the RFC Process
This PR comes out of a discussion started in Discourse in the #docs channel. Reading through this (not very long) discussion may provide additional context for what we are hoping to accomplish with this change.