Hannes (Mar 02 2023 at 02:13): Hannes (Mar 02 2023 at 02:13):Hi everyone, I've wanted to get involved in contributing to Roc recently, but I'm not a compiler dev, so instead I wanted to contribute some tooling/peripheral stuff for Roc. Things like pre-commit hooks, a github action to install Roc, maybe a Docker image, stuff that I don't think the core team would be interested in maintaining.
I've made a Roc-Community organisation on GitHub (https://github.com/roc-community/) to house these kinds of projects and to hopefully attract some more contributors, but I realised I should check in here to make sure the core Roc team (and particularly @Richard Feldman) are okay with that. I don't want anyone thinking, for example that if they pull a Docker image from roc-community that they're getting an officially endorsed image, or if they have a problem with the tools that they should contact/blame the Roc developers.
If anyone is unhappy with this, I can delete/deactivate the organisation and put these kinds of projects on my own GitHub account instead. Thanks :)
Luke Boswell (Mar 02 2023 at 02:50):Im interested to explore ideas in this direction. It might be helpful to write up a bit of a proposal with more specific details? Are you thinking things like packages? or more like core compiler work? Maybe a brainstorming discussion to consider different things. I've had similar ideas but coming from a different direction. I was trying to think about intended use cases and possible future interest groups and how to identify and meet thier needs. Like a teacher using roc to teach programming, verse an embedded engineer using roc for a controller etc. Always up for a chat if that would help. :grinning:
Hannes (Mar 02 2023 at 03:38):Hi Luke, thanks for your interest. I can share the notes with ideas I've taken over the last few days, but they're pretty raw, I'm interested in hearing if any of them seem like they would be useful to work on.
Like I said, I'm not a compiler developer, so I don't plan to contribute to the compiler much :sweat_smile:
In terms of packages, I was thinking about eventually trying to build some basic packages like datetimes and regular expressions, the kinds of things that are in the stdlib of more batteries-included languages, but those were more long-term goals.
I'm coming from the Julia world, where the community has organised itself into organisations like JuliaDocs which manages the documentation generator packages and JuliaActions which manages CI configurations. These organisations are unofficial in that they don't get official support by the Julia team, but they're de-facto standards and are used by the core team, e.g. the official Julia documentation is generated by the Documenter.jl package, rather than something in the stdlib. I wasn't expecting any of the core developers to use anything in the roc-community organisation, but just to have an organisation name attached to the projects that let people know they were a community effort, rather than one person's work.
Hannes (Mar 02 2023 at 03:39):Here's the ideas I've collected in a very raw form:
Roc Community Ideas
Brendan Hansknecht (Mar 02 2023 at 05:08):Lots of fun stuff. This seems like a cool idea overall with tons of projects to learn with and help push the community forward.
Brendan Hansknecht (Mar 02 2023 at 05:09):Not sure about organization naming but overall seems like lots of great stuff to invest more into.
Brian Carroll (Mar 02 2023 at 05:25):Yeah this is great stuff to work on. I can't comment on the organisation name etc, Richard and Anton know more about that side of things.
Brian Carroll (Mar 02 2023 at 05:26):From your notes:
a serde kinda library
is this even possible without macros or similar?
We have a new language feature, implemented in the past year, called Abilities! Implementing something like serde was one of the big motivations for it. It's not well documented yet but there's an Encoding ability and a Decoding ability, and they are used in Json.roc in the repo.
Hannes (Mar 02 2023 at 05:29):@Brian Carroll Cool! I've heard of abilities but I also saw they're not documented yet, so I haven't looked into them at all so far :)
Luke Boswell (Mar 02 2023 at 05:58):I posted an example using a JSON URL package recently if you're interested to see it in action zulip thread
Richard Feldman (Mar 02 2023 at 12:38):hi @Hannes, and welcome! :smiley:
Richard Feldman (Mar 02 2023 at 12:40):I appreciate the question about organization/repo naming - honestly I agree with Evan that elm-community ended up not working out the way we'd hoped, so I personally wouldn't be in favor of having a roc-community org or repo
Richard Feldman (Mar 02 2023 at 12:41):Hannes said:
I'm not a compiler dev, so instead I wanted to contribute some tooling/peripheral stuff for Roc. Things like pre-commit hooks, a github action to install Roc, maybe a Docker image, stuff that I don't think the core team would be interested in maintaining.
this is really awesome to hear, because Roc could really use these things! :smiley:
Richard Feldman (Mar 02 2023 at 12:42):one thing that would be immediately useful is a GitHub action to publish platforms
Richard Feldman (Mar 02 2023 at 12:44):for example, let's say I want to do a release of https://github.com/roc-lang/basic-cli - I have to do a build of its low-level implementation for:
...and possibly more, if I want to support more than that.
then, afterwards, I need to take all of those compiled binaries and put them all together in a tarball so Roc application authors can install it from one convenient URL
Richard Feldman (Mar 02 2023 at 12:45):a GitHub action to reduce all of those steps into one step (and which could run on all the different necessary operating systems) would be really helpful, not just for basic-cli today, but for platform authors in general in the future!
dank (Mar 02 2023 at 12:57):Richard Feldman said:
I appreciate the question about organization/repo naming - honestly I agree with Evan that
elm-communityended up not working out the way we'd hoped, so I personally wouldn't be in favor of having aroc-communityorg or repo
out of the loop i guess but what happened with elm-community?
the only community driven gh org I know is https://github.com/nix-community and well seems that they're doing pretty good? idk maybe it's different in lang-space
Richard Feldman (Mar 02 2023 at 13:41):more context here: https://elmlang.slack.com/archives/C0NLYJWSZ/p1673439727608069
Richard Feldman (Mar 02 2023 at 13:54):tl;dr
elm-community in practice created a misperception of reputation - e.g. if you see someone/csv, and elm-community/csv, you might think "ok, I don't know who someone is, but I trust the Elm community, so I'll go with the elm-community CSV library." But for all you know, elm-community/csv is actually made by the same someone, or maybe it's a different author but they didn't do as good a job as someone did. In either case, it's a community member making the package, but one of the community members gets a special reputational bonus just for getting their package moved into the elm-community repo, even though there isn't any special vetting process to ensure quality in there. (And I don't think a special vetting process would have been the solution here either.)elm-community and let others take it over), over the years there have been several instances of "this elm-community package used by lots of people isn't maintained anymore; will anyone volunteer to take it over?" - as opposed to the usual process of "if a package I use isn't maintained anymore, I can fork it under my own username and continue in the direction I think makes sense"elm-community packages can end up being taken over by whoever happens to volunteer, but as a user of the package, you don't have any way to tell that the package is now under completely new ownership (because the org didn't change; it was the same before and after) and future releases might not be what you've come to expect from the current author(s) Richard Feldman (Mar 02 2023 at 13:56):so overall, it seems best not to have a special org/repo whose name suggests it represents The Community; I think it's better if all community members are publishing on an equal playing field, and nobody's package gets a reputational bump by getting into the official-sounding repo :big_smile:
Richard Feldman (Mar 02 2023 at 13:57):that said, I do think there's a separate case of packages being moved into the roc-lang/ org, which to me means "the people making Roc are collectively taking responsibility for actively maintaining this" - and in that case it's appropriate for the package to take on the reputation of the Roc organization as a whole...because that is indeed who is maintaining it!
Hannes (Mar 02 2023 at 14:43):Thanks for replying with your thoughts Richard, this is the exact kind of thing I was thinking of when I made the organisation. I won't use the organisation and instead put these kinds of projects in my own account. :+1:
Coming from the Julia world these kinds of community projects have worked really well there, so it felt natural to me to make one for Roc. I'm trying to think about why the system has worked so well in Julia but seemingly not in the Elm community (not having used Elm before). I think some of it is specific to the Julia language where multiple dispatch encourages a few small libraries that define common interfaces like Tables.jl which is the interface used by basically all rectangular data libraries or Colors.jl which basically every package that uses colours interfaces with.
I'll look into your suggestion for a github action to publish a platform, and of course if I get any of these ideas off the ground I'll share them in #show and tell :) Anyone reading this who's interested in sharing more ideas or contributing to any of them, free to DM me and/or @Luke Boswell, we're looking to flesh out a plan for these ideas.
Richard Feldman (Mar 02 2023 at 15:04):awesome, sounds good!
Last updated: Jul 26 2025 at 12:14 UTC