[HN Gopher] Show HN: RFC Hub
___________________________________________________________________
Show HN: RFC Hub
I've worked at several companies during the past two decades and I
kept encountering the same issues with internal technical
proposals: - Authors would change a spec after I started writing
code - It's hard to find what proposals would benefit from my
review - It's hard to find the right person to review my proposals
- It's not always obvious if a proposal has reached consensus (e.g.
buried comments) - I'm not notified if a proposal I approved is
now ready to be worked on And that's just scratching the surface.
The most popular solutions (like Notion or Google Drive + Docs)
mostly lack semantics. For example it's easy as a human to see a
table in a document with rows representing reviewers and a checkbox
representing review acceptance but it's hard to formally extract
meaning and prevent a document from "being published" when criteria
isn't met. RFC Hub aims to solve these issues by building an easy
to use interface around all the metadata associated with technical
proposals instead of containing it textually within the document
itself. The project is still under heavy development as I work on
it most nights and weekends. The next big feature I'm planning is
proposal templates and the ability to refer to documents as
something other than RFCs (Request for Comments). E.g. a company
might have a UIRFC for GUI work (User Interface RFCs), a DBADR
(Database Architecture Decision Record), etc. And while there's a
built-in notification system I'm still working on a Slack
integration. Auth works by sending tokens via email but of course
RFC Hub needs Google auth. Please let me know what you think!
Author : tlhunter
Score : 13 points
Date : 2025-12-01 17:04 UTC (5 hours ago)
(HTM) web link (rfchub.app)
(TXT) w3m dump (rfchub.app)
| samuelstros wrote:
| Initial reaction: Looks too complicated & too niche of a problem
| to appeal to a sustainably large user group.
|
| GDocs might be annoying to track who read the RFC etc. etc. but
| everyone is familiar with it.
|
| I write RFCs, I share RFCs and your tool seems to require a
| substantial amount of buy in
|
| - register
|
| - unclear what the writing experience is
|
| - outdated / overloaded UI
|
| The last RFC I wrote was in hackmd (https://hackmd.io/Jjy-
| afCWS4CAFlHa62anMQ) because
|
| - I wanted Markdown to store the RFC in git eventually
|
| - Google Docs has issues with Markdown rouundtrips
|
| - I didn't want to use git to write with VSCode (although... I
| actually did. I let CLaude Code write most of the RFC under my
| guidance, then put it into hackmd for easy sharing)
|
| I hope the feedback helps!
| tlhunter wrote:
| Thanks for the feedback!
|
| I agree that the UI is dated and can be a little overwhelming.
| The sample RFC (https://rfchub.app/rfchub/rfc1-org-batch-
| markdown-exporter-j...) shows what a proposal looks like with
| every single feature being used. Most of the time they'll look
| a bit simpler. I have a big UI overhaul planned but I'm hoping
| to get more real usage feedback on the core functionality
| first.
|
| FWIW the editing process does use markdown, and the "download"
| link in the sidebar downloads a markdown file with YAML
| frontmatter to avoid vendor lock-in. RFC Hub has so much
| functionality that it's difficult to explain it all on the
| homepage. There is this overview document but it's honestly
| just overwhelming:
|
| https://rfchub.app/blog/an-overview-of-rfc-hub
| samuelstros wrote:
| > RFC Hub has so much functionality that it's difficult to
| explain it all on the homepage
|
| That's what I meant with overwhelming / too niche.
|
| It seems like you intend to productize the RFC process e2e.
| But most "time consuming" parts of an RFC process is the
| human stuff "Did you read this?" "Did you update the RFC
| again?" etc. That back-and-forth seems to be expressed by all
| the features you have in RFC Hub but:
|
| 1. That makes RFC hub complicated.
|
| 2. Requires buy-in from every party to participate in all of
| RFC hubs feature like "Yes, I reviewed it and pressed the
| reviewed button in RFC Hub"
|
| 1 & 2 combined make RFC Hub (likely) a very niche product.
| New users are overwhelmed. Existing users need to onboard new
| users (their collegues) though. Otherwise, the RFC process
| will fallback to just DMs on Slack. Only a few teams will
| have sufficient buy in from all team members.
| tlhunter wrote:
| I agree that adoption will likely be difficult. Basically
| the larger the engineering org the greater the benefit. If
| a company only has a few proposals a year then RFC Hub is
| mostly just friction.
|
| I've worked at a few companies with thousands of engineers
| and where I've had to review hundreds of proposals. That's
| where the product really shines. Of course I do want it to
| be useful to smaller orgs as well. Adding Google auth
| should help reduce signup friction.
|
| As another person on here put it, RFC Hub will benefit from
| automated importing of proposals. To be maximally
| beneficial all engineers at a company need to have an
| account and all RFCs need to be in RFC Hub. It almost
| requires a top down mandate which is bad. I do hope to make
| it incrementally beneficial for smaller teams.
| anitil wrote:
| This would have been very useful at my previous job. We had a
| gdrive folder with '2024' or '2025' with a bunch of google docs
| with no inter-linking between them. If you were lucky the title
| would be vaguely related to the topic you are working on, and
| maaaaaybe there'd be a link to prior work. Frequently I'd look at
| an RFC, see no approvals but then find out it _had_ been approved
| but nobody actually updated the document. Infurating.
|
| I'm not sure the reason for friction. These are developers, they
| know how to use git etc, but management prefers google docs I
| suppose (previous iterations were confluence, then markdown on
| github).
| tlhunter wrote:
| I'm glad to hear you would have found it beneficial!
|
| I've definitely seen the same patterns at companies (and even
| introduced similar patterns).
|
| The proposal linking was inspired both by IETF RFCs and by Jira
| issues. I love how both systems provide semantic meanings to
| such links (X obsoletes Y).
|
| I do hope to marry the engineering love of markdown with
| management's love of WYSIWYG. Currently the proposal editing
| process is done via a syntax-highlighted markdown editor but in
| the future I'll add a WYSIWYG editor, then let users select a
| default mode.
| anitil wrote:
| To be honest (and I'm just some rando so feel free to ignore
| me), if you have an MVP I'd say forget about development and
| sell what you have. You're already better than what I've seen
| in industry. If anything, being able to take an existing
| decision database and onboard it to RFC Hub (even if done
| manually) would be a better sell than WYSIWYG to enterprise
| customers.
___________________________________________________________________
(page generated 2025-12-01 23:00 UTC)