I maintain a few elm libraries, and for what it’s worth, I’ll share a little perspective on that experience. I put a lot of thought and effort into guiding these libraries in a good direction, and keeping them well-maintained. And I think there are many people who will say it was a great experience when they requested a feature, asked for help on Slack, or contributed to one of my libraries. However, I’m sure there are others who feel frustrated that I didn’t get to their issue quickly enough. And of course there will always be some people who disagree with the direction of a library, so they’re unhappy with some decision.
Even though I’ve put a tremendous amount of effort into being responsive, I often fall short. I have several open issues where I haven’t responded at all, or for too long. Despite all the effort I put into staying on top of things, it’s extremely difficult to keep up, and to triage effectively.
I know that Matt is the same way with Elm UI. If you look at his recent OSS contributions, he’s doing a ton of work, and he’s constantly taking time to answer questions in the Elm slack, working on ways to make the documentation great, and making his libraries easier to use. He also has a lot of detailed discussions on issues.
I’m not excusing having open issues that don’t get responses, I’m just saying that I completely understand it, and it’s a difficult problem. I wonder if some sort of community contribution could help with this kind of thing? Maybe people could volunteer to help triage simpler issues?
All of that said, here are a few things that have worked really well for me.
What’s worked well for me
Find ways to allow people to do their part (easily)
I’ve really enjoyed the approach of trying to involve the community when someone says they have an issue (similar to the Rust approach). I recently had a bug filed that was a little subtle. So I asked the reporter to create a minimal reproduction. This required trimming down a GraphQL Schema and re-running the code generation CLI repeatedly, which is tricky if you don’t have some tooling set up to help you with that. So I invested some time in writing some docs on how to reproduce an issue (and why I ask people to do so). And I built a small script to help with the process. The script and docs live here: https://github.com/dillonkearns/elm-graphql/tree/master/reproducing-issues.
This was a big win! Fortunately, the reporter of the issue was really appreciative and willing to help, so it was a delightful interaction (on both sides, I think!). The reporter was even kind enough to give me a failing unit test case that I could use to quickly make a patch.
Interactions and attitude
The reporter’s attitude and tone can make a big difference for maintainers. In this case, the reporter was really grateful and willing to pitch in. For me, I find it really emotionally taxing when my interaction feels like it’s coming from a place of expectation, or wanting to get a feature a very specific way rather than recognizing that it’s part of a bigger vision that needs to be discussed and examined.
I’ve considered adding something to this effect in a code of conduct, but I hesitate because I want to make those things emerge through the interaction rather than needing to “police” behavior. But maybe that’s just me. The things that I’ve found really help contribute to a better atmosphere (and that I can do as a maintainer):
Have humility - Even if I “know” I’m right, I try to come from a place of curiosity. Very often, when I thought I was “right”, the humility pays off because I end up learning something that I wasn’t considering. At the very least, the interaction is a lot more pleasant that way on both sides!
State explicit core values/philosophy in README - This let’s you collaborate to find a solution that honors those principles, rather than arguing about different approaches. Instead of “X is the best solution to Y,” I try to say “Can you think of any ways to solve Y that are in line with <core philosophy point 1>?”
Ask questions to dig down to the problem - it’s very common to have XY problems in feature or bug requests. No need to “correct” anyone, though, just ask a few questions, and the conversation tends to turn towards the bigger picture.
Document knowledge when it keeps coming up
A lot of the community interactions take place on Slack. This is great in a lot of ways, but it does indeed end up with questions coming up repeatedly because it can be hard to find answers. When I find myself answering the same question more than once, I write the answer in this FAQ doc (in the case of elm-graphql), and then send a link over. This also allows me to invite people to make a PR if something was missing, or not clear enough.
Strengthening the elm community
@Lucas_Payr, I love your thoughts on how we can focus on what we have the power to do right now. I totally agree! Perhaps that FAQ technique I’ve been using for elm-graphql (documenting things when they keep coming up) could be something that we as a community could start doing? There’s a lot more to explore here, but I’ll leave it at that for now