5 ms·

>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm droppin

by krasin 4y ago

>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library without a second thought. You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.

Arnavion 4y ago
Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
- knicknic 4y ago
  I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of. I am okay with paying for software. not okay with paying to find out my feature request will get denied
pharmakom 4y ago
Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
- krasin 4y ago
  They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously). The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.
ilyt 4y ago
> You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced. They were explicitly talking about PR for a bug, not unwanted feature. Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem

by krasin 4y ago

Arnavion 4y ago

Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.

knicknic 4y ago
I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of. I am okay with paying for software. not okay with paying to find out my feature request will get denied

pharmakom 4y ago

Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.

krasin 4y ago
They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously). The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.

ilyt 4y ago

> You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced. They were explicitly talking about PR for a bug, not unwanted feature. Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem