Much less crashing in with it in the form of a “SumoBot,” as Mozilla seems to have done to its non-English communities… (with the disclaimer that I have zero insight into Mozilla’s process here outside of this writer’s account).
It puts a name to a considerate consensus-based way to approach change, that seems humane (and effective) in any culture—leave it to the Japanese to have a specific term for it…
I have to say it feels like a really familiar, NGO-flavored disrespect, though: “we’re doing this favor for underrepresented language communities,” regardless of whether they want/need it or not.
“There’s only X number of you having to shoulder the load in XX sub-community, don’t you want us to impose a bunch of ‘help’?”
Well, no, if the choice is between a formidable volume of slop and a smaller but well-executed volume of volunteer labor-of-love…
(…I say as a person very much without all sides of the story, and shooting from the hip a bit. I don’t mean to impugn anybody’s intentions, and I imagine at the end of the day we’re all on the same side here.)
For any RFC, there will be a "comment" after publication from someone who did not take earlier comments seriously enough to read them.
Mind boggling
You can't just arrive after publication, ignore what others said before you, and expect anyone to listen to you.
"many of the early RFCs were actual Requests for Comments and were titled as such to avoid sounding too declarative and to encourage discussion.[8][9] The RFC leaves questions open and is written in a less formal style. This less formal style is now typical of Internet Draft documents, the precursor step before being approved as an RFC." https://en.wikipedia.org/wiki/Request_for_Comments
At this point, as we close in on 10,000 final-stage documents, it's better to pretend that "RFC" is just a name, not an acronym.
When reading about nemawashi I immediately thought about its usage in software refactoring.
This is something you often intuitively do when making bigger refactors. Lay the foundations before actually doing it. Affected code parts and stakeholders should not be surprised by one big change. Instead they should be consulted before hand, building consensus, modify the planned big refactor itself and preparing the individual parts for it by small changes. Otherwise you will encounter a lot of friction, introduce bugs, etc.
It is very nice to have a proper term for this.
I already suspect that Duolingo destroyed real people's recording of Spanish conversations and replaced them with AI. For example I can quite often hear continental Spanish accent which has never been taught to me before (as I started with Duolingo as a freshman) - it used to be always American Spanish accent. Wrongly cut conversions is another matter.
Long time in Japan too, I would not consider newamashi as being Japan's strengths.
The sort of consensus building ultimately involves having to do stuff to make people's opinions feel taken care of, even if their concerns are outright wrong. And you end up having to make some awkward deals.
Like with all this "Japanese business culture" stuff though, I feel like it's pretty universal in some degrees or another everywhere. Who's out there just doing things without getting _any_ form of backchannel checking first? Who wants to be surprised at random announcements from people you're working with? Apart from Musk types.
But of course some people are very comfortable just ripping the band aid off and putting people in awkward spots, because "of course" they have the right opinion and plan already.
Why context matters in judging whether some practice is good or not.
To be clear this is Japan we’re talking about with the twenty years part. The same thing applies in the US but on smaller timescales though. If people feel appreciated and respected and you have good relationships, they will basically back whatever you want.
I tend to lean towards thinking backchanneling makes sense as a general vibe, if only because it's a way of doing things that lets people have dignity, and the costs _can be_ low.
Just that lacking context one really can't make that many blanket statements.
I think the difficult cases come when people's interests aren't aligned. If you're coordinating with a vendor to basically detangle yourself from their vendor-specific tooling to be able to move away from them, at some level it doesn't really make sense to read them in on that.
There are degrees to this, and I think you can argue both sides here (so ultimately it's a question of what you want to do), but parties are rarely neutral. So the tough discussions come from ones where one party is going to be losing out on something.
IMHO the only correct way to measure the effectiveness of decision making is from the quality of executed outcomes. It is somewhat nonsensical to sever decisions from execution, and claim that decisions have been made rapidly if the decision doesn't lend itself to crisp execution. Without that, decisions are merely intentions.
How do you know what "the right thing" is at the outset without talking to the stakeholders?
I'm dealing with someone's "the right thing" that is actually wrong and dumb. They didn't ask us before rolling out the new "standard."
I think most people have at least one issue where they discount one of the stakeholder's judgement, it's all fairly contextual. But hey, if you're the CEO of some company you have the ability to act on that discounting.
If you have a better solution to correct an error or solve a problem than having a call/meeting and openly discuss situation and possible resolutions - I would love to know about that.
Acknowledging the mistake immediately seems like a good start.
It ensures you truly understand what the crux of the grievance is and what they would like to happen to get it resolved, instead of being distracted by tangential points.
> That nothing is on the record?
If you’re already assuming malice before the resolution process even had a chance to begin, the conversation has little chance of being productive. Do you know this particular person? Have you interacted with them before?
> A lot of people don't want to jump in calls, ever.
Then say no! But being preemptively mad because someone asked is absurd and does nothing to fix the problem. The asker shouldn’t assume what the other person wants or doesn’t, they should ask. Which is what they did.
> Acknowledging the mistake immediately seems like a good start.
Yes, very much agreed. But you can’t take back what you did, only try to make amends. And that’s very difficult if the other party demands perfection while you’re still even trying to understand the situation.
in your own opinion
>and very American
from an American company? that's what I'd expect. Should they have brought up some Japanese PR consultant just to reply to a community post?
>acknowledging the mistake immediately
Who says a mistake happened? You? Before apologizing maybe we should understand the problem?
Yes! It wouldn't even have had to have been a good one to have done a better job. Shit, just find the closest weeb and run it past them.
A developer relations person needs to understand developers so why shouldn't we expect the community person to understand the community they're interacting with?
Mozilla doesn't have the community goodwill to burn, it's hanging on by a thread - so not hiring someone with an idea if how to actually do that job would be penny wise pound foolish.
I understand people have sympathy inclination to victims, so everyone would assume the victim is good and other side is bad. I have worked long enough with japanese people knowing they can throw unpredictable tantrums.
As a manager, what would be your best course of action to deal with similar situation?
Life doesn't always have to be from the perspective from “a manager”, these are community volunteers doing untold hours of unpaid work. Just be a person, whose acquaintance is upset you replaced their handmade postcard with an AI-generated one.
Agree on manager view, I was rather putting situation in a wrong perspective. It doesn't change the questions though - what would you do to resolve the situation (not to make the other side feel good)?
This feels very wrong to me, I'm sorry, but I'd be very pissed if you told me such a thing in a personal context. Reminds of Stanley from The Office, who claims he never apologised to any of his wives.
I do, actually. You first read what the other person wrote. Then your response will take whatever they wrote into account. If they did not expressed themselves clearly, you explain what it is that you do not understand. The "We want to make sure we truly understand what you're struggling with." is wholly inappropriate if the only reason you do not understand is that you did not read what they wrote.
Second, you dont suggest the other person is struggling with something, unless they are actually struggling with something. The original post does not show someone struggling at all.
Tl;dr if you want to "openly discuss situation and possible resolutions" you dont start by ignoring what the other person wrote. This response makes it very clear that manager does not intend to openly discuss the situation or possible resolutions, the manager is not taking the complaint seriously at all.
Also, his demanding of not using his work for AI training is nonsense. Because entire articles, this one included is published under a Creative Commons license.
Didn't he agree on that?
Mozilla must reject his further contribution because he stated he don't understand the term of Creative Commons license. His wish granted I guess.
And
> Licensees may copy, distribute, display, perform and make derivative works and remixes based on it only if they GIVE THE AUTHOR or licensor THE CREDITS
The Japanese copyright law clearly stated decades ago and recent US court favors Anthropic on this regard.
Copyright isn't granted on mere information or thought.
If you take somebody's copyrighted writing, analyze it and publish information such as how many words or sentence in it or other information about that copyrighted work, that's not a derivative works of original copyrighted work.