Only specify one name
pserwylo opened this issue · 33 comments
I notice that you have both "firstName" and "lastName" as entries in the scehma. May I propose that this be amended to just a single name? This is in the spirit of "Falsehoods Programmers Believe about names".
In this case, the assumption that people have a first name and a last name is probably not suitable for resumes. If the goal is to have the ability to output a resume which uses their full name, and also only their first name, then perhaps a different solution is required. For example, a "name" (e.g. Peter Serwylo) and "preferredName" (e.g. Peter or Pete).
The final case which I think people may want to have separate first/last names would be so that resumes can be output with the surname first (e.g. Serwylo, Peter). I'm not quite sure of how to achieve this with only a single name unfortunately.
At any rate, the points in the article linked above are worthwhile considering, as are many of the comments people have posted to that article. Cheers.
It could be worthwhile to look at how Microformats do this in hCard. There is either fn for a representation of the “full name” or n, which is structured in more detail (given, family, prefix, middle name, ...). This could be mapped quite easily to JSON.
sorry guys, only saw this after I posted my issue, which is the same:
Shall I just delete it? Either way agree with this of course!
Yeah, just close for now if you could.
On Mon, Jul 7, 2014 at 7:48 PM, Andy notifications@github.com wrote:
sorry guys, only saw this after I posted my issue, which is the same:
Shall I just delete it? Either way agree with this of course!
—
Reply to this email directly or view it on GitHub
#4 (comment)
.
Thomas Davis
http://thomasdav.is
VP of Tech - Earbits - http://earbits.com
Co-founder - Cdnjs - http://cdnjs.com
Founder - Backbone Tutorials - http://backbonetutorials.com
here's some supporting info from my now closed issue:
w3.org has a great article on this (name fields):
"If designing a form or database that will accept names from people with a variety of backgrounds, you should ask yourself whether you really need to have separate fields for given name and family name."
Indeed. Name is one of those pesky things.
I'm not sure I like the hCard solution.
I was thinking something along the lines of a formalName (dictionary order) and name (full name, canonical to the local customs).
For "Robin van Persie" that might be:
{
name: "Robin van Persie",
formalName: "Persie R., van"
}
From the standpoint of an applicant, two fields for "full name" and a "preferred name" field, as in the W3 article, makes the most sense to me.
I don't know enough about being on the receiving end of resumes to know how important having a dictionary-orderable form of someone's name is, but as an applicant the two pieces of information I'd typically care about conveying are "what is my legal name" and "what should you actually call me".
I used the hCard fields from Microformats when I designed my resume's format:
https://github.com/stuartpb/stuartpb.com/blob/master/routes/resume/resume.yaml
Since the hCard fields are in 1:1 correspondence to vCard, they're the ones I feel are most valid, since vCard is the widest-supported contact info standard I know of.
Another case to consider is people who use their middle name and display it as "F. Middle Last", e.g. F. Scott Fitzgerald.
@wdoekes to me the proposal of name, formalName is introducing too much complexity without any obvious benefit. I think @pserwylo 's original suggestion of something like legalName, nickName (i.e. what name would you like us to use when contacting you?) both seamlessly handles localization issues without forcing the user to unnecessarily duplicate data.
And if we condense it even more, are there compelling reasons to supply more than a single name at all?
The email/phone contact thread skews towards one email and one phonenumber. It's the one you want to advertise to the employer. The same can be said for the name.
It's useful to have two name fields. A recruiter will often want to address you informally ("Hey Joe," rather than "Hey Mr. Joe Smith"), but with naming conventions from different cultures it can be difficult to infer what your informal name actually is (hint: it's not always your first name). Explicitly asking for those two name fields removes that ambiguity.
Having a full name is, of course, important for other reasons (contracts and such).
hey guys, agree with those who think we may be overthinking it.
The spec before was :firstName/:lastName. I think we all agree we should just replace that with :name.
In terms of nickname / preferred name / formal name / legal name, these should probably be part of some extension or module.
For example, the issue of what you want the recruiter/employer to call you, you can probably just sort that out pretty quickly when you e-mail/talk/meet them. Not sure we can capture all the complexity of human interaction in a single field!
Why was the issue closed? Has a fix been checked in?
@webmaven this issue hasn't been closed 😄 - #62 has (pesky Github interface).
@thatandyrose I think the problem with that is that in some cultures, ones legal 'name' has no bearing whatsoever on what people call you. I think we should still have :preferredName as an optional field for these people.
I agree with this. I personally think the schema should support a fullName field, which can override the first and last name fields. Some apps will only have that field and won't be able to necessarily reliably parse out the first and last names automatically.
At the same time, firstName and lastName can still be supported. OR, they can be renamed to givenName and familyName, which is what Gravitar uses and which is what the internationally accepted standards include. Either would work I think, but the former is more western-oriented and the latter is more internationally-oriented.
Gravatar entries look like this:
{ "name": { "givenName": "Ryan" , "familyName" : "Shea", "formatted": "Ryan Shea" } }
The Google Person schema supports schema.org and can be found here:
https://developers.google.com/schemas/reference/types/Person
The person schema at schema.org is here:
And here's the schema from portable contacts:
So I think we should move towards a solution for this issue so we can move the debate onto the other issues. For a lot of these issues there seems to be no right answer due to the complexity of the problem.
Honestly, after reading through everybody's comments I believe name might be the best choice for now. The main point to re-enforce here is that this schematic is not a be and end all of persona schematics. A persona schema, might have fields to specify givenName, legalName, tribalName but in the employee/employer context a full name field should be sufficient.
The name field obviously looses out when trying to search by last name, but with a decent implementation you should be able to split names intelligently enough to get results that are searchable by first and last.
So you could just do this:
{
"name": "Thomas Davis",
"firstName": "Thomas",
"lastName": "Davis"
}Where either "name" OR first and last are required.
Agree with @thomasdavis 100%. The issue here is firstname/lastname is too limited. Replacing it with name resolves that issue.
I think any other concerns about persona schematics is outside of the scope of this issue and should be opened as a separated - less immediate - issue.
fredsterss wrote:
I think the problem with that is that in some cultures, ones legal 'name' has no bearing
whatsoever on what people call you. I think we should still have :preferredName as an
optional field for these people.
After sleeping on it, I'm leaning towards this: name and optionally preferredName.
- It's optional.
- While I'm not immediately fond of the phrase 'preferred', something like 'informal' is less appropriate.
- It can make initial communication a little bit smoother, so why not?
I think we need to think hard about the most common use cases for using jsonresume. If that is to provide users with a way to store their own resume(s) in a structured manner and easily export that to various representations (pdf, html, etc.), then I'd go for name and optionally preferredName (personally I don't care much for the last one), because that will serve the need to get information about yourself across.
On the other hand, if we (also) lean strongly towards manageability of resumes by HR persons, recruiters, etc. and we want to emphasise searching and ordering as possible use cases for jsonresume, then I think it's important to be able to specify your lastName/familyName for those purposes.
Although I have plenty of ideas what one could do with jsonresume, to me, it's not clear yet why we're building this in the first place, what the canonical use cases are. This is important because it determines in large past your schema design :)
Experimenting with a new label called "Decision Needed", this issue has it applied. It means we will be passing something through in the very near future.
+1 for name
I would like to use Ursula Kallio or 高思俐, depending on my audience.
-1 for preferredName for the sake of simplicity.
+1 for name as well
+1 for name
Okay, looks like we have a winner.
name as type string will be added to the bio attribute.
I've removed the decision needed label and have now applied PR Needed. If no one gets to submitting the PR, I will do the commit later. Make sure to take the issuue #
Something like that? :)
Yep, looks good, I might get you to submit PR's for the next ones. I forgot that I have to setup some sort of change log process...
Ah right, sorry about that. Would've been more proper if I'd submitted a PR. Beginner-question: can you create PRs from the main repo itself (where I have write access), or do I need to fork it anyways?
It was actually my mistake, I said to do the commit lol You could push it to a different branch but a fork would probably be easier.
Doesn't make sens at all