Thanks, haven't seen it before, but love the idea of it. It certainly takes the concept a lot futher that I intended with this project. My goal is far is to relyt on well-supported open source tools and frameworks, and give both the software and hardware flexibility for people to create what they need. Think of it like FlipperZero, but for outdoors
Unfortunately it means there's no fancy CRDT system: no multiplayer edits for example.
I haven't looked into webhooks yet or browser notifications. That's all stuff that I would build when left to my own devices but I want more user feedback on basic functionality.
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:
> 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.
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.
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.
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.
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.
I suppose this is the kind of thing that would be handled by a separate RFC but I hope that browsers will be allowed to send QUERY requests via HTML <form> elements since traditionally they can only send GET and POST.
I did originally plan for every company to be able to configure their own XYZ prefix (there's a vestibule of this that you can see here by replacing `rfc` with any arbitrary acronym like `XYZ`):
The overall namespace is the org slug (`rfchub` in this case) so I was going to allow different orgs to choose the same prefix (defaulting to `RFC`). In that respect the actual globally unique identifier for this proposal is `rfchub/rfc1`. But I need to figure out some bigger features first before I add that.
It's also a reason I still use Firefox based browsers instead of chromium based browsers.
reply