Hacker News Reader

Comment by alwa | Hacker News Reader

I did as you suggested with respect to “nemawashi.” I read about that and “ringi,” and I’m glad I did. Even to get just the gist of what I’m sure is a thin interpretation: that nemawashi refers to a “laying-the-groundwork” process of circulating a proposal between peer-level counterparts, before formalizing it and proposing to act on it.

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…

View on HN

common sense... no real need for digging into japanese culture and so on. really no idea why Mozilla is so disrespectful to it's volunteers. well, that sweet 400m a year from Google... no need for volunteers anymore, eh

For sure. Common sense <> common, etc… although it does seem relevant that it was specifically a Japanese-language sub-community who were reacting here.

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.)

Enlightened despotism, all over again.

mixed with good ol' white-man-saviour attitudes.

That reminds me of internet RFC’s… like by the time they are formally published, no the author is not interested in your “comment”.

I've written a few RFCs.

For any RFC, there will be a "comment" after publication from someone who did not take earlier comments seriously enough to read them.

Exactly the attitude described by GP comment

Mind boggling

You may be relieved to hear that there's a straightforward process to have an RFC revised. Step 1 of that process, however, is reading the the RFC and the archived email about the RFC.

You can't just arrive after publication, ignore what others said before you, and expect anyone to listen to you.

…and, for that matter, there was an earlier draft phase where the author was R’ing For your C. And you could have jumped in then and been more-or-less welcome.

Sounds like RFC ought to be the name of that draft phase, rather than a name encompassing all phases, especially not the final phase in which C's are no longer R'd.

Times changed. Historical names did not.

"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

RFCs can be titled Architecture Decision Records (ADRs) or policies once they are accepted.

Historical precedent. They assigned a grad student to write up the notes; he wasn't sure he had got everything, so he titled it an RFC.

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.

We Americans call this garnering buy-in.

I’ve more typically heard it as “consensus / coalition building” - but in any case it’s such a sane way to work. No one wants a rude surprise, so why make one for your teammates.

> It puts a name to a considerate consensus-based way to approach change

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 predict that these times of excessive trust in AI during decision making will be written in history books at some point of time. Providing that there will be books at all.

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.

Reply on news.ycombinator.com