Date: Thu, 26 Sep 2024 02:00:02 +0000 From: bugzilla-noreply@freebsd.org To: doc@FreeBSD.org Subject: [Bug 266357] cripple (pejorative) in doc and src trees Message-ID: <bug-266357-9-cZMP1tx6OD@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-266357-9@https.bugs.freebsd.org/bugzilla/> References: <bug-266357-9@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D266357 --- Comment #11 from Chad Jacob Milios <milios@ccsys.com> --- (In reply to Ceri Davies from comment #9) I completely agree with Ceri that there is no reason not to -e s/crippled/broken/g;s/cripple/break/g across the entire codebase. I'm sorry= I did not make that abundantly clear sooner than today. This is one very simp= le case where we can easily improve the inclusivity and civility of the projec= t. I completely agree with Dru Lavigne that technical accuracy is paramount an= d I can see no reason that this proposed change should reduce the fidelity of t= he documentation. An example or reference mentioned "will result in denied connections" and t= he memory that invokes for me is adjusting one's firewall remotely from the command line. A "jarring" (bad word choice of mine in #3; I wasn't saying we should insult our users.) warning is always best because if to deny some connections and allow some connections is what you intend, then by the suggested text alone one plausibly might fail to realize they are holding a gigantic foot-gun. Of course that warning can just as easily become "will result in denying all connections". OTOH, "cripple" stands in for 5 of 6 words there and [imho] adequately so w= hen the context sufficiently supplies all the technicals. I don't know about y'= all but I read/skim enough technical jargon as it is in one day to give an arac= hnid cataracts. However, I would never stand in the way of this particular change proposal. When I said #3 I was probably going through something. Oh yeah, I felt some typa way after the master/slave debacle swept through open source years bac= k. While it works that Unbound switched to primary/secondary, I know of at lea= st one system I support that requires the slaves be online and responding _bef= ore_ the master rounds them up to kick off the show. (a performant, not h.a. sys= tem) So, I opted to reject ambiguity and pray the mob passed over me rather than invite any additional support calls from confused clients to placate the mo= b of the day. Sure, if pressed, we could've come up with some other vernacular t= hat avoided contradiction in the documented procedure but thought to myself "How far must we erode our language? We're going to be communicating in grunts a= gain soon." I know the slippery-slope argument is always a logical fallacy when applied= to any single and particular case. That being said, it *is* indeed a valid gen= eral argument in the hypothetical sense. I would invite everyone to enjoy this t= en minute insightful and empathy-rich segment about "soft language" from [imho] the greatest philosopher of the modern era, George Carlin: https://youtu.be/-ZAo_dUbh9s (NSFW, rated PG-13) --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-266357-9-cZMP1tx6OD>