Help Me Help You, Maintainers
matduggan.com
Help Me Help You, Maintainers
1–10 of 25 posts
Re: Help Me Help You, Maintainers
#2[deleted]
Re: Help Me Help You, Maintainers
#3> "We need to support open-source maintainers better!"
> "Let's have a conference to discuss how to help them!"
> "We should provide resources without adding requirements."
> "But how do we do that without more funding or time?"
> "Let's ask the maintainers what they need!"
> Maintainers: "We need more support and less pressure!"
> "Great! We'll discuss this at the next conference!"
> "We need to support open-source maintainers better!"
Maybe some maintainers should be invited to these conferences? And maybe more direct communication with the projects you want to contribute to? I get the impression from the article that these conferences the author describes are more virtue signalling than an attempt to solve the issue.
I do think that advice at the end of the article is useful, but the opening makes me feel that no one's actually having a conversation with maintainers.
Re: Help Me Help You, Maintainers
#4> "We need to support open-source maintainers better!" > "Let's have a conference to discuss how to help them!" > "We should provide resources without adding requirements." > "But how do we do that without more funding or time?" > "Let's ask the maintainers what they need!" > Maintainers: "We need more support and less pressure!" > "Great! We'll discuss this at the next conference!" > "We need to support open-source…
The list at the end isn't that good though. It's basically dictating this Matt Dugan's preferences. The third one about seven systems is both an exaggeration and a demand.
The rest of this page makes me think it would be really hard to work with Matt, and I'd probably just pass back when I was running projects. It's not worth the effort.
Re: Help Me Help You, Maintainers
#5Two things to think about:
One, as the article points out, supporting Maintainers is important.
Two, many software engineers don't enjoy writing documentation. Even if it would make their lives easier.
From that perspective, the majority of these complaints revolve around communication. However, this article frames documentation as something only the maintainer should write.
Why not make a PR to update the documentation yourself instead of asking the maintainer to do it?
Instead of getting frustrated about opening a bug in the wrong place, why not document the right place?
If the description around PR criteria doesn't match your experience, why not create a PR updating it to include undocumented requirements?
Re: Help Me Help You, Maintainers
#6[dead]
Re: Help Me Help You, Maintainers
#7As the maintainer of several popular open source projects (e.g. https://chezmoi.io), the forms of help I appreciate the most are:
* User support. Answering questions in discussions, social media, and GitHub issues. This helps on multiple levels: it saves me time that I would otherwise have to spend, and builds a community around the project.
* Documentation improvements. Better documentation means less user support work and helps everybody.
* Issue reports with a clear, minimal, way to reproduce the problem.
* Pull requests that follow the contributing guidelines of the project. This means that they follow the project's conventions, include tests, don't break any existing tests, and so on.
I don't write open source software to make money. I write open source software because I enjoy building high-quality software and I get a buzz from helping people.
Re: Help Me Help You, Maintainers
#8> "We need to support open-source maintainers better!" > "Let's have a conference to discuss how to help them!" > "We should provide resources without adding requirements." > "But how do we do that without more funding or time?" > "Let's ask the maintainers what they need!" > Maintainers: "We need more support and less pressure!" > "Great! We'll discuss this at the next conference!" > "We need to support open-source…
The list at the end isn't that good though. It's basically dictating this Matt Dugan's preferences. The third one about seven systems is both an exaggeration and a demand. The rest of this page makes me think it would be really hard to work with Matt, and I'd probably just pass back when I was running projects. It's not worth the effort.
>The third one about seven systems is both an exaggeration and a demand.
I don't know how many times in the post they say some variation of "it's your stuff, do whatever you want", but it's certainly more than once. While they didn't explicitly say it (again) in this particular sentence, "do what you want" is repeated enough times throughout the page that it's pretty clear that nothing on this page is a "demand".
"You provide an amazing service and I want to help. But part of helping is I need to understand what is it that you would like me to do."
Is a pretty reasonable take. I don't know how that translates to "really hard to work with", but, in their own words: "It's your project, you are welcome to do with it whatever you want".
Re: Help Me Help You, Maintainers
#9> "We need to support open-source maintainers better!" > "Let's have a conference to discuss how to help them!" > "We should provide resources without adding requirements." > "But how do we do that without more funding or time?" > "Let's ask the maintainers what they need!" > Maintainers: "We need more support and less pressure!" > "Great! We'll discuss this at the next conference!" > "We need to support open-source…
The list at the end isn't that good though. It's basically dictating this Matt Dugan's preferences. The third one about seven systems is both an exaggeration and a demand. The rest of this page makes me think it would be really hard to work with Matt, and I'd probably just pass back when I was running projects. It's not worth the effort.
Other than the one about using only one platform, which you referenced, it seems like he's really just asking for clarity from maintainers about what contributions they would like, and how they would like them to be provided.
What items on the list do you think are just the author's preferences, but other potential contributors wouldn't like? It seems unlikely that contributors would prefer NOT to know if the maintainer doesn't want PRs, or would prefer NOT to have an example of how to contribute, e.g.
Re: Help Me Help You, Maintainers
#10I had the misfortune to yet again interact with the world of FOSS today. This is how it panned out:
1. Heard that something called Rustdesk is a good VNC solution.
2. Installed it on my host and client devices fine. The client is an Android tablet
3. Finger touch input works, but stylus input doesn't work.
4. Search the internet and find the GitHub issue
5. In it the developers at Rustdesk have responded "Fund it if you really need this feature."
6. Cool, I'll put in $18 and hope that they fix this issue. It's a shame that there's no guarantee whatsoever or timeline, but I'll put my money where my mouth is.
7. ERROR! MINIMUM DONATION $20!
8. Give up. Why did I give the sewage world of FOSS another chance?
As a counter example:
The other day I had a bug in a paid software I've been using for years, that cost me less than $100. Mailed the company, and a few hours later the developers sent me a new executable with the bug fixed. The next day they released an update for every user with the bug fixed.