Comments (16)
👍 for gender-neutral pronouns.
EDIT: Also, I agree with "they" :)
from acme-spec.
👍
from acme-spec.
+1 for "they" and "their". In my brief review of the current doc, the possible plural issue is not an issue, but I volunteer to do a more careful look as the draft proceeds.
from acme-spec.
Seriously? People put far too much into words. I can't believe this is the first issue reported. Such a joke.
from acme-spec.
Maybe I'm a traditionalist, but I prefer to follow the long tradition of using the masculine pronouns when the gender of the subject is unknown or ambiguous. This completely avoids the issue of the singular "they".
"Traditionally, in English, if the gender of a person was not known or ambiguous, then the masculine pronouns were often used by default (e.g. a good student always does his homework). Increasingly, though, singular they is coming to be used in such cases."
https://en.wikipedia.org/wiki/English_personal_pronouns#Use_of_he.2C_she_and_it
I would be willing to consider a PR, but would likely only merge if the ambiguities introduced were minimal.
from acme-spec.
Even better if we can rephrase sentences to avoid needing to use a gendered
pronoun while still being grammatical.
On Nov 18, 2014 11:41 PM, "bifurcation" [email protected] wrote:
Maybe I'm a traditionalist, but I prefer to follow the long tradition of
using the masculine pronouns when the gender of the subject is unknown or
ambiguous. This completely avoids the issue of the singular "they"."Traditionally, in English, if the gender of a person was not known or
ambiguous, then the masculine pronouns were often used by default (e.g. a
good student always does his homework). Increasingly, though, singular they
is coming to be used in such cases."https://en.wikipedia.org/wiki/English_personal_pronouns#Use_of_he.2C_she_and_it
I would be willing to consider a PR, but would likely only merge if the
ambiguities introduced were minimal.—
Reply to this email directly or view it on GitHub
#1 (comment).
from acme-spec.
Yes, people put far too much into words, but that is because words matter.
If some people feel excluded due to a particular choice of pronouns and it is not the project's intention, and someone is willing to make a pull request instead of simply whining and demanding it be changed, I would welcome their efforts.
Singular they for users and it for programs are preferred since it is the least obtrusive change. Rewriting the sentences takes a little more effort.
from acme-spec.
👎
I'm against. However if someone wants to waste their time on language-policing the fine manual, I couldn't care less.
I will submit all my PR's (I hope I'll have something to contribute) using the approach that @bifurcation mentioned. Then you can spend your time to adjust them or decline them.
from acme-spec.
I don't understand how this is still a thing that people can disagree with.
It's a zero-effort stylistic point that many readers care a lot about. Even free of context, that should be a no-brainer.
👍, obviously.
from acme-spec.
👍
from acme-spec.
@burke, "in matters of taste, there can be no disputes", so I won't comment on your version of "obvious", but it's factually incorrect to say that it's a zero-effort point - it takes 100% more effort to type "he" than "they".
Many readers also don't care about that point. What about them? What is happening is not that someone is creating PC PR's (as I said, I don't care, as far as I'm concerned I support that all of them be accepted), but trying to impose some style of writing on others.
This is not an "issue" because there is no issue and there won't be consensus because you cannot force me (and possibly others) to accept your view. Who wants gender-neutral language can create his own PR's and contribute to docs. At that point I don't see why project owners would decline them.
from acme-spec.
it takes 100% more effort to type "he" than "they".
Yeah, where that effort is a fraction of a second. It also takes more effort to not use single-letter variable names everywhere, but we don't do that either in code that is meant to be read by other people.
from acme-spec.
There is a pull request already. Once the language has been thoroughly neutralized (lol) let's close this.
from acme-spec.
@Rippler You might want to spend more time thinking about how to improve the project and less about how to annoy others and waste time intentionally creating pull requests which don't agree with a language standard.
+1 for this issue and I'm glad there is a PR out.
from acme-spec.
@titanous, @gordon-morehouse: First one of the PC guys above says it's a zero effort, then titanous contradicts him and says it's not (according to him it requires "a fraction of a second" to change a non-PC PR), but then gordon-morehouse contradicts the both of them by saying that creating PR requests that require a fraction of a second to "neutralize" would be a "waste of time" (as in "every second matters").
Since all you contradict each other, it seems I can't argue with any of you without contradicting myself, so I give up. Besides, I've just learned that this project has "a" standard, so we're good to go. Well done!
from acme-spec.
Fixed by 7c3ad0a.
from acme-spec.
Related Issues (20)
- 7.4 DNS Challenge *pre*pends label HOT 5
- 9.1 update outbound cxn methods HOT 1
- Differing description of {DVSNI, DNS} validation mechanism in 7.2, 9.2 HOT 1
- Add RECOMMENDED line to stronger DNS validation HOT 1
- Dns challenge signature is too long for dns TXT record HOT 6
- Specify type of "true" / "false" value for "tls" field. HOT 3
- .well-known ACME challenge files blocked 403 Forbidden in some Nginx configurations HOT 8
- method needed for forwarding *.acme.invalid to correct server HOT 3
- Register .well-known/acme-challenge with IANA HOT 2
- Describe 'validationRecord' (part of a challenge-resource) HOT 1
- Usage of RFC3339 - "5.3 Rarely Used Options" HOT 3
- Clarification on which spec to use HOT 2
- ASN1_mbstring_ncopy string too long with multiple alt-names HOT 3
- Domain validation and usage of userkey pair discussion HOT 1
- Travis integration may expose integration keys HOT 6
- http-01 and dns-01 challenges: just use account key HOT 1
- dns-01 walk-up HOT 1
- Letsencrypt behind a firewall with NAT HOT 4
- --agree-tos in ACME clients: acceptable or not? HOT 2
- Add alternate hostname for http challange HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from acme-spec.