My tone doesn't make me wrong, or how I convinced the Ruby project to fix a bug | Hacker News Reader

My tone doesn't make me wrong, or how I convinced the Ruby project to fix a bug

felipec.wordpress.com

12 pointsfelipec29 comments

Your tone doesn't make you wrong, but it doesn't make you an ambassador either. You could have chosen much less combative words, which would have avoided pushing him into a defensive posture, and avoided most of the discussion. It's pretty obvious looking at the exchange that he was confused about what you were talking about, why it was a problem, and why it should be fixed.

A diatribe about the Japanese language and culture reflects poorly upon you. Every culture has their way of writing and expression and norms, and we give leeway to people speaking a foreign language for that reason.

Like it or not, we're all human, and one of the greatest skills one can learn is the skill of de-escalation.

Yes, every culture has their idiosyncrasies, which is precisely the reason why mentioned them. If every culture is different, then different cultures... are *different*. Being aware of the differences helps understand where the potential frictions might be.

You are making assumptions about me, but what about Tanaka and Matsumoto? They are Japanese and they couldn't get Funaba to understand either.

Ultimately Funaba wasn't angry with me, he just ignored me, he was angry with Matsumoto for listening to me and telling him what to do. Could Matsumoto have picked "less combative words"?

Or is it possible that there was a problem with Funaba?

The problem lies with you.

I've dealt with Japanese people for a long time, and what I'm seeing here is people trying to avoid a person who is being disruptive and rude. And I'd be miffed too, because your writing style comes off as arrogant and entitled.

I don't mean to imply that this is how you are in person, and I'm sorry that this will come off as an attack, but business communication is something that you'll really need to work on if you want to successfully contribute to larger projects (this is nothing to be ashamed of; Linus Torvalds had to take lessons, too). I'd also remove that blog post if I were you.

I have successfully contributed *thousands* of patches to many large projects. I don't need help.

And as is very typical you are concentrating on the wrong thing. I am not important.

The bugs that ruby users are experiencing *today* are important. If I die tomorrow that's not going to change.

> I have successfully contributed thousands of patches to many large projects. I don't need help.

Linus Torvalds successfully contributed far more, and for decades swore up and down that he didn't need any help with communicating (after all, what's so hard about it? You say what you mean and mean what you say! Child's play!). And yet even he eventually realized his need to learn.

At the end of the day, community and morale is far more important, because it improves velocity overall and fosters new blood. I know it's hard to see, because I've been there myself, scratching my head at why those "idiots" wouldn't just see reason and do things efficiently like me. Focusing on the code and not the people and their "silly" politics. I took far too long to realize that I was the problem.

No, Linus Torvalds did not realize that, he thought he was going to get cancelled, so he _claimed_ he was going to change.

After the stormed passed he went back to being Linus.

"The problem lies with you."

You yourself are hypocritically writing in a direct, laconic style while advising Felipe to politely tip toe around sensitivity issues. Why aren't you yourself trying to "empathize" with Felipe and whatever culture he's from?

To be clear, I obviously like direct communication. I'm just pointing out the hypocrisy of this comment chain.

No but it does make you an asshole, and you drove an open source maintainer to quit.

Software is like 10% code, and 90% soft skills. You need to work on that.

And that case he drove out a racist asshole. He did the good deed

The racist asshole is the author of the article who drove out the maintainer. (Just look at his rant about "Japanese verbosity".)

He is just stating a fact. If this looks like racism to you then I am afraid it's not him who's racist.

He quotes three excerpts from an email exchange in Japanese followed by his "translation" where he leaves out much of the explanation and even the parts where they quote each other so he can demonstrate his claim that in Japanese "you have to say much more than just what is actually necessary."

Does that make it a fact? I don't think so, because I disagree that the explanations he cut out were actually unnecessary.

Pointing out idiosyncrasies about a language is not racism. I didn't even complained about the verbosity, merely pointed it out.

Moreover, if I didn't like the language why do you think I learned it?

Maybe you should edit your post to have actual translations then.

The comments are open. Any translator willing to help would be more than welcome.

Anything like this ever happen to you before?

https://felipec.wordpress.com/2011/09/23/no-gnome-doesnt-wan...

That's a red herring. If you want to discuss that incident feel free to comment on that post. This is different.

Any ideas on what might be common between the two events?

While I understand the point about displaying a time in a given timezone (output/strftime)

I don't see how specifying a timezone on a epoch count makes any sense (input/strptime).

A 'number of seconds since epoch' (%s) is a _duration_, not a time. It makes no sense to attach a time zone to it. (This seems to have been the initial response from the project maintainer).

From the original article the reported "bug" is about _parsing_ an epoch duration, not about displaying a time.

DateTime.strptime('0 +0100', '%s %z')

Probably I am missing something but I've re-read the original article and I cannot see this point addressed directly (examples are given but they have to do with displaying/output, not parsing).

You can argue that attaching a time zone to a `%s` doesn't make sense, but a lot of people do it, and more importantly: it doesn't hurt.

If you do `Time.strptime('0 +0100', '%s %z').to_i` you get the correct result: "0". That is: the number of seconds since the epoch is correctly parsed. The time zone is extra information that doesn't affect `%s` in any way. In other words: it's orthogonal.

Was your goal to be right or to get the patch pushed? Now you're opening up old wounds because.... ?????

Like damn dude, you catch more flies with honey than vinegar. Don't they have a saying like that in Spain?

Just because people say it doesn't mean it's true.

And the reason why I made the post is that there's an actual important issue with rubygems, but I'm not allowed to comment. Users are being negatively affected for no reason. I have the fixes.

Ask any user negatively affected by this and they would tell you I should be heard. In fact, I've received emails personally thanking me for persisting and trying to get it fixed.

There's more important things than tone.

This seemed to go beyond being blunt to get your point across.

It seems there were numerous possible better outcomes and I would have liked to see some acknowledgment of that in the conclusion, lessons learnt, instead of leaning on Linus and "I was right". Especially after 10 years reflection.

> Not only that, but if you asked ruby to represent the epoch in Berlin with “%s %z“, it did it correctly:

> DateTime.parse('1970-01-01T01:00:00 +0100').strftime('%s %z') => "0 +0100"

Does that mean that "0 +0000" is the same as "0 +0100", "0 +0200", "0 +0300" etc.?

Yes, it's the same time in different timezones. "0 +0000" is "00:00 +0000", "0 +0100" is "01:00 +0100": same time.

It does not look well for an outsider looking into Ruby maintenance to see a technical discussion devolve into a discussion about politeness and race. Luckily matz made the right call.

Felipe is right that: 1. `%s %z` is inconsistent in ruby. 2. He has consensus everywhere else. 3. Nobody has provided any good technical arguments against his.

Whether he is polite enough or not, code talks, bullshit walks.

The translations that were purposely cut from the post:

Chunk 1

Unlike the day of the week and the date, %s and %z are independent, so I don't see the problem. > Here, independent means orthogonal, so changing one doesn't change the other.

It doesn't mean there is a problem, it just means they are different. For example, it is possible to write a date in UTC and then change it to local time. But this time it's only %s.

Suppose I am in Japan and dealing with UTC time. Let's say I'm in Japan and I'm dealing with UTC time. The given time is in UTC, but I'll refer to it as +09:00.

2001-02-03T04:05:06 UTC (+0900)

Since this is not common DateTime.parse('2001-02-03T04:05:06').new_offset('+0900') This is not common, so the description would be something like

Now, this kind of description is not currently in ruby, but I feel that what is required for the '%s %z' thing is something different from what we have been dealing with, which from my point of view includes this kind of thing.

Chunk 2

Perhaps if you could elaborate a bit more on what a date is or something like that, it might make it more understandable.

When I say date, I am including such time. I think of this date as a kind of name assigned on a time axis based on certain rules. In space, it is like a milestone. There are actually more imperfect dates, which are also dates. Sometimes they can be identified by context and other information, and sometimes they can't.

Chunk 3

If you think the time difference has special significance, you can describe it in local time. > > The question is which local time, not the local time set by the OS, but an artificial local time with a > fixed difference from UTC. > > I understand that you are talking about being able to record the given time difference as is. > I understand that you are saying that the given time difference can be recorded as it is.

I'm not sure what you mean.

Since %s seems incomplete to begin with, I don't know why you are so hung up on it.

If we replace %s with space, we can't place milestones with it, it just shows the distance, and we can't define the distance, can we?

Also, just for the record, I would like to confirm that what Mr. Tanaka is referring to as fixed time difference is not universal.

The given self-evident local time is also useful, and the time zone = time zone information, not time difference. It contains more information than just time difference.

Isn't it important to have the actual time system and format we are referring to, such as daylight saving time? In that sense as well, I feel uncomfortable with the trend of %s bias.

Thank you for the translation, I've updated the blog post with them. I don't see any new actual information though. For example in chunk 2 what I gathered from Google Translate was:

> What I call a date includes time. It's like a name given on a point on the time axis.

And now it's:

> When I say date, I am including such time. I think of this date as a kind of name assigned on a time axis based on certain rules. In space, it is like a milestone. There are actually more imperfect dates, which are also dates. Sometimes they can be identified by context and other information, and sometimes they can't.

What information did we gain?

Anyway, in chunk 1 you said:

> Since this is not common DateTime.parse('2001-02-03T04:05:06').new_offset('+0900') This is not common, so the description would be something like

But that's not a correct sentence, I changed it to:

> Since this is not common, the description would be something like DateTime.parse('2001-02-03T04:05:06').new_offset('+0900').

Back in 2012 I encountered a bug that took me through many hoops to get fixed, all because of a single developer, which compelled me to start an infamous email thread.

Reply on news.ycombinator.com