Comment by samuelstros

Comment by samuelstros 2 days ago

3 replies

View on Hacker News

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 2 days ago

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

Reply View 2 replies
  • samuelstros 2 days ago

    > 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.

    Reply View 1 reply
    • tlhunter 2 days ago

      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.

      Reply View 0 replies