Missing personnel master data

[ocram]

At least in Germany, it's standard practice to include a short section of personnel master data at the top of the CV.

Example:

Name = John Doe
Birth = 6th December 1980 in Berlin
Citizenship = German
Family status = married
Children = two (6 and 12 years)

Although that might not be common in other countries, could this be added as an optional section?

Example:

master_data: {
    name: string,
    birth: {
        date: integer,
        place: string
    },
    citizenship: string,
    family_status: string,
    children: [{
        gender: string,
        birth_date: int
    }]
}

[vote539]

I think adding these fields to the bio section may be a good approach. Not all fields can or should be required. For example, not everyone is going to list children, but if someone adds their children to the Bio section, then the templating engine should figure out how to display that in the final PDF. I think we should err on the side of standardizing too many fields rather than too few.

[ocram]

Yes, definitely, I wanted to propose the addition of master_data to the bio section. Actually, I meant it to be a separate section, but one could certainly include it just under bio.

I think we should err on the side of standardizing too many fields rather than too few.

Yes, I agree. This is what makes a good standard. Too many (optional!) fields is no problem. Too few is.

[osg]

This must be optional, because it is illegal to require people to provide marital status, for example, in applications and interviews in the US, and the resume/CV follows from that logic.

[ocram]

Of course, it's meant to be optional.

However, in JSON Schema you don't specify optional attributes but you specify required ones. We haven't done this yet.

[osg]

Great, sounds good. Many people do not realize what is legal or illegal to ask in applications and interviews in the US.

Thanks for the added info about specifying required attributes.

[wdoekes]

While I agree that when you do want to specify these things, you'll want to have it standardized, I also feel that these properties do not belong on a resume.

These are criteria typically used to discriminate -- in the bad sense of the word. (Age discrimination, gender, descent based, less overtime because of obligations to family, etc. etc.)

P.S.1. This opens up the question of which enum to put in the family_status field.
P.S.2. Where is the gender field? And do we want to open up the can of worms in that?

Can we circumvent this by adding a notes property to the bio field where you may describe gender, kids and marital status in free-form if needed. Or would the german resume be unusable?

[ocram]

I also feel that these properties do not belong on a resume

That's highly subjective. In Germany, it's common to provide these pieces of information and accepted to ask for them.

These are criteria typically used to discriminate -- in the bad sense of the word. (Age discrimination, gender, descent based, less overtime because of obligations to family, etc. etc.)

Unfortunately, that's what they may be used for. But should it be this open-source project's task to fight social issues -- or should this project concentrate on providing users what they need to get their resumes done? Ultimately, it's up to the user to decide which data to provide. But a specification should not prevent use cases that are absolutely valid.

This opens up the question of which enum to put in the family_status field.

We can just as well make this a plain string. That seems to be the way this project goes for i18n issues, and it makes sense.

Can we circumvent this by adding a notes property to the bio field where you may describe gender, kids and marital status in free-form if needed. Or would the german resume be unusable?

Actually, yes. These pieces from free-form data will always appear different than the other records in your resume. For example, a template designer may consider adding bullet points to each record, causing your huge free-form "notes" section to have only one bullet point and thus appearing completely different, resulting in an unprofessional CV.

The specification currently lacks these fields preventing it from being used for a proper German CV:

"citizenship": {
    "type": "string",
    "description": "optionally provide information about your nationality, e.g. Canadian"
},
"maritalStatus": {
    "type": "string",
    "description": "optionally provide information about your civil status, e.g. married, single, divorced or widowed"
},
"birth": {
    "type": "object",
    "description": "optionally provide information about the date and place of your birth",
    "properties": {
        "date": {
            "type": "string",
            "description": "e.g. 1970-12-31"
        },
        "place": {
            "type": "string",
            "description": "e.g. London"
        }
    }
},
"children": {
    "type": "string",
    "description": "optionally provide information about your children, e.g. number of children and their age"
}

[DonDebonair]

We could make them optional and make it very clear in the description that in some countries it's illegal for an employer to ask about this.

[TimDaub]

We could make them optional and make it very clear in the description that in some countries it's illegal for an employer to ask about this.

+1

I'm from Germany too. Your Birthday is required on a resume here.
For everyone who feels like he is getting discriminated because of this age can just leave the birthday field empty...

[DonDebonair]

I haven't seen any +1s for almost 2 months now, which gives me the feeling that there's not so much need for this after all? Can we close this @thomasdavis?

[ernstkui]

+1, its pretty much mandatory in the Netherlands. Just google "nederlands cv", first 13 image hits contain this data.

[thomasdavis]

@dandydev I feel like we might include a new dynamic field type to support specific use cases like this and call it extensions or something. Obviously it will solve a bunch of our other problems too.

[DonDebonair]

I have been thinking some more on this, and I feel that:

But should it be this open-source project's task to fight social issues?
Yes, open source is about pushing boundaries outside of the confines of corporate and societal constraints.
I might be opening a can of worms here, but I feel it is really bad if we start providing companies with tools that are there for the sole purpose of discrimination. Providing birthdate and gender for instance, serves no other purpose than giving employers a way to "pre-select" candidates.

So I stand by my original reasoning:

We could make them optional and make it very clear in the description that in some countries it's illegal for an employer to ask about this.

That means, whatever form we give it, I feel a warning is in order :)

[osg]

+1, @dandydev

[aloisdg]

+1 @dandydev

[JD-Robbs]

+1 @dandydev

Albeit I utterly disagree with this practice, it sadly is how CVs work in Germany (and, to my knowledge, Austria, Switzerland and Netherlands as well).

[JD-Robbs]

@mwaclawek Just to extend on that - this would also need to be able to account for dual citizenship. I.e. turning that property into a collection of 1-n citizenships. While that may not be necessary for most - I know a number of people falling into this group.

Edit: Mea culpa - this is already in the draft. 😃

[chrisdotcode]

The schema only cares about data. A warning, if provided, isn't necessarily the job of that schema. That responsibility should be pushed to the consumers of the schema, that is, the theme creators. Again considering that some of this is locale specific, we shouldn't necessarily add it for those locales that don't need this sort of information.

What I do propose, however, is an optional schema section that can consist of any values, that theme implementors can use when generating locale-specific themes. This is isomorphic to @thomasdavis's extensions suggestion.

[stp-ip]

A warning in the schema just makes it easier for theme developers to notice, which might be a good idea. Nothing too fancy for such a notice so.

As local data is just additional data, which is still available in other locales, I would use an additional info section, which can be extended, but has some predefined items available.

[aloisdg]

As suggested by @dionysius, we should add a field for:

mobility (driving licence [category xyz], train season ticket, ...)

source

[dionysius]

ty for mention me @aloisdg

to make the use case a bit clearer i suggest as example:

"mobility": [
  "Driving licence XYZ",
  "Train 1/2-price yearly ticket"
]

I see this field as an array of strings: 0..n elements

[StevenBlack]

schema.org may provide helpful taxonomy here.

• Person
• Permit

And others.

[mudassir0909]

+1 for

I feel like we might include a new dynamic field type to support specific use cases like this and call it extensions or something. Obviously it will solve a bunch of our other problems too.

This way we can keep the original schema lean & provide these additional add-ons on demand

[dionysius]

-1 for

I feel like we might include a new dynamic field type to support specific use cases like this and call it extensions or something. Obviously it will solve a bunch of our other problems too.

Might be true for the "problems" part, but for the "standards" part this might be a problem. Because resume-schema is supposed to be (let me cite) JSON-based standard for resumes, so when there is a "well" standard, its easy to write tools to filter data on these json data.

If you have thousand of different "add-ons", how do you filter or sort them? It's nearly impossible to address the definitions which come by these add-ons.

resume-schema has only a chance to really become a "standard", if it addresses exactly this issues well

[aloisdg]

-1 for extension too. You can choose to not fulfill everything. It should be enough.

[stp-ip]

There is always the possibility to add fields somewhere and try to get it upstream, if it is actually useful for the standard. With extensions you don't need to get the change upstream as this would kill the extension. So I would try to close down the standard for v1 as best as we can without killing of generic uses. In addition enable workarounds, which work, but make it clear that, if actually necessary going upstream would be best.

Hope that makes sense.

[aloisdg]

@stp-ip I agree with this.

[dionysius]

agree

try to close down the standard for v1 as best as we can without killing of generic uses

[aarnaud]

+1 for birth

[alisterlf]

+1 for add birthdate on schema.
In Brazil is extremely common to resumes have birthdate in it.

[thomasdavis]

After careful appreciation, I think that this extra national data shouldn't be in the schema.

There is room to build packages on top of what exists to support these peculiarities.

(custom translated themes/resumes, meta property)