←back to thread

Show HN: RFC Hub

(rfchub.app)
30 points tlhunter | 2 comments | 01 Dec 25 17:04 UTC | HN request time: 0.001s | source

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!

Show context
anitil ◴[01 Dec 25 21:34 UTC] No.46113552[source]▶
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).

replies(1): >>46113758 #
tlhunter ◴[01 Dec 25 21:49 UTC] No.46113758[source]▶
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.

replies(1): >>46114052 #
1. anitil ◴[01 Dec 25 22:15 UTC] No.46114052[source]▶
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.
replies(1): >>46130639 #
2. tlhunter ◴[03 Dec 25 05:35 UTC] No.46130639[source]▶
Great ideas!

You convinced me tonight to implement a feature: pasting content from Google Docs now gets converted into markdown. For example bold becomes *bold*, heading 1 becomes # Heading. It'll even find monospace fonts in a paragraph and add `code` ticks or monospace on dedicated lines and convert into ```code blocks```.

Faster automation would of course be nicer, e.g. providing a Google Drive directory and slurping all of the docs up, but that'll take a bit more time.