#288 Add Marking Scales for non-USA Courses

[joshuarpearce]

#288

[DonDebonair]

Can we merge this one? I remember that there was consensus that grade is better than gpa?

[DonDebonair]

@evanplaice @thomasdavis what do you think?

[thomasdavis]

@dandydev I think we can keep it as gpa

I think the reason was

The Grade Point Average (GPA) is an internationally recognised calculation used to find the average result of all grades achieved throughout your course.

Grading in education is the process of applying standardized measurements of varying levels of achievement in a course. Grades can be assigned as letters, as a range, as a percentage, or as a number out of a possible total. In some countries, grades are averaged to create a grade point average.

Although it seems American, it is not meant to be.

[DonDebonair]

The quote says that gpa is internationally recognized, but at the same time #288 contains arguments that it isn't. I have only one data point, which is my own country. In The Netherlands we don't regularly use gpa.
I'm still in favor of using grade and making the type open (you can use string, number etc)

[thomasdavis]

Yeah, I prefer grade anyway, happy to bring it in. Let's do it!

[DonDebonair]

This one cannot be merged automatically, I will resolve it manually and merge. Probably tonight (GMT+2)

[stp-ip]

I do like score and a min, max, that can easily be shown as a percentage. That covers all min, max scales and the type being a free form covers explanation.

          "score": {
            "additionalProperties": false,
            "description": "exam score",
            "properties": {
              "best": {
                "description": "best possible score",
                "type": "string"
              },
              "type": {
                "description": "type of the score",
                "type": "string"
              },
              "value": {
                "description": "value of the score",
                "type": "string"
              },
              "worst": {
                "description": "worst possible score",
                "type": "string"
              }

[thomasdavis]

@stp-ip Makes a lot of sense.

Though over the five years it is quite clear that theme developers really value simplicity, and also a lot of people have been happy to keep their resume rather elementary.

[stp-ip]

@stp-ip Makes a lot of sense.

Though over the five years it is quite clear that theme developers really value simplicity, and also a lot of people have been happy to keep their resume rather elementary.

Great thing about this is that score and type are enough so it can default back to simple.
Same for theme developers. They can show a range, bar, percentage or just go with value + label aka type.

[DonDebonair]

I still think it's too complicated for the majority of use cases. In fact, I'd recommend that we call it grade as in the PR and make the type the JSON Schema equivalent of any. That way people can do what they want with it and themes can choose what formats to support. I suspect that the majority will just take the value of grade and print it as is

[stp-ip]

I still think it's too complicated for the majority of use cases. In fact, I'd recommend that we call it grade as in the PR and make the type the JSON Schema equivalent of any. That way people can do what they want with it and themes can choose what formats to support. I suspect that the majority will just take the value of grade and print it as is

Not sure I fully agree. Giving a framework with flexibility on what is being used > making free form fields do everything.
If we would go the full flexibility route we could say that currently optional fields are allowed so why introduce a grade field into the schema at all? (Exaggerating here, but in my mind what the various discussions over the years have shown is that a general schema, that can be used both with a few filled out values up to full detail might work better than having no strictness in place)

[DonDebonair]

I'm in favor of being specific and rigorous in places where the impact/significance of that part of a resume is big. But in all my years of hiring people internationally, I have rarely seen people specify their educational grades in a way more specific than just one value (be it a percentage, number). And to be honest, I've rarely seen people actually specify grades/scores at all.

And don't get me wrong, I acknowledge that being able to specify a grade is useful, and I also acknowledge that there is a variety of ways in which people might want to do this. But I strongly feel that we should not try to make a complex specification that tries to capture the myriad of ways in which somebody might want to specify their grade. That's why I want to give people all the options. To be honest, personally, I don't want to have to specify best, worst and value.

[stp-ip]

I'm in favor of being specific and rigorous in places where the impact/significance of that part of a resume is big. But in all my years of hiring people internationally, I have rarely seen people specify their educational grades in a way more specific than just one value (be it a percentage, number). And to be honest, I've rarely seen people actually specify grades/scores at all.

And don't get me wrong, I acknowledge that being able to specify a grade is useful, and I also acknowledge that there is a variety of ways in which people might want to do this. But I strongly feel that we should not try to make a complex specification that tries to capture the myriad of ways in which somebody might want to specify their grade. That's why I want to give people all the options. To be honest, personally, I don't want to have to specify best, worst and value.

Thanks for giving the context.

Personally had various requests or feedback especially internationally, where a grade format wasn't widely known and hiring internationally was easier with a percentage number or at least have an ability to visually say great, good, not good etc.

The great thing about the schema being in the background is that not everything has to be exposed, but having it set even just to set a precedent would be good in my view.

Only setting value and assuming a context of it being GPA is fine, so is adding an additional type or for other type of scenarios a range. The specific idea to use score instead of grade was the re-usability of the scores for various parts of the schema. It makes it easier for theme developers to reuse design and tooling.

[DonDebonair]

I'm not hung-up on the term grade. I think gpa is too specific, but I can totally see how score is nicely reusable.

With regards to the JSON Schema type of score: I'm really trying to prevent overengineering here. I think the majority of people are going to be confused when, instead of this:

{
    "score": 5.3
}

they have to fill in this:

{
    "score": {
        "value": 5.3
    }
}

And that would only be so we can support what feels to me as edge cases.

I don't think @stp-ip and me are going to come to a consensus there, so I propose @thomasdavis makes a decision and we both live with it :)

[stp-ip]

I think we sort of agree on a few things so.

For example I agree that score and/or type are the fields that are most important. Difference is I think the schema should be a bit wider than the normal use case and let the ecosystem tooling handle the easy to use cases.

Aka the schema could accommodate the full score object, but 90% of the editors might only expose "score" the field and that is fine, but having a rule set within the schema for the other 10% makes the overall usefulness of the schema bigger in my view.

Totally agree, that we can't do this for everything, but especially with the reusable nature of score, it might still make sense.

Happy to hear Thomas's thoughts :)

Sidenote

[thomasdavis]

+1 in my experience in hiring, the grade has always been easily conveyed or non important.

More often than not we will stick with strings over flexibility, the only thing holding the ecosystem together is the simpleness.

If people absolutely require more complex fields, they are free to do so, by a) forking the theme they want to use and updating it and b) adding their fields as they wish to their resume.json. By virture of the entire project being open source, they could fork everything.

Until a mass of people have pitch forks burning down the README I think we can err on the side of basic.

As for grade vs score, I did feel score for a bit, but believe we should stick with grade.

education.grade
certificate.grade
test.grade 
training.grade

education.score
certificate.score
test.score
training.score 
```

I think grade sounds better in general. 

Happy for more comments before we decide.

[DonDebonair]

ok, so for now: "whateverthenameis": "string"

Regarding the name, I'm actually starting to lean more towards score because of your examples @thomasdavis 😂 training.score and test.score sound better than training.grade and test.grade. For education.score vs eduction.grade I'm a bit on the fence, but the others pull me towards score.

If we can come to an agreement on the name of the field, I will adjust the PR, resolve conflicts and merge.

[stp-ip]

Would love to get a maintainer call done before merging, but definitely not opposed :)

In my non native english speaker mind grade is more tailored towards school compared to a score, that could be for a certificate, training or the like.

[DonDebonair]

In my non native english speaker mind grade is more tailored towards school compared to a score, that could be for a certificate, training or the like.

But if we want to choose one for education, training, certificate and test, to keep consistent, which one would you choose between grade and score?

[stp-ip]

In my non native english speaker mind grade is more tailored towards school compared to a score, that could be for a certificate, training or the like.

But if we want to choose one for education, training, certificate and test, to keep consistent, which one would you choose between grade and score?

score

[DonDebonair]

I tried to fix the merge conflict, but it pulled in a lot of commits.
I'm also trying to figure out why the tests fail now.

[DonDebonair]

I've created a new PR with the same change but also with passing tests and no merge conflicts. Have a look at #391

[DonDebonair]

Fixed by #391