3 ms·

This is a thoughtful and important article for anyone who uses or creates open-source software, which is everyone. But, if we follow this advice? If some more

This is a thoughtful and important article for anyone who uses or creates open-source software, which is everyone. But, if we follow this advice? If some more thoughtful and considerate users kindly reduce their input into support conversations to avoid overwhelming developers, doesn't this mean that support conversations will become dominated by users who are not thoughtful and considerate?

giomasce 4y ago
The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community.
- prox 4y ago
  It’s a problem everywhere in software, the ones who give back the least feel the most entitled. Having a some form of a treshold is good, whether that is money, or some sort of on-boarding (e.g. can’t comment until you are a member for x days) Usually the ones with loudest mouths have the shortest attention span and don’t bother with those things. I have seen this in many communities.
- FatalLogic 4y ago
  >The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community That's true, and it's a good goal. But, my point is that if we try to reduce entitled input by simply asking people not to behave entitled, then the result may be that we increase entitled input (as a proportion of all input), because many 'entitled' users will ignore the request, because they feel entitled. In the common scenario where developers are already overwhelmed with suggestions and demands, then they will have even less time to separate out the good suggestions from the bad.
jka 4y ago
I don't know what the best answer to that potential problem is: I think users should continue to be allowed to comment on any issue. However I do think that the amount of analysis and effort that the user has done for each comment is relevant. Silly hypothetical example: if a project is a Fibonacci function that (incorrectly) prints nothing but repeated "1" values, then the potential range of comments may include: - "it's wrong" - "it's printing the wrong output" - "expected to see 1 1 2 3 ... but found 1 1 1 1 ..." - "line two is missing an addition operator near character five" - "please see #3 for a pull request to add an addition operator on line two" (roughly in order of estimated "most frequent" to "least common" comment volume -- and not coincidentally, also ordered from "least analysis" to "most analysis" performed) Not all participants have the same level of analysis and development ability - and for many projects there's a lot of surrounding domain knowledge (and/or history) required to post more valuable comments. Also worth noting: high-frequency, low-analysis comments along the lines of "it's broken" can still be useful - they're often an indicator that a bug has been introduced, and can be the equivalent of comment storms on Twitter asking whether a service is down after a website/API has an outage. Coming back to the problem: it's difficult to scale the ability of small groups of maintainers to respond to large volumes of comments - as the article alludes to, it can become a kind of "time denial of service" attack. I'd guess that problem is most pronounced for developer-and-end-user-facing projects (web frameworks, for example). One solution could be tools that help maintainers cluster and categorize comments -- customer support tools are often designed to do this. Another idea is whether it'd be possible to challenge the commentor gently to check whether they've provided all the relevant information. This could theoretically be conversational (human or automated) -- and that's similar to tech support in traditional IT. Finally, a structural solution is to attempt to choose software architectures that distribute the support load and allow clusters of maintainers and developers to develop expertise in particular areas. This is, to a large extent, naturally the way that open source evolves. If one project becomes too heavyweight, then frequently we'll see smaller libraries emerge that provide the core functionality elements with a smaller code surface. If development slows unacceptably or moves in problematic directions, then motivated actors generally step in to fork or create an alternative. In summary: I think that these ticket entitlement issues have likely existed in closed environments for a long time, and there are patterns and tools for dealing with them that may be valuable. Also it's a software-and-organizational architecture issue (in an evolutionary environment with no central authority).
jacobtomlinson 4y ago
OP here, thanks for the kind words! I hear your point. I’m not saying don’t make a comment, just that folks should try and consider the human on the other side more.

giomasce 4y ago

The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community.

prox 4y ago
It’s a problem everywhere in software, the ones who give back the least feel the most entitled. Having a some form of a treshold is good, whether that is money, or some sort of on-boarding (e.g. can’t comment until you are a member for x days) Usually the ones with loudest mouths have the shortest attention span and don’t bother with those things. I have seen this in many communities.
FatalLogic 4y ago
>The point is not reducing input per se, but reducing entitled input that doesn't give back anything to the community That's true, and it's a good goal. But, my point is that if we try to reduce entitled input by simply asking people not to behave entitled, then the result may be that we increase entitled input (as a proportion of all input), because many 'entitled' users will ignore the request, because they feel entitled. In the common scenario where developers are already overwhelmed with suggestions and demands, then they will have even less time to separate out the good suggestions from the bad.

jka 4y ago

I don't know what the best answer to that potential problem is: I think users should continue to be allowed to comment on any issue. However I do think that the amount of analysis and effort that the user has done for each comment is relevant. Silly hypothetical example: if a project is a Fibonacci function that (incorrectly) prints nothing but repeated "1" values, then the potential range of comments may include: - "it's wrong" - "it's printing the wrong output" - "expected to see 1 1 2 3 ... but found 1 1 1 1 ..." - "line two is missing an addition operator near character five" - "please see #3 for a pull request to add an addition operator on line two" (roughly in order of estimated "most frequent" to "least common" comment volume -- and not coincidentally, also ordered from "least analysis" to "most analysis" performed) Not all participants have the same level of analysis and development ability - and for many projects there's a lot of surrounding domain knowledge (and/or history) required to post more valuable comments. Also worth noting: high-frequency, low-analysis comments along the lines of "it's broken" can still be useful - they're often an indicator that a bug has been introduced, and can be the equivalent of comment storms on Twitter asking whether a service is down after a website/API has an outage. Coming back to the problem: it's difficult to scale the ability of small groups of maintainers to respond to large volumes of comments - as the article alludes to, it can become a kind of "time denial of service" attack. I'd guess that problem is most pronounced for developer-and-end-user-facing projects (web frameworks, for example). One solution could be tools that help maintainers cluster and categorize comments -- customer support tools are often designed to do this. Another idea is whether it'd be possible to challenge the commentor gently to check whether they've provided all the relevant information. This could theoretically be conversational (human or automated) -- and that's similar to tech support in traditional IT. Finally, a structural solution is to attempt to choose software architectures that distribute the support load and allow clusters of maintainers and developers to develop expertise in particular areas. This is, to a large extent, naturally the way that open source evolves. If one project becomes too heavyweight, then frequently we'll see smaller libraries emerge that provide the core functionality elements with a smaller code surface. If development slows unacceptably or moves in problematic directions, then motivated actors generally step in to fork or create an alternative. In summary: I think that these ticket entitlement issues have likely existed in closed environments for a long time, and there are patterns and tools for dealing with them that may be valuable. Also it's a software-and-organizational architecture issue (in an evolutionary environment with no central authority).

jacobtomlinson 4y ago

OP here, thanks for the kind words! I hear your point. I’m not saying don’t make a comment, just that folks should try and consider the human on the other side more.