3 ms·

"Hey John, thanks for contributing" - This is only true if you are actually grateful to John. Otherwise, John is wasting your time (if his patch is complete rub

by jdjb 13y ago

"Hey John, thanks for contributing" - This is only true if you are actually grateful to John. Otherwise, John is wasting your time (if his patch is complete rubbish). "There's a lot of good there but this algorithm really needs to run faster and use less memory" - Another lie (unless there actually is a lot of good there). What if there's not a lot of good? Should we just prefix our statement with this banal clause? "Check out how Sarah did it here when working with Y. Additionally, here's some resources." So now someone who's time is worth a lot (top tier linux maintainer) is responsible to LMGTFY for everyone who contributes?

codyb 13y ago
Sometimes a little politics goes a long way. You can always be grateful someone is taking their time to contribute to a project even if they're not particularly good at it yet. Version control and branching means things don't have to be implemented immediately or at all. If there's not a lot of good, I was assuming perhaps it was one part of his contribution, but if there isn't any good at all then how about "Thanks for contributing but in order to be an effective member of the team you're really going to need to work on X, Y, and Z. Unfortunately we cannot commit your patch to the code repository until this is the case. If you do work on X, Y, and Z though you should be at a point where you can contribute to quite a wide variety of areas within this project and will be a quite a valued member! We need people like you with dedication. And don't worry about it, if you look at version 0.a.b you'll see I made a bunch of the same mistakes!" If you have the time to dole out harsh criticism of someones patch you can't take the time to provide a helpful comment instead of an overtly negative one? "Oh I spent all this time reviewing your code and it sucks." is better to you than taking the what, ten or fifteen minutes to compose a quality reply? I understand the top tier linux manager's time is valuable. But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a polite manner. In addition, by providing resources, you make your own job easier as the quality of patches continues to improve in quality, you retain talent, and foster new talent within the software community. If you don't want to provide resources then perhaps a "Hey, if you have any questions trying to work through X, Y, and Z try to contact me here although you'll get far quicker responses on irc.freenode.net #linux".
- daemon13 13y ago
  >> But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a polite manner. In addition, by providing resources, you make your own job easier as the quality of patches continues to improve in quality, you retain talent, and foster new talent within the software community. One of the problems with assumptions here is that kernel maintainers by definition shall know that their code is wrong and why it is wrong . If this is not true, they shall not be kernel maintainers. Another one is that Linus does not need to retain talent that can not perform to acceptable standards. Please note that acceptable standards are different for different people.
  - codyb 13y ago
    No this is totally true and I agree. But if you can mold someone into performing at acceptable standards than you have more talent which produces better products faster. That's basically my reasoning for my approach. If you do not know why the code is wrong, then tell them what it is doing wrong in a similar fashion. "Hey John, I see you updated this patch. Thanks but it seems to be hogging memory. What can you do about that?" Perhaps you point them to people who have worked in that area before. "Well you working on I/O, you know Tim over here has worked in that area before, he might be busy but if you can't figure it out on your own maybe you can shoot him a question and see if replies." I guess a kernel maintainer may never make a mistake since you assume it is a tautology that all kernel maintainers by definition know when and where and why their code is wrong or they could not be kernel maintainers. Or you're implying that any kernel retainer will, upon being notified, no matter the language of the rebuke, immediately know how to fix it and will also be willing to do so. There are also different levels of experience for different people. It doesn't mean you should throw them off the ship or so harshly rebuke them that they never return to the project. And if there are different standards than you probably don't need to give everyone the harshest standard. Alright but I've posted enough in this thread.
prakashk 13y ago
Your comments seem entirely premised on the patch being "complete rubbish". If that is not true (and, there's nothing in the GP's comment to indicate otherwise), and actually "there's a lot of good there", why should the maintainer not be grateful to John?
- jdjb 13y ago
  Of course, if the patch is helpful the response should be a positive one. I'm not debating that point. I'm debating the fake politeness that is expected when a patch is in fact rubbish. It's more impolite to lie to someone and make them feel better by phrasing such as "It's good but...". It's much better to simply cut to the "but" part and tell it how it is. Fellow developers are not clients who are our responsibility to make feel good at the end of the day.
talmand 13y ago
You need to decide whether the examples given are outright lies or are just hypothetical. You can't have both. But I agree with your point, not everyone has the skills and mentality to be mentors and/or teachers to others who may wish to learn. It's just too bad so many have to be complete assholes about going about informing people of this fact.
- jdjb 13y ago
  Furthermore, you can't assume that because someone is unwilling to be a mentor that it's always the mentor's fault for not having enough patience or the right attitude. Sometimes the student just isn't worth investing your time and effort into.
  - talmand 13y ago
    Totally true, sometimes someone doesn't make for a good student. But I don't think it should be up to a bad teacher to decide who is a bad student.

by jdjb 13y ago

codyb 13y ago

Sometimes a little politics goes a long way. You can always be grateful someone is taking their time to contribute to a project even if they're not particularly good at it yet. Version control and branching means things don't have to be implemented immediately or at all. If there's not a lot of good, I was assuming perhaps it was one part of his contribution, but if there isn't any good at all then how about "Thanks for contributing but in order to be an effective member of the team you're really going to need to work on X, Y, and Z. Unfortunately we cannot commit your patch to the code repository until this is the case. If you do work on X, Y, and Z though you should be at a point where you can contribute to quite a wide variety of areas within this project and will be a quite a valued member! We need people like you with dedication. And don't worry about it, if you look at version 0.a.b you'll see I made a bunch of the same mistakes!" If you have the time to dole out harsh criticism of someones patch you can't take the time to provide a helpful comment instead of an overtly negative one? "Oh I spent all this time reviewing your code and it sucks." is better to you than taking the what, ten or fifteen minutes to compose a quality reply? I understand the top tier linux manager's time is valuable. But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a polite manner. In addition, by providing resources, you make your own job easier as the quality of patches continues to improve in quality, you retain talent, and foster new talent within the software community. If you don't want to provide resources then perhaps a "Hey, if you have any questions trying to work through X, Y, and Z try to contact me here although you'll get far quicker responses on irc.freenode.net #linux".

daemon13 13y ago
>> But if you can tell the code is wrong, then give reasons for why it is wrong, tell them you can not commit until those reasons are corrected, and do so in a polite manner. In addition, by providing resources, you make your own job easier as the quality of patches continues to improve in quality, you retain talent, and foster new talent within the software community. One of the problems with assumptions here is that kernel maintainers by definition shall know that their code is wrong and why it is wrong . If this is not true, they shall not be kernel maintainers. Another one is that Linus does not need to retain talent that can not perform to acceptable standards. Please note that acceptable standards are different for different people.
- codyb 13y ago
  No this is totally true and I agree. But if you can mold someone into performing at acceptable standards than you have more talent which produces better products faster. That's basically my reasoning for my approach. If you do not know why the code is wrong, then tell them what it is doing wrong in a similar fashion. "Hey John, I see you updated this patch. Thanks but it seems to be hogging memory. What can you do about that?" Perhaps you point them to people who have worked in that area before. "Well you working on I/O, you know Tim over here has worked in that area before, he might be busy but if you can't figure it out on your own maybe you can shoot him a question and see if replies." I guess a kernel maintainer may never make a mistake since you assume it is a tautology that all kernel maintainers by definition know when and where and why their code is wrong or they could not be kernel maintainers. Or you're implying that any kernel retainer will, upon being notified, no matter the language of the rebuke, immediately know how to fix it and will also be willing to do so. There are also different levels of experience for different people. It doesn't mean you should throw them off the ship or so harshly rebuke them that they never return to the project. And if there are different standards than you probably don't need to give everyone the harshest standard. Alright but I've posted enough in this thread.

prakashk 13y ago

Your comments seem entirely premised on the patch being "complete rubbish". If that is not true (and, there's nothing in the GP's comment to indicate otherwise), and actually "there's a lot of good there", why should the maintainer not be grateful to John?

jdjb 13y ago
Of course, if the patch is helpful the response should be a positive one. I'm not debating that point. I'm debating the fake politeness that is expected when a patch is in fact rubbish. It's more impolite to lie to someone and make them feel better by phrasing such as "It's good but...". It's much better to simply cut to the "but" part and tell it how it is. Fellow developers are not clients who are our responsibility to make feel good at the end of the day.

talmand 13y ago

You need to decide whether the examples given are outright lies or are just hypothetical. You can't have both. But I agree with your point, not everyone has the skills and mentality to be mentors and/or teachers to others who may wish to learn. It's just too bad so many have to be complete assholes about going about informing people of this fact.

jdjb 13y ago
Furthermore, you can't assume that because someone is unwilling to be a mentor that it's always the mentor's fault for not having enough patience or the right attitude. Sometimes the student just isn't worth investing your time and effort into.
- talmand 13y ago
  Totally true, sometimes someone doesn't make for a good student. But I don't think it should be up to a bad teacher to decide who is a bad student.