3 ms·

In this thread I see a few comments assuming that polite VS blatantly rude are the only options. If for "polite" we mean, accepting bad contributions, ideas, co

by antirez 11y ago

In this thread I see a few comments assuming that polite VS blatantly rude are the only options. If for "polite" we mean, accepting bad contributions, ideas, code, yep that's a problem, but to refuse contribs that don't match the idea of the person in charge of a project does not need to be as bad as we see in certain cases. It is possible to say negative things about ideas or code in a decent way and very firmly at the same time, without attaching persons, and without creating an environment where new ideas are limited since, well, you are going to be insulted if your idea is less than excellent. A couple examples: Behavior A: This code is a good example about how you should never write code, it's going to explode in the hand of users, it's going to make our project a piece of crap. Please don't do that, how many times I've to repeat that... you are a long time contrib, it is unacceptable you send me such a crap of stupid patch. Behavior B: Sorry, I think the patch is not good because it does not test correctly for <some-technical-reason-here>. Without this check the code works today but may fail tomorrow. Because our project needs an high level of stability, we can't merge such a contribution. Please could you review it or perhaps even rewrite it in a way that's going to be very stable? Thanks. I think both A and B send the same message, but with "A" the problem is that the contributor may never return back or may be offended. Life is already tough, there is no need to be offended randomly because you are trying to give code for free.

maratd 11y ago
How about C: We have a tight deadline. Why don't you approach this by doing x and y. After we're finished and have production code deployed, you can refactor into z. In the process of implementing x and y, the developer will soon learn that z is inferior. If he doesn't, you need to get rid of him because he's incapable of learning.
- davidw 11y ago
  antirez is approaching it from the open source point of view - businesses are different in many ways.
Swizec 11y ago
B doesn't send the same message, there are too many weasel words, and rather than being polite, comes off as giving the other person authority. I think. Here's how I would phrase it: "Thanks for the patch. How does your code deal with condition X? We're a big project that needs to consider the needs of users under many different circumstances, so even if it seems like X only happens in 1 out of every 10,000 cases, that means it happens every five minutes to one of our users somewhere in the world." The idea is that you know the contributor didn't check for X, but you're giving them the option of saving face. You just asked them whether they considered such a condition and explained why it might be important. Edit: and if they did consider X, they can explain why their solution is okay. You could be wrong in thinking that it's not.

by antirez 11y ago

maratd 11y ago

How about C: We have a tight deadline. Why don't you approach this by doing x and y. After we're finished and have production code deployed, you can refactor into z. In the process of implementing x and y, the developer will soon learn that z is inferior. If he doesn't, you need to get rid of him because he's incapable of learning.

davidw 11y ago
antirez is approaching it from the open source point of view - businesses are different in many ways.

Swizec 11y ago

B doesn't send the same message, there are too many weasel words, and rather than being polite, comes off as giving the other person authority. I think. Here's how I would phrase it: "Thanks for the patch. How does your code deal with condition X? We're a big project that needs to consider the needs of users under many different circumstances, so even if it seems like X only happens in 1 out of every 10,000 cases, that means it happens every five minutes to one of our users somewhere in the world." The idea is that you know the contributor didn't check for X, but you're giving them the option of saving face. You just asked them whether they considered such a condition and explained why it might be important. Edit: and if they did consider X, they can explain why their solution is okay. You could be wrong in thinking that it's not.