The Forem team recently changed its engineering processes at the start of the new year. These changes also impact the Forem open source community, too. This post highlights some of those changes, and details the rationale behind why we are trying to adopt a new process.
The Internal RFC Process at Forem
Many changes to the Forem platform can be implemented and reviewed using the standard GitHub pull request workflow. However, some changes are far more substantial and require more thought and detail.
In an effort to streamline our product and engineering workflow, the Forem team recently started using an internal RFC process (βRFCβ stands for βrequest for commentsβ). This process is intended to provide a consistent and standardized path for new changes to enter the Forem ecosystem.
It demands more rigor and up-front design, but helps us ensure consensus across the Forem team before any significant changes are implemented.
The RFC process will be used whenever a change involves adding or removing a feature, as well as other substantial changes made to the codebase. It will not be used for smaller, more straightforward changes (like patches, optimizations, or refactorings).
Once we have refined our (very new!) internal RFC process, we hope to make it public and open to the community in the interest of transparency.
For now, weβd like to share some of the ways that this new process will impact our Forem repository and open source workflow.
Feature Request Changes
OSS Manager
As the OSS Manager, I will be looking for repeat feature requests raised by our OSS community. When I see a common theme or feature requests that I feel are particularly important, I will convert these requests into a RFC, which will be reviewed by our internal team as a part of our process.
Going forward you may see many older feature requests closed in our repository or labeled as potential RFC
.
Potential RFC Label
Some of the open issues in our repository may have the potential RFC
label added to them. This label is used to highlight features or issues that we think would make a great RFC for a Forem team member to champion.
Closing Older Feature Requests
Because of the new RFC process, we would love for people to head over to forem.dev for feature requests that warrant more discussion.
Feature requests that have been open over a year without much traction will be closed to help with the health of our repository. This will also ensure that our team can devote time to the features that the majority of our community members would find useful.
If you would like us to champion any feature requests on your behalf, please put them in forem.dev
Why forem.dev?
As a team, we debated whether we should use Github Discussions or stick with our own platform at forem.dev.
Here are some of the reasons we decided to use forem.dev for discussions:
- While sticking with Github would be much easier for our technical contributors, forem.dev is more friendly for users or creators who are nontechnical to bring up discussions and create feature requests.
- Unlike many open source projects where the entire community is technical, the Forem community is made up of an interesting intersection of technical contributors (coders who live in Github) and non-technical "contributors" in the sense of feature suggestions (non-coders who may have never used Github).
We're excited to use forem.dev to help support the entire Forem community, from the technical coders who joined us on DEV, to the younger Forem communities who are newer to the Forem ecosystem. We look forward to having fruitful, engaging conversations with you, and hope you'll use the forem.dev platform to share your ideas for our platform. See you online!
Cover Photo by Ross Findon on Unsplash
Top comments (0)