Hello!
I'm relatively new to the community and I've noticed that design documents get shared in the form of Google Docs. I've been wondering what the particular reasons for that might be (if any), e.g. zero or more of the following:
I've been looking at the Rust, Python, Ethereum and Bitcoin communities (links below) and was wondering what the Roc community thinks about transitioning to Roc Enhancement Proposals (REPs), where REP documents could be "first-class citizens", GitHub-wise and (cross-)referencing and comments would be much more streamlined, whilst all benefits that GitHub brings could result in a much more systematic process.
I've put together a minimal proof-of-concept here: https://github.com/hristog/roc-reps. Please, note that the focus isn't on the language and license - naturally, those must be refined as a result of community discussions and efforts.
If this is viewed as a potentially useful addition by the community, ideally, a REP repository should live under the Roc organisation on GitHub. A nice bonus thing is that the accompanying static site could be generated in Roc :rocket:
Further, I would be happy to volunteer to contribute further in this direction, to whatever extent is necessary, e.g.:
.md format and REP guidelines (; alternatively, the authors could perform the updates themselves);Last but not least, It feels to me this is something that @Richard Feldman would be particularly interested in, as (if I remember correctly from podcasts/interviews) one of his key focus areas is the (future-)contributor-facing aspects of the Roc community.
References:
so for right now the process is intentionally lightweight - there's more info about it at https://www.roc-lang.org/community#ideas
as far as Google Docs vs alternatives, honestly I just tend to write in it because it's convenient to write in...I like the idea of storing the markdown files somewhere at some point though!
but for now, "write something down and talk about it on Zulip" feels like the most streamlined system for the current size of the community :big_smile:
Yeah, that does make perfect sense - thanks for confirming, @Richard Feldman!
And I also have to apologise because I'd missed that particular section of the "Community" page on the website.
I'll close the thread as done.
Hristo has marked this topic as resolved.
oh no need to apologize! I'm happy to talk about it, and there's a lot of information on the website - there's no expectation that everyone will have read all of it! :big_smile:
and btw welcome to the community! :wave:
Thank you!
One thing I forgot to mention - even if a more systematic process doesn't get introduced at the present stage, it feels to me there could be benefit in at least maintaining an index of (Google Doc) proposals, if such doesn't exist already.
The only way I was able to discover proposal docs was coincidentally, as I was exploring and familiarising myself with past discussions here on ZulipChat.
I think a further benefit an index could provide is serving as a record of design decisions and making it easier to refer new community members to such decisions, in response to potential queries, involving why a certain decision was made, or why a feature X has been decided to not be introduced. On a related note, I've found the existing documentation to be serving as a great reference point for the latter type of questions, but I also do appreciate that it cannot be updated continuously to refer to every single decision and argument in favour or against a certain language feature/characteristic.
This is specifically thinking about accepted ideas:
On top of this, it can be semi common for ideas/projects to get filed away as eventual todos, but with no real tracking. Given there are so many GitHub issues now, we may want a better way to organize these from a contributor standpoint.
At a minimum, all of them should be tracked in GitHub somehow. Better yet, we should somehow group them in github. Maybe just a label. Maybe a smarter grouping or projects or roadmap. Eventually Zulip threads become lost in the weeds but many will reference things we definitely want added. Many of those are great first issues or intermediate projects if they just get documented well and presented to interested contributors.
I think a more concrete process around ensuring tracking of accepted ideas would be a good idea. Especially for small builtin changes that haven't been gotten to but would be a good first issue.
Yes, usually, some combination of labels and grouping by projects and managing a Kanban board of sorts is what I've seen in practice.
The latter, however, comes with a huge caveat - I haven't looked into a ton of open-source projects, but I've looked into at least a few, and in my experience (the following is the caveat), the contributor-facing Kanban boards aren't and can't realistically be kept up-to-date, in order for them to be of any practical use to the average contributor, who isn't familiar with more specific details about current priorities etc.
This, I think, is also - at least to some extent - due to the fact that refining such boards can be a very time-consuming task, cumulatively speaking; and also, I imagine, the stability of open-source "roadmaps" probably varies wildly from project to project.
Just for reference, I've been trying to maintain the accepted larger proposals on roc awesome, any assistance would be most appreciated.
And we have the plans
Happy to give a hand if/when necessary, @Luke Boswell!
What kind of assistance have you got in mind? Generally monitoring topics here and other sources of contributions to the ecosystem and submitting PRs to your roc-awesome repo?
Yeah, PRs with any ideas or updates most welcome
Last updated: Jun 16 2026 at 16:19 UTC