5 ms·

Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the w

by fxn 15y ago

Indeed, it took me some 24 hours to revert. I reflected about it for some time. After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.

zumda 15y ago
Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)
kelnos 15y ago
I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.
chc 15y ago
I hate to be harsh, but just to give some perspective: You really come across as stubborn and intractable there. Your rationale basically boils down to "People might think I was wrong if we change this." The reason given is not anything like "The code I am reverting is inferior," it's just "This code doesn't support the point I want to make." You even said that if his commit message had been different — not the code, just the commit message — you would have left it. Try imagining this from somebody else's eyes — what does it look like?
- fxn 15y ago
  I can only say you basically have no idea what you are talking about. I know my motivations, you can't read my mind chc.
  - chc 15y ago
    That is true, and I'm sorry if it sounded that way. I was speaking from the perspective of interacting with other people, not your inner thoughts. You might actually have had very good reasons why your choice was superior, but you did not share them with anyone else, and from an impartial observer's perspective, it looks like this stonewalling is what made a simple PR turn into a huge bikeshedding flamefest. If this doesn't matter to you, I apologize for wasting your time. It just seemed like something I would want to hear if I were in your place.
    - fxn 15y ago
      If that was the intention I appreciate it. Yes it matters to me, but up to a point. I cannot do things in my life seeking approval or saying yes to some people when I am convinced the answer is no. Also, saying no, and not applying the PR the way I did, with the rationales and respect I showed, should not be taken as an offense. People just get upset when they see the red label "Closed". On the other hand, for every 24 haters, I can present 24 lovers. It just doesn't matter, one has to do what he thinks is the correct action. Do it politely, but do it.
      - 15y ago
neerajdotname2 15y ago
Thanks for not allowing code convention to be based on mob psychologoy.

by fxn 15y ago

zumda 15y ago

Ah I'm sorry, I should have rechecked before posting this. I meant no offense. There you see how closely I follow this story... :)

kelnos 15y ago

I was thinking about avoiding replying on this thread, because I can't know the motivations of the people involved, but this reply kinda takes the cake. I was an active open source contributor and maintainer for around 6 years this past decade. I've witnessed (and sadly fervently participated in) my fair share of bike-shed discussions. Some (most?) of them quite regretfully. I've learned something recently about APIs and frameworks, when you're the author. Something that should be obvious, but apparently isn't: your job is to make it as easy to build on as possible. Full stop. That's it. That is the number one priority. If one of your interfaces is confusing, you make it not confusing. It doesn't matter if it makes the implementation a little bit more complicated, or a little bit less beautiful and idiomatic. It does matter if it introduces a huge unacceptable performance degradation or a security issue. But that just means you need to rethink your implementation and assumptions. Because really, the user of your software is all that matters. You can make all sorts of stupid arguments, arguments that I myself have made in the past: * I write this software for me, not for you. Be happy that I've chosen to share it with you so you can benefit too. * Maintainability is more important. * Implementation elegance is more important. * Following common idioms is more important. * It's documented, so even if it's not 100% straightforward, it's ok. * If you don't like it, fork it. No. I don't care. At all. Once you make your code public in the open source world, it's not yours anymore. It belongs to everyone. Suggesting any of the above is just selfish, egotistical, and irresponsible to your users. This is the real world here, not some idealized theoretical academic playground. People use your software to get work done. People use your software to avoid having to reinvent the wheel every time they come across a similar problem. People use your software because it saves them time. Oh wait: except when behavior is changed for no good reason, and now they have to audit tens of thousands of lines of code to make sure everything still works. It's utterly unnecessary to force people to do this. I've been sorely tempted any number of times to stick to my guns, believing more in the principle of the thing than in the practical effects my decision would have on my users. And I'm sad to say that many times I made what I now know to be the wrong decision. The closing of the initial pull request might be forgivable. I disagree with it, but hey, it's not the end of the world, and there's certainly precedent for that behavior. Sure, the change that introduced that behavior is pretty questionable, but... ok, let's leave it be. But then we have another developer who commits a change that "fixes" the behavior in a manner that looks elegant and readable and maintainable. And you revert it. Why? Because you feel it sends the wrong "message". Because it might make people believe that all predicate methods return boolean singletons. Which is nothing more than convoluted logic used to reinforce your own opinion. But ok, ok. We're all human. And I could certainly argue that it was rude of the other guy to make that commit without consulting you first. (Assuming he didn't, I actually do believe it was pretty rude of him to do that.) And then there's the final straw: someone submits a pull request to augment the documentation to make it clear what the method actually returns. And you reject it. Ok, you don't want so much information about the internal implementation in the docs. Gotcha. But you can still make the docs clearer without leaking that info. (Or, hell, you could just, y'know... not leak the implementation out through the API call itself.) All credibility lost now. The crap about variable-width vs. fixed-width font usage in docs is just semantic masturbation. You are not making things clear for your users. That is a problem. Instead of fixing it, you dismiss people who try to help you. Is this particular issue a bike-shed moment? Yeah, probably. The return value of xml_http_reqeust? isn't really what I care about. I'm sure there are plenty of other predicates in Rails that behave similarly. The issue here is the message this sends: "I care more about writing idiomatic ruby than I care about making my users' lives easier". Which is ridiculous when you consider that the entire purpose of Rails is to make webapp developers' lives easier.

chc 15y ago

I hate to be harsh, but just to give some perspective: You really come across as stubborn and intractable there. Your rationale basically boils down to "People might think I was wrong if we change this." The reason given is not anything like "The code I am reverting is inferior," it's just "This code doesn't support the point I want to make." You even said that if his commit message had been different — not the code, just the commit message — you would have left it. Try imagining this from somebody else's eyes — what does it look like?

fxn 15y ago
I can only say you basically have no idea what you are talking about. I know my motivations, you can't read my mind chc.
- chc 15y ago
  That is true, and I'm sorry if it sounded that way. I was speaking from the perspective of interacting with other people, not your inner thoughts. You might actually have had very good reasons why your choice was superior, but you did not share them with anyone else, and from an impartial observer's perspective, it looks like this stonewalling is what made a simple PR turn into a huge bikeshedding flamefest. If this doesn't matter to you, I apologize for wasting your time. It just seemed like something I would want to hear if I were in your place.
  - fxn 15y ago
    If that was the intention I appreciate it. Yes it matters to me, but up to a point. I cannot do things in my life seeking approval or saying yes to some people when I am convinced the answer is no. Also, saying no, and not applying the PR the way I did, with the rationales and respect I showed, should not be taken as an offense. People just get upset when they see the red label "Closed". On the other hand, for every 24 haters, I can present 24 lovers. It just doesn't matter, one has to do what he thinks is the correct action. Do it politely, but do it.
    - 15y ago

neerajdotname2 15y ago

Thanks for not allowing code convention to be based on mob psychologoy.