4 ms·
Maybe that is what the developer intended, but afaik it is not what he communicated. What he communicated was a flat out dismissal of the issue along with the p
by cerebellum42 7y ago
Maybe that is what the developer intended, but afaik it is not what he communicated. What he communicated was a flat out dismissal of the issue along with the proposed fixes. Followed by deleting the whole issue from GitHub. To be fair, there were some very unpleasant things said in there, but he could have just deleted those and maybe locked the conversation telling people about his plans.
This whole thing was a feedback circle of increasing hostility between the community/contributors and this developer. At some points the developer was very unresponsive, leading to disappointment from the community, but then some very uncalled for personal attacks came from the community. I think the developer received some justified criticism, but I still understand his perspective, putting work in and getting abuse back sucks.
- protomyth 7y agoSo, how fast do people expect developers of open source projects to respond before someone is considered unresponsive? I'm not sure combining social media with code control is going to be such a good thing for a lot of developers who might not like to program in a fishbowl.
- zozbot234 7y agoExpecting a reasonably-quick response to security concerns is certainly appropriate.
- jdbernard 7y agoIn a free project where the author isn't paid? What if he's on vacation? What's the SLA there? Is it reasonable to expect him to cut short the vacation? If you want to be able to place expectations on the author, pay them and get a contract.
- atoav 7y agoThen it is about communicating exactly this. Security and trust hinge on properly communicating what is going on.
- protomyth 7y agoWhat is reasonably-quick time wise?
- dunnock 7y agoThat's like expecting your boss to double your salary because he is paying you salary. Opensource expectation should be in general if you are not happy feel free to fork and fix yourself. Then submit PR if you want to push your fix upstream. But still so many PRs getting rejected, because they do not pass code review and usually it does not cause reporters of those failed PRs to open whole big flame discussion. That + overreaction on reddit was a last drop after which Nikolay decided to close the thing.
- ssokolow 7y agoFrom what I saw, the problem wasn't response time but response tone. If he'd said "I'll write my own solution" rather than calling it boring, his response wouldn't have been a problem.