Skill levels should have pre-defined values.

[buraksarica]

So that resumes would easily be filtered.

[tborychowski]

+1; or numerical values (percentages?), e.g. 10 - noob 50 - working knowledge 80 - master 100 - god

[wdoekes]

I think you may be overspecifying things here.

And remember scio me nescire: you cannot compare values between different people who self-specify their skill level.

[tborychowski]

@wdoekes Completely agree - you shouldn't compare people like that. But it could still be helpful. E.g. if Ann says her spanish is 10 - I will not hire her as an interpreter, but Tim's spanish is 90 - so he might be a better person...

Anyways - my primary idea was just for styling purposes, e.g. one might present their skills with some sort of progressbars or icons which would be impossible without a standard...

[qwertzguy]

+1 for numerical values. Percentage seems a good scale. However it could come in addition to the level string. So it could be in levelPercentage. Also, it would be really great to have an experienceYears field, as this is a more objective self-assessment of the level and very frequently asked by recruiters.

[vote539]

Giving yourself number grades for your skill level is very subjective. If there are two equally competent JavaScript developers, one might give themselves a 70 and the other might give themselves a 90. I feel like word-based is less precise and therefore less likely to be valued differently.

I do think, though, that there should be a standard dictionary for skill level strings. Letting people invent their own words isn't going to be particularly helpful.

[buraksarica]

Guys, because it is autographed, resume itself is a totally subjective thing. But if i have to deal with hundereds of resumes, i may need help just for filtering and having a set of tens of resumes. So having a pre-defined set of words for competence (may be some explanation with them in docs ) will be ok.

[ocram]

Maybe this results in your applicants giving themselves even better grades and your automatic review process failing even more.

Anyway, the larger the number of possible values, the higher the effect of subjectivity. If you give people an "enum" of five possible values, there is less room for variations.

I feel like word-based is less precise and therefore less likely to be valued differently. (vote539)

One might say this is overspecifying things. But I think it's helping people a lot, who would not know what exactly to type in a plain string field without any requirements.

[wdoekes]

But I think it's helping people a lot, who would not know what exactly to type in a plain string field without any requirements.

That's a compelling argument. But then I'd lean towards even fewer than 5 levels. Something like: beginner, competent, proficient, expert (or differently phrased). Based on the assumption that people will be likely to vary their responses, I'd expect there to be more variation than if they just used numbers or a larger variety of skill levels.

On the other hand, if we use numbers, the employer could achieve a similar effect by equalising/balancing the levels before using them in a comparison.

As for @qwertzguy's suggestion:

Also, it would be really great to have an experienceYears field, as this is a more objective self-assessment of the level and very frequently asked by recruiters.

Sounds sane.

[ocram]

So what about:

"level": {
    "enum": [
        null,
        "beginner",
        "competent",
        "advanced",
        "expert"
    ],
    "default": null
}

With different phrases, maybe.

[buraksarica]

My idea is smth like @mwaclawek's suggestion. +1

[DonDebonair]

+1 for enum. No numbers, that's opening a can of worms.

[thomasdavis]

I wonder what impact having predefined values in the spec will have on our ability to do i18n across the ecosystem.

I don't think we can tackle this issue from the prospect of database indexing. I'd rather see ways that empower people and theme developers the most.

[ocram]

@thomasdavis I agree that any pre-defined value or required format is bad for i18n. It's similar for the countryCode (Europass has an additional Label here) and the pre-defined key(s) in websites/profiles.

Anything that is not fully customizable by the user, i.e. anything other than plain strings without format requirements, will make i18n harder.

Maybe the skill level should rather be a plain string as well, allowing the user to describe themselves in their own words, and giving "beginner", "advanced" and "expert" as examples in the description.

[DonDebonair]

I'm inclined to agree with @mwaclawek . Make skill levels a simple string and provide examples of skill levels in which we make clear that it should probably not be numerical.

[osg]

+1 for "mwaclawek commented on Jul 13, 2014".

[aloisdg]

Is nullreally needed? If you have a skill at the level null, why bother writing it in th resume?

[osg]

@mwaclawek correct me if this is inaccurate, null does not mean that that person's skill are "null"; it means that they decline to disclose the level for some reason.

[stp-ip]

@aloisdg @opensourcegrrrl I would say that null is just a not disclosed skill level. Could be used as defaults for themes, as placesholder in editors etc..

[aloisdg]

I understand more now. Therefore, I think the default placeholder should be beginner, but this is not a concern for the spec. Thank you :)

[stp-ip]

@aloisdg I would say beginner as default could be wrong. Imagine someone just not disclosing any level for all their skills. This would lead for them to be a beginner in all of them instead of them just being no skill level at all for that skill.

[aloisdg]

@stp-ip you are right.

[osg]

-1 for beginner for being the default for reason in my previous comment.

[aloisdg]

-1 too (is it matter?)

[stp-ip]

Just to revisit the whole discussion with m own point of view.

• numerical values make it more subjective
• predefined levels are bad for i18n
• predefined levels make it easier for all participants

Therefore I think we should go for predefined values as @mwaclawek suggested:

"level": {
    "enum": [
        null,
        "beginner",
        "competent",
        "advanced",
        "expert"
    ],
    "default": null
}

How to solve i18n with predefined values is not just needed here, but in other places too. So we need a solution anyway. Reducing the ease of the schema seems imperfect.

[aloisdg]

Can we use "early" too.

I use and read Python sometimes. I never release a project with this techno. I am an early dev. I just start to learn F#. I would love to use it more. I am a beginner dev.

What I propose is we have beginning coders and early coders. I got this idea from a painting teacher who kept referring to students who had never painted as “beginners”, but those who had painted for about one class as “early”.

Early vs. Beginning Coders by @zedshaw

It would look like this:

"level": {
    "enum": [
        null,
        "beginner",
        "early",
        "competent",
        "advanced",
        "expert"
    ],
    "default": null
}

I will add that this addition is not dev-centric. It can be use everywhere.

[olivif]

Let me give a counter-example to the levels. There are people who have very specific skills that might not fit into the enum above. Or rather, they would fit, but they would not mean as much as a different keyword would, that is specific to that skill.

Wine tasting professionals for instance

skills: [
    {
        name: "Sommelier",
        level: "Level 1"
    }   
]

I would much prefer what @mwaclawek said here

Maybe the skill level should rather be a plain string as well, allowing the user to describe themselves in their own words, and giving "beginner", "advanced" and "expert" as examples in the description.

I think we are losing some flexibility with the enum and it is not really clear to me what we are gaining. If the goal is to make it easy for people to fill in the resume, I think having the levels as an example in the description should be sufficient, as opposed to enforcing it in the schema. I am willing to be convinced otherwise though :smile:

[osg]

Another counter example from my own human-language skill levels:

English Native Finnish C1 Spanish C1 German B2 Mandarin A2 Hungarian A2

The levels are defined per https://en.wikipedia.org/wiki/Common_European_Framework_of_Reference_for_Languages.

These levels would never apply to programming languages.

[aloisdg]

I think we are losing some flexibility with the enum and it is not really clear to me what we are gaining.

We loose flexibility for coherence. (It is not necessarily good)

Imagine a HR who want to look in a database for every employees who has a level in "skill name" where "skill level" is superior than "enum value".

With a blank string, it will be difficult to parse, isnt?

[aloisdg]

@opensourcegrrrl We have languages for this case (with its own discussion #34 ). We could remove it and use skills for languages, but I dont really like this idea.

[osg]

@aloisdg Thanks, got it.

[stp-ip]

A few possibilities:

• predefined levels (less subjective, machine readable, inflexible)
• numeric levels (subjective, machine readable, flexible)
• numeric levels + string level (subjective, machine readable, flexible)
• string level (subjective, flexible)

I vote for either predefined or numeric + string level. Machine readable/search-able is something I find quite valuable.

[aloisdg]

@stp-ip I prefer a predefined levels. It feels clearer and easier.

By the way a predifined level can be easily convert to a percent or anything if you really want. I dislike percent because it allows to use more sub level without clear meaning.

label	star	n%	Closing an issue with this skill
beginner	★☆☆☆☆	20%	I will teach you how to do it
early	★★☆☆☆	40%	I will help you to do it
competent	★★★☆☆	60%	I will follow how you do it
advanced	★★★★☆	80%	I will be there in case of trouble
expert	★★★★★	100%	I will be there when it is ready

Edit:

The issue's column was written based on my short experience.

[chrisdotcode]

So, guys, an enum or a free-form string is winning simply because we like machine readability.

10% is not quantifiable (10% of what?), whereas "beginner" certainly is. Now, it is true that constitutes a beginner is highly subjective, but an enum IS machine readable, and most people are comfortable and can honestly rate their skill level on a beginner - expert spectrum far more easily than any alternative.

Failing that, we forgo any attempts at being machine readable, and go full-subjective with a text field.

I personally think an enum is the way to go, and the "hard part" about that is choosing what we call the levels.

[chrisdotcode]

I really like @aloisdg's quantifications of the skill levels, and if we choose this route (I think "beginner" and "early" (and "advanced" and "expert") are the same thing, though), we aught to document those descriptions somewhere.

As a matter of fact, even if we don't quite agree on what to call the fields, if we can agree on the descriptions of the levels, then that's all we need - because we have now semantically specified skill level. That being said, I don't 100% agree with @aloisdg's level descriptions either, but it's a fantastic start.

[aloisdg]

@chrisdotcode Thank you! Feel Free to change it. If you want to know more about the difference between beginnner and early : Early vs. Beginning Coders by @zedshaw.

[stp-ip]

My proposal would be to have defined levels within our documentation as @aloisdg provided:

level	label	star	n%	Closing an issue with this skill
0	null	not provided	not provided	not provided
1	beginner	★☆☆☆☆	20%	I will teach you how to do it
2	early	★★☆☆☆	40%	I will help you to do it
3	competent	★★★☆☆	60%	I will follow how you do it
4	advanced	★★★★☆	80%	I will be there in case of trouble
5	expert	★★★★★	100%	I will be there when it is ready

This way we could make it machine readable and possible to localize. We would have something like the following within a resume:

skills: [
    {
        name: "Sommelier",
        level: "1",
        label: "beginner"
    }   
]

In the schema itself we could have the level be an enum from 0-5 and label and name would be a string.

I would love to decide on this slowly, so we can move it into a PR needed state.

[aloisdg]

Some points:

• The level as label is enough. I dont think we need more than the enum.
• "Closing an issue with this skill" is here as an idea, nothing fixed.
• Should we use null or undefined?

[stp-ip]

So your suggestion would be:

skills: [
    {
        name: "Sommelier",
        level: "beginner",
        label: "Anfänger"
    }   
]

"Closing an issue with this skill" is here as an idea, nothing fixed.

The idea is nice and we can easily refine it even after v1 as it's mainly documentation.

Should we use null or undefined?

null vs undefined needs more input from others I think: @chrisdotcode @olivif

[osg]

@stp-ip How about instead of null or undefined it is unprovided, and unprovided across the board.

[stp-ip]

@opensourcegrrrl seems this would be the most generic and non language (JSON, YAML) specific. +1 for unprovided

[olivif]

@opensourcegrrrl I like unprovided.

@stp-ip I like your table and I think this is a good trade-off between flexibility and machine readability. This solves my counter example while it's easy for theme creators to use and machines to aggregate on.

What I am concerned about with this example is that you can provide inconsistent information, like so.

skills: [
    {
        name: "Sommelier",
        level: "1",
        label: "advanced"
    }   
]

But it's not a deal breaker, we can have custom validation for this if needed. Or we can even allow users to set one of the fields (level for instance), and we auto generate the others.

[aloisdg]

you can provide consistent information

inconsistent I guess ;)

flexibility and machine readability.

Enum are perfect for machines and humans.

I think we should remove the number level and rename label as level.

[stp-ip]

Without label, we would remove the possibility to localize. I am alright with having the level be an enum with the standard levels instead of a numerical one, but I think a label, even if optional, is necessary.

[thomasdavis]

I love the suggested static values but feel like they might be too presumptuous across different industries.

I would imagine that we as a community/project have unwritten guidelines about what we encourage but not limited to them as such.

Pretty torn on this issue though because uniformity sometimes works incredibly well.

[aloisdg]

@stp-ip JSON is in english. We have to deal with it. cli/app/template dont have to be english. If someone is a the db aka the json here, he should know a bit of english.

I love the suggested static values but feel like they might be too presumptuous across different industries.

How so?

I would imagine that we as a community/project have unwritten guidelines about what we encourage but not limited to them as such.

As a standard, I think we need some guidelines.

[phumke]

I'd say stick with the numeric level and push the label out to the visualizer. Standard naming could still be used and it allows localization.

I'm iffy on unprovided. If 0 is actually entered into the schema than it has been provided by the user.. It might be a nitpick, but it could be confusing.

[aloisdg]

• An int mean's nothing without documentation.
• Enum are awesome for readability.
• Enum allow localization without any kind of trouble.
• Enum are bascially pretty int.

[phumke]

@aloisdg Sounds good. I like the enum, it provides a tightly coupled value and meaning and solves the issue of someone entering 1 and advanced. I didn't realize enums can be localized.

+1

[aloisdg]

@phumke enum are only for the json. The work of the localization should come from the template. But an enum as an obvious meaning even if you read it directly in the json. An enum is just a bunch of int with a pretty name. It is very handy.

[stp-ip]

I think we can agree on non numeric enums for the level. But I would still think a label field would make it easier to localize on the data side. I can see, that it could be seen as display information and not data.