I’ve struggled a bit with the Frontend RFC process. Maybe I’m approaching it the wrong way, but there are several challenges with the current approach from my perspective:
- Using unmerged PRs makes it hard to see the proposal itself.
- The default view is discussion about the PR and not the proposal itself
- Navigating to the proposal is obfuscated (e.g., click on link to proposal repo if you know where to find it, click on “text” folder, click on the correct file)
- Numbering RFCs in a “text” folder is cumbersome (e.g., finding out what the “right” number to use)
- It’s not clear where to take discussion on merged RFCs
- Important discussion on design ideas is done separately from the OpenMRS Talk forum.
- There aren’t links to RFCs other than through Github file browser
Some thoughts on an alternative approach for RFCs that might address some of those challenges:
- Make default page be a list of RFCs or “table of contents”
- The overview of the RFC could be moved to a secondary page)
- PRs would include a link to themself as an update to that README page
- Drop the numbers from RFC file names so the only requirement is the “file” name be unique
- Ask PRs to include a link to themself (the actual proposal page in the source repo) in the description of the PR, so anyone browsing to the PR would see a “View the proposal” before any conversation about it.
- By convention, include a link to a Talk topic for discussion of the RFC (e.g., create a “Frontend RFC: Browser Support” labeled with “rfc” that gives an overview of the RFC and a link to review the full text of the RFC and then add the link to that Talk topic in the RFC itself… like a "Questions/concerns? Discuss on OpenMRS Talk).