On Friday we had our first contributor meetup. Thirteen folks showed up to a zoom call to discuss how to contribute to Dark.
Obviously, the point of the conversation was to get to know each other. We're all hanging out in the #contributors channel, but the room isn't super chatty so talking in person (or whatever counts for in-person on Zoom) is helpful to get to know one another.
One of the big topics was how to do bigger projects. Most folks had fixed some small bugs or added some tests, and were quite interested to contribute bigger features that would solve problems that were annoying them.
The first of these was GraphQL. Folks wanted to be able to easily create GraphQL backends in Dark, which is obviously a great idea. I hope that folks will be able to create Dark backends using any protocol that makes sense to them, like GraphQL, gRPC, Thrift, etc, in addition to the REST APIs they can build now.
So what's the blocker here? Well, there's probably two. First, we need to design this; we need to figure out what GraphQL means in the Dark world. My instinct is that it's tied to types (which don't properly exist yet), and to DBs (which should use types but use schemas instead right now). But I'm not expert in GraphQL, and have never really used it beyond "hello world" apps, which means that making a really good GraphQL design for Dark is something that someone else would need to do.
Secondly, there is a lot on my plate right now, and GraphQL isn't near the top. So for this to happen, someone else needs to drive it. I certainly have the bandwidth to help someone drive this if they're interested (and a few people in the call certainly were, both for GraphQL and the other things I mention here), but I only have so much space in my head for things I'm personally driving.
I think this basically counts for most things in Dark: if someone steps forward to design something and drive it forward, there's a lot of latitude to do so, and I'm willing to put in the time to help.
We also discussed expanding the language. There's quite a few language features in the issue tracker already, and there's probably a need to add more. Dark needs tuples, enums, a type checker, characters, statements, refs, polymorphic types, more patterns to match, and string interpolation. We also currently have our Dictionaries and Records as a single concept, which is obviously (and predictably) bad.
This brings up an interesting question: how to trade off people's interest in contributing with the existing Dark vision. The Dark language is pretty much designed, though it is far from complete.
While that's not true for other parts of the platform, it is the case that there is a high-level vision for Dark (which is not necessarily well-articulated) which each new feature needs to fit into. Working with contributors to design new features will likely help expose that vision, so that's a great place to spend time.
The final area we discussed contributions was around Datastores: folks wanted to add default values for schemas, and build DB migrations, both of which are very valuable. They are blocked by an awkward step though: Datastores have schemas, but they should be specified using types instead.
Contributing with other skillsets
Something else that came up was about contributing if you don't want to write OCaml/ReasonML. While there are existing docs about contributing in other languages or other ways, folks were also interested in helping spread Dark by writing about it, helping it spread, and other kinds of "content marketing". All of which is very welcome!
Next contributor meeting
Folks seemed excited to meet every 2-3 weeks, though people asked to move it a bit later (7am is early for US west coast folks) and to do it on a weekend. The weekend-vs-weekday thing is a bit tricky: we want to be inclusive to folks who are using Dark for work and don't have time on weekends, but also to people who aren't using Dark for work and can't take time during the workday. So we'll maybe try alternating. The next one is Saturday, August 8th.