10 ms·

I need to read through this more thoroughly, but upon a first read, I feel I pretty strongly disagree with the approach and advice but not necessarily the senti

by bmitc 4y ago

I need to read through this more thoroughly, but upon a first read, I feel I pretty strongly disagree with the approach and advice but not necessarily the sentiment. This is mainly coming from a user of open source projects who is both trying to contribute more and start projects where I'd be the maintainer. As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. Just because the maintainers do not have time to fix the issue does not mean it isn't an issue! Too many times has this happened. It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist. How many times have you found an issue only to find several issues have already been reported, not fixed, but closed due to automated bots or maintainers just blindly closing? The issue still exists, but now its history is spread across a half dozen issue reports. This complicates what the issue actually is and contributions for it. The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues. On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. They are often just open sourced personal fiefdoms. Which is honestly fine, if they are marketed as such, but they rarely are so. As I think about possibly open sourcing a personal project or two, I am thinking deeply about this. I think it's much better for expectations that if an open source project is going to be dictated by the maintainer, it should be explicitly stated so as to set expectations. Even then, I would not blindly close actual issues that are reported. Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication.

gautamdivgi 4y ago
I don’t find anything wrong with the authors approach. I just think he should make it clear that he’s not interested in issues or PRs on the project readme or contribution guide. It’s hard to have it both ways - where you say issues and PRs are welcome but say no when someone reports or makes a contribution.
- bmitc 4y ago
  I agree that making it clear is important, and I think I edited my post at the same time as your comment to say the same. However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.
  - tekla 4y ago
    > If PRs and issues truly will be ignored, then that really needs to be explicitly stated. No it doesnt. No one owes anything to you > Because otherwise, why even open source or release it? Because they can.
    - bmitc 4y ago
      Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part. > Because they can. That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default. Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach. I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.
louwrentius 4y ago
The key thing is that your frustration doesn’t entitle you to anything. The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it. The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing. For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention. But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic. “No” is a perfect antidote to that toxicity.
- bmitc 4y ago
  > The key thing is that your frustration doesn’t entitle you to anything. Well see, I never said that. However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations. > The best thing to do is to contact the maintainer first before you do the work That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations. GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
  - tekla 4y ago
    > However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations. Why? No they don't deserve anything. Unsolicited communication is unsolicited. >GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only. Why should anyone bother. It doesn't mean anything
    - teddyh 4y ago
      I was going to argue your comment, but you don’t deserve it.
narrowtux 4y ago
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it. I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect. Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app. It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan. Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users. > The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues. I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates. > Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication. Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?
- bmitc 4y ago
  > > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. > The article also discusses that They mention that but they don't really discuss it, and I disagree with the conclusion and advice. GitHub allows disabling issues altogether. Just do that snd save everyone trouble. > What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list? My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.
matkoniecz 4y ago
> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. Is it a bug report? In that case I agree that it is irritating. Is it a feature request? Then your mistake is to spend days on crafting feature request. I prefer to make simple feature request and spend more effort if it is provisionally accepted. > It just means that users get a false sense of the tool's maintainability, reliability, etc. by looking at a "clean" issue listing only to find out that tons of issues still exist. I look also at recently closed ones - if stalebot is present then I escape immediately. > The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate that is entirely appropriate response, maintainers are not obligated to fix bugs (unless they are under some support contract). > On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. what is the problem here?
- bmitc 4y ago
  > > On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. > what is the problem here? My personal issue with it is that it is misleading. I feel there is a difference between "I am the maintainer for these open source projects" and "I open sourced these personal projects" if one doesn't really maintain, in a community sense, the projects. It's akin to resume padding.
  - matkoniecz 4y ago
    OK, if someone abandons open source project and claims to be developing it then I see a problem. (though open sourcing project and not accepting PRs or even issues is fine, if it is actually maintained)
    - bmitc 4y ago
      Agreed. I think this just revolves around clear communication and expectation setting. Just too often it is all too implicit and ad-hoc, where frustration easily brews on both sides. It's like wet towels and mildew. Lol. Don't wet them if you're not going to dry them or hang them up. (Disclaimer: I didn't heavily think through this analogy.)
jjav 4y ago
> because the filing of an issue is not a request to fix Great phrase, this summarizes the point very well! Exactly. A bug report is just that, a report. It increases the knowledge base of what problems exist in the project so that everyone can know. It doesn't mean it has to be fixed. Not everything can always be done. So if it remains open, it's simply documentation of a problem that still exists. Closing it because some time passed is dishonest, if the problem still exists.

by bmitc 4y ago

gautamdivgi 4y ago

I don’t find anything wrong with the authors approach. I just think he should make it clear that he’s not interested in issues or PRs on the project readme or contribution guide. It’s hard to have it both ways - where you say issues and PRs are welcome but say no when someone reports or makes a contribution.

bmitc 4y ago
I agree that making it clear is important, and I think I edited my post at the same time as your comment to say the same. However, I think I still disagree with closing issues, particularly with a bot, even if expectations are set. On GitHub, I think labeling the issue is more appropriate. Labeling it as "maintainer-wont-fix-contributions-welcome" with a detailed "I will only accept a PR if these conditions are met" in the README is much better than just swatting away things by closing and saying "won't fix" or "this is not a bug". If PRs and issues truly will be ignored, then that really needs to be explicitly stated. Because otherwise, why even open source or release it? I have seen quite a few presentations with "I maintain all these projects" instead of the truth of "I open sourced all of these personal projects". There is a difference.
- tekla 4y ago
  > If PRs and issues truly will be ignored, then that really needs to be explicitly stated. No it doesnt. No one owes anything to you > Because otherwise, why even open source or release it? Because they can.
  - bmitc 4y ago
    Society generally disagrees that unclear or unresponsive communication is welcomed. If someone speaks to me, I believe giving and them expecting a respectful response is not entitlement on their part. > Because they can. That's not really an answer to basically any question. Yes, a person can do anything, but actions also have consequences. Also, frustration is a legitimate emotion for anyone. It's okay for someone to be frustrated and admit so in a respectful manner. Being frustrated does not make one an evil or entitled person by default. Lastly, there are different approaches and perspectives, which is also fine. For open source development, there is no one true approach that everyone is going to agree with. But I do think clear communication will reduce a lot of friction no matter the approach. I once came across a project where the maintainer clearly stated that they will never adjust the license. Is it frustrating? Yes. Do I disagree? Yes. But it's their choice, and they clearly stated it. So I grunt to myself and move on.

louwrentius 4y ago

The key thing is that your frustration doesn’t entitle you to anything. The best thing to do is to contact the maintainer first before you do the work. Saves a lot of frustration. But I feel that people don’t want to hear no and need an excuse to do the work anyway because they like doing it. The ‘no’ that eventually is / will be communicated shattered the illusion that they are helpful/contributing. For me the whole “no” topic is all about setting personal boundaries. Maintainers have to deal with the same drama as mostly women face when dealing with unwanted attention. But to me it’s 100% this ingrain sense of mostly men feeling so entitled to basically anything is so toxic. “No” is a perfect antidote to that toxicity.

bmitc 4y ago
> The key thing is that your frustration doesn’t entitle you to anything. Well see, I never said that. However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations. > The best thing to do is to contact the maintainer first before you do the work That's rarely possible without filing an issue, which will apparently be immediately closed anyway, and I think the better solution is for the README to merely state the expectations. GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only.
- tekla 4y ago
  > However, I do think maintainers, issue reporters, and contributors equally deserve clear and respectful communication and that, further, the burden rests on the maintainers to clearly communicate initial expectations. Why? No they don't deserve anything. Unsolicited communication is unsolicited. >GitHub provides the ability to disable issues altogether. Just do that if all you want to do is release a personal project as open source only. Why should anyone bother. It doesn't mean anything
  - teddyh 4y ago
    I was going to argue your comment, but you don’t deserve it.

narrowtux 4y ago

> As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. The article also discusses that. Of course there are better ways to do this than just closing it wihtout comment, even though the end result is still saying "no" to it. I have open-sourced a library that I wrote for an in-production app at work, and it got a little too popular for me to handle like most open source "consumers" (even though they don't pay me) expect. Every time there's a feature/pull request, I not only have to think about if the code is correct, but also if it would introduce breaking changes in the way it is used in that production app. It's very mentally draining to visit the issues page of that repository, because it's full of people needing help or wanting to contribute work. But I can't handle them all within an acceptable timespan. Every few months I take half an hour to clean up there, and then the issues list is already filled with disgruntled users. > The response to an issue of "contributions are welcome" or "you can fork it" are inappropriate because the filing of an issue is not a request to fix. It is an issue reporting mechanism. But too often, maintainers become chippy about reported issues. I agree in hindsight that it probably would've been better to just turn off the pull requests feature when creating a repository if you can't commit yourself to the potential workload it creates. > Saying no is fine but please be honest and upfront on a repository's README. If someone says "this is open source but it's mainly a personal project and/or library and I will aggressively close issues", then that does wonders to set expectations. And I think that's the key idea. Setting expectations, upfront, is the key to effective communication. Most of the time you don't realize that you really can't handle all that workload when you're still in the "honeymoon" phase of the thing you're open-sourcing. What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list?

bmitc 4y ago
> > As a user, I can't think of anything more frustrating to spend hours or even days on an issue on an open source project that "welcomes" issues and contributions and then creating a detailed GitHub Issue only for it to be responded with with author's "No" and immediately closed. > The article also discusses that They mention that but they don't really discuss it, and I disagree with the conclusion and advice. GitHub allows disabling issues altogether. Just do that snd save everyone trouble. > What are you supposed to do when it gets to the point where it's just overwhelming you to even look at the issues list? My thoughts are my overall opinion and approach: clear communication. Just update the README, appropriately comment on issues that are closed as a result, and maybe even disable issues.

matkoniecz 4y ago

bmitc 4y ago
> > On another note, many maintainers will report how much of an open source developer they are on their resume or talks they give, when in reality their open source projects are just that, open source. > what is the problem here? My personal issue with it is that it is misleading. I feel there is a difference between "I am the maintainer for these open source projects" and "I open sourced these personal projects" if one doesn't really maintain, in a community sense, the projects. It's akin to resume padding.
- matkoniecz 4y ago
  OK, if someone abandons open source project and claims to be developing it then I see a problem. (though open sourcing project and not accepting PRs or even issues is fine, if it is actually maintained)
  - bmitc 4y ago
    Agreed. I think this just revolves around clear communication and expectation setting. Just too often it is all too implicit and ad-hoc, where frustration easily brews on both sides. It's like wet towels and mildew. Lol. Don't wet them if you're not going to dry them or hang them up. (Disclaimer: I didn't heavily think through this analogy.)

jjav 4y ago

> because the filing of an issue is not a request to fix Great phrase, this summarizes the point very well! Exactly. A bug report is just that, a report. It increases the knowledge base of what problems exist in the project so that everyone can know. It doesn't mean it has to be fixed. Not everything can always be done. So if it remains open, it's simply documentation of a problem that still exists. Closing it because some time passed is dishonest, if the problem still exists.