Skip to content

First attempt at an RFC process #7

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
tekstrand wants to merge 1 commit into
base: main
Choose a base branch
from
Open

First attempt at an RFC process #7

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added .DS_Store
View file
Open in desktop
Binary file not shown.
23 changes: 23 additions & 0 deletions CONTRIBUTION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
1. **Familiarize with the RFC Template**: Before submitting an RFC, please review our [RFC Template](template.md). This template provides a structured format for proposing changes.

1. **Write up your proposal**: There are two methods to write up your proposal within this repository. If you are comfortable with how to work with Git, we recommend you clone this repository, create a copy of the RFC template in the `/rfcs` directory, and submit a PR. If you are not familiar with Git, we recommend you follow the steps below:

1. Sign into or create a GitHub account. Then, navigate to [https://github.com/meshtastic/rfcs](https://github.com/meshtastic/rfcs).

1. Navigate to the RFC template in the root of the repository. Copy the contents of the template to your clipboard.

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.

1. Fill in the template with your proposal. Be sure to include a descriptive title and summary, as well as a detailed description of your proposal. Once you are done, copy the title and high-level description of your proposal. You will need this in the next step.

1. When you are finished, click "Commit Changes" at the top of the page. Enter the title and description from the last step into the appropriate fields. Then, click "Propose changes." This will create a new Pull Request (PR) for your proposal.

1. Congratulations! You have successfully submitted an RFC. Now, you can engage in the discussion about your proposal. You can view your PR by navigating to the pull requests tab here: [https://github.com/meshtastic/rfcs/pulls](https://github.com/meshtastic/rfcs/pulls)

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.

> **Note:** If you followed the steps to edit your proposal in the GitHub web interface, you can skip this step! Your proposal is already submitted as a PR.
1. **Participate in the Discussion**: Engage with the community and project maintainers in the PR discussion. This is where your proposal will be reviewed, and feedback will be provided.

1. **Finalizing the RFC**: The discussion period will remain open until the RFC is deemed complete. Upon completion, the PR will be closed. Note that closing the PR does not necessarily mean the RFC is approved; it signifies the end of the discussion phase.
72 changes: 49 additions & 23 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,50 +1,76 @@
# Meshtastic RFC Repository

Welcome to the RFC (Request for Comments) repository for the Meshtastic mesh networking project! This repository is a dedicated space for discussing and managing significant changes and enhancements to the Meshtastic project, which focuses on creating firmware for LoRa mesh networking radios.
Welcome to the RFC (Request for Comments) Documentation Repository. This repository is designed to increase community collaboration and ensure transparency throughout the development of Meshtastic. By following a structured approach to proposing, discussing, and implementing new features and changes, we seek to create a cohesive, forward-thinking community.

## Purpose of This Repository

The Meshtastic RFC repository serves as a centralized hub for collaboratively discussing, reviewing, and deciding on major changes and new features across various Meshtastic repositories. This includes the firmware repository, client applications, and language support repos. It's important to note that this repository is for documentation and discussion only and does not contain code files.
1. **Facilitate Open Communication**: Provide a place for contributors and community members to propose, discuss, and refine new ideas or changes to Meshtastic in an open and inclusive manner.
1. **Ensure Transparency**: Make the decision-making process visible to all stakeholders, allowing for a transparent and democratic approach to Meshtastic development.
1. **Promote Collaboration**: Encourage contributions to leverage the collective expertise and perspectives of our community to drive Meshtastic forward.
1. **Maintain Project Integrity**: Ensure that changes and new features align with Meshtastic's overall goals and values, while preserving integrity and focus.

## How to Make an RFC
## Contribution Guidelines & Participation

1. **Familiarize with the RFC Template**: Before submitting an RFC, please review our [RFC Template](template.md). This template provides a structured format for proposing changes.
While contributing to the Meshtastic RFC repository, please adhere to our community standards and guidelines. These are in place to ensure a productive and respectful environment for collaboration.

1. **Write up your proposal**: There are two methods to write up your proposal within this repository. If you are comfortable with how to work with Git, we recommend you clone this repository, create a copy of the RFC template in the `/rfcs` directory, and submit a PR. If you are not familiar with Git, we recommend you follow the steps below:
- Be respectful and constructive in your communication.
- Clearly articulate your proposals and feedback.
- Engage in discussions with an open mind.
- **Informal Discussions**: Before submitting an RFC, you may want to discuss your idea informally. Join us on our [Discord](https://discord.com/invite/ktMAKGBnBs) for preliminary discussions and feedback from the community.

1. Sign into or create a GitHub account. Then, navigate to [https://github.com/meshtastic/rfcs](https://github.com/meshtastic/rfcs).
## Applicability

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
Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Member

@garthvh garthvh Mar 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Required seems strong for a process that has never even been used.


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:
Copy link
Contributor

@thebentern thebentern Feb 19, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree here, the introduces new features is too broad. How do we define what significant means? Anyone have ideas?

Copy link
Member

@mc-hamster mc-hamster Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I agree here, the introduces new features is too broad. How do we define what significant means? Anyone have ideas?

Non-backward compatible?

Copy link
Author

@tekstrand tekstrand Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

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

Copy link
Contributor

@thebentern thebentern Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

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.

Copy link
Author

@tekstrand tekstrand Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


1. Fill in the template with your proposal. Be sure to include a descriptive title and summary, as well as a detailed description of your proposal. Once you are done, copy the title and high-level description of your proposal. You will need this in the next step.
- Changes to the core architecture
- Introduction of new dependencies
- Major UI/UX changes
- Changes affecting backward compatibility
- Significant performance optimizations

1. When you are finished, click "Commit Changes" at the top of the page. Enter the title and description from the last step into the appropriate fields. Then, click "Propose changes." This will create a new Pull Request (PR) for your proposal.
### When an RFC is _Encouraged_

1. Congratulations! You have successfully submitted an RFC. Now, you can engage in the discussion about your proposal. You can view your PR by navigating to the pull requests tab here: [https://github.com/meshtastic/rfcs/pulls](https://github.com/meshtastic/rfcs/pulls)
An RFC is encouraged for any initiative where someone or a group of someones wishes to benefit from the collective wisdom and experience of the Meshtastic community, but are **not subject to the rules below**.

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
Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, loosely held opinion by me. What would you all like to see here?


> **Note:** If you followed the steps to edit your proposal in the GitHub web interface, you can skip this step! Your proposal is already submitted as a PR.
Minor changes that do not broadly impact the project's functionality or user experience may not require an RFC. This includes:

1. **Participate in the Discussion**: Engage with the community and project maintainers in the PR discussion. This is where your proposal will be reviewed, and feedback will be provided.
- Bug fixes
- Minor feature changes that do not alter key functionality
- Minor UI/UX adjustments that do not alter the overall design
- Documentation updates

1. **Finalizing the RFC**: The discussion period will remain open until the RFC is deemed complete. Upon completion, the PR will be closed. Note that closing the PR does not necessarily mean the RFC is approved; it signifies the end of the discussion phase.
## Timeline

## Community Participation
The typical timeline for an RFC process, which is a minimum of 3 weeks, is as follows:

We highly encourage community involvement in the RFC process. Whether you're proposing an RFC or contributing to the discussion of someone else's, your input is valuable.
1. **Proposal Submission**: The RFC is submitted to the repository and made available for public comment.
1. **Discussion Period**: A minimum of 2 weeks is allocated for community discussion and feedback. This period may be extended based on the complexity of the RFC or the volume of feedback received.
1. **Revision Period**: (optional) Up to 1 week for the proposer to incorporate feedback and make necessary revisions to the RFC.
1. **Final Decision**: Within 1 week after the revision period or discussion period, a decision will be made regarding the RFC's implementation.

- **Informal Discussions**: Before submitting an RFC, you may want to discuss your idea informally. Join us on our [Discord](https://discord.com/invite/ktMAKGBnBs) for preliminary discussions and feedback from the community.
## Decision Making
### Handling Open Questions

## Contribution Guidelines
If open questions remain as the discussion timeline concludes:

While contributing to the Meshtastic RFC repository, please adhere to our community standards and guidelines. These are in place to ensure a productive and respectful environment for collaboration.
- The RFC proposer, in collaboration with core contributors, will assess whether additional information or revisions are needed to address these questions.
- If consensus cannot be reached within the allotted time, the decision will be escalated to the Meshtastic administrators for review.

- Be respectful and constructive in your communication.
- Clearly articulate your proposals and feedback.
- Engage in discussions with an open mind.
### Approval Process

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
Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I have no idea here. Is core contributor even the right word? Maintainer? Something else? We need to define what/who they are.

Copy link
Contributor

@thebentern thebentern Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like maintainer, because to me a maintainer feels like it conveys more of a sense of stewardship of the project.

Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that. How do we define who that is, objectively?

- 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.
Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we need to define admins, or point to a legal doc somewhere

Copy link
Contributor

@thebentern thebentern Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@tekstrand tekstrand Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Member

@mc-hamster mc-hamster Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@mc-hamster mc-hamster Feb 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this sort of guide is overdue. @ajmcquilkin has been talking about growing the sense of so things projects can persist.

Copy link
Author

@tekstrand tekstrand Feb 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, if we go with Maintainer how do we define who these people are?


## How to Make an RFC
Please refer to the [CONTRIBUTION.md](CONTRIBUTION.md) file for detailed instructions on how to submit an RFC.

## Questions and Contact

Expand Down