been thinking about my approach to saying critical things about open source projects
I'm always trying to balance 2 things:
1. I want other users to know that if they're struggling, it's not because they're dumb. There are real problems.
2. I don't want to downplay the work people are doing to make it better.
this has been coming up a lot with Nix, which I find useful but incredibly difficult to use
(no advice please, but curious to hear what your personal approach to this is)
(1/?)
in general my approach to criticism is to try to stick as closely as possible to Facts About My Personal Experience, like:
1. here's a problem I ran into
2. this is why I found it frustrating
3. here's a possible solution
4. here are some questions / unresolved problems I still have
I try to avoid:
* broad judgements (“this is designed badly because of X”)
* speculation ("this is because the devs don't care about X")
(2/?)
@b0rk it's kinda hard to follow this advice when the problem is "there is no consistent model how this should work": any single problem you have can be fixed by one more epicycle it by just knowing about this one more piece of usually helpful magic. (Examples that I encountered recently: systemd-resolved and choosing which interface to use for a request, nix flakes' treating top level of flakes specially.)
@robryk I think that's very easily framed as a story about your personal experience (“I've run into dozens of problems and fixed them but I haven't been able to come up with any mental model of how the system works, it always feels like magic”)
it's hard for someone to take action on by itself but I think it's a very fair criticism