3 ms·
> When given criticism, banning the critic from ever contributing is a ludicrously adolescent response. According to this: https://christine.website/blog/serie
by lightgreen 6y ago
> When given criticism, banning the critic from ever contributing is a ludicrously adolescent response.
According to this: https://christine.website/blog/series/v https://christine.website/blog/series/v it was a year between first post and the last. It was more than enough time to make at least some contributions.
This timeline convinces me that Christine did not intend to contribute at all.
> Well, in the adult world you will face criticism for what you produce constantly.
Criticism is natural. Banning people who don't help, but distract and demotivate, is also natural.
> You need to develop a mature response to all these scenarios.
It's not that simple. Too much criticism can kill will even in strongest people. Sometimes the best response to non-constructive criticism is to just ban, and focus on what's important.
- phaemon 6y agoNo, the best response, if the devs truly felt the criticism was non constructive, was to ignore it. Having read the posts, it seems perfectly reasonable criticism, with enactable improvement. The dev response seems immature (at best) to me. To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up.
- lightgreen 6y ago> No, the best response, if the devs truly felt the criticism was non constructive, was to ignore it. We don't know how exactly Christine communicated with project devs. We see the posts, but we don't see Telegram or Discord messages or GitHub issues or comments or whatever. For example, there are people who just derail/flood group communications by raising non-important issues (like discussing syntax), or discussing completely unrelevant topics (like starting a conversation about political situations, human rights etc). Anyway, I agree that the project author could do better. But I cannot blame him either. At least until either party provide some evidence. > Having read the posts, it seems perfectly reasonable criticism, with enactable improvement Calling a product vaporware is not a good way to start a constructive communication. If I did that, I'd either start with apologising for calling the project vaporware, or did not attempt to join the community. > To put it another way: if this was a commercial product and my team came whining to me about this, I'd tell them to grow up. Developers in commercial products are paid for listening that feedback (constructive or not). But V is open source. And in commercial companies, internal tensions are usually fixed very quickly, because teams cannot work efficiently when communication is bad.
- phaemon 6y agoWe don't know the full story because the V devs deleted it. Experience tells me that people tend not to delete stories that paint them in the better light. It's vaporware until it we exists. Perhaps it would be kinder to call it "conceptware" but who really cares? Oh, and the vast majority of commercial software firms have absolutely terrible communication. And, yes, they do not work effectively. I feel like I am destroying an optimistic world view here, which is the last thing I wanted. There are many excellent and exciting places to work. Don't let an old man's cynicism put you off!
- delian66 6y ago>Perhaps it would be kinder to call it "conceptware" but who really cares? I do. It is not vaporware, because it exists, can be used, works for the most part, and is improving every day. Please do refrain from calling stuff, that you do not use yourself names.
- codezero 6y ago> And in commercial companies, internal tensions are usually fixed very quickly I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out.
- lightgreen 6y ago> I would love to know what companies have good systems to keep internal tensions in check because I've never even seen a single company that had that figured out. Probably most companies deal with tensions more or less successfully. They have good instruments to manage these things: yearly bonuses and option to fire employees who do not cooperate. Obviously these instruments are not available in open-source projects.
- codezero 6y agoWhat companies, and what are those instruments? I'm sincerely curious, I have worked in tech for 20 years, and while some companies are active in trying to make sure teams work well together, I've never seen one that had specific systems for keeping tensions in check - maybe it's because I've worked for <1000 people companies?