Projects and Event Categories Implementation

[chrisdotcode]

There's a category for work, and one for volunteering. Projects and events (and any others) would likely be implemented in like.

There are several ideas about how these sections will be implemented already. This will be the compilation of those past discussions, and the place for new discussions.

cf. #166, #11, #200, #123, #138

[stp-ip]

In my draft overview #193 I distilled it down to:

• work
  • work 1 (item of work)
    • project 1 (item of work.work.projects)
    • client 1 (item of work.work.projects)
• projects
  • project 1 (item of projects)
    • fundraiser 1 (item of projects.project.activities)
    • project 1 (item of projects.project.activities)
• events
  • conference 1 (item of events)
    • talk 1 (item of events.event.talks)
    • talk 2 (item of events.event.talks)
  • fundraiser 1 (item of events)

[chrisdotcode]

I like the addition of a nullable client field in work. Should it be a list of clientelle, instead of just a single client?

The name of the project field you have for both work and projects is a little ambiguous. What does it mean?

Also, let's try to be more generic: not every event is a conference or fundraiser. And let's still not forget about volunteer work.

We're on the right track, though, certainly.

[stp-ip]

Work items can have projects and projects can simply be used as clients depending on the work. See here: https://github.com/stp-ip/resume-schema/blob/2015-draft/schema.json#L168

Being ambiguous was by design to be able to use it for clients, internal projects, products etc. for work and in a similar way for projects.

Volunteer work would be summed up in projects, as not every non-work item is volunteering work, but all volunteering work could be summed up under projects. That's why a non-profit boolean was introduced for projects: https://github.com/stp-ip/resume-schema/blob/2015-draft/schema.json#L263

I agree that not every event is a conference, but that's why the item in itself is just an event. Events can then have talks, which would be used by conferences etc.
https://github.com/stp-ip/resume-schema/blob/2015-draft/schema.json#L504

[chrisdotcode]

I sense overlap between .projects and .highlights. Let's try to think of a unified term that means "tasks accomplished". Personally, I do prefer highlights, because you don't need to annotate every single thing you did at every job ever.

I also feel that the projects and events sections might be able to be merged. Having a talks field is too narrow a focus. While that may be somewhat normal in our field, if we want jsonresume to be the resume standard, we also have to consider the plumber, the electrician, etc.. For this, I think we should find a combination of your project and events field that means "things that I did outside of my day job". On my own personal resume theme, I called this field community.

+1 non-profit boolean, but we'll have to rename it. non-profit has a legal meaning, in addition to possibly meaning "work provided for free". Maybe a "type" field that can be something like non-profit|pro-bono|paid.

[stp-ip]

The thing is one can do highlights at a client or in a specific project and especially outside our profession long term employment is a thing. 10 years at one employer can result in 5 projects. in 2 years per project there can be quite some highlights to report.

If only highlights are used, one has a work item, with one project and then lists the highlights. Much more difficult to use highlights for clients/projects.

Even a plumber or electrician could go to exhibitions or other work related events.
Therefore I would not merge events and projects into a community item.

Perhaps with the events section we should not say talks, but something more ambiguous. I would not remove it as in science and even in other professions presentations, talks etc. can be quite important on a resume.

Probably a good thing to not force a legal meaning, but provide a more generic type field.

[chrisdotcode]

So then how about a merging of projects and highlights into tasksPerformed (or something better named)? That reduces clutter, and allows you to list more than just highlights.

I'm more concerned about jsonresume being generic than I am limiting a certain field: so it's not that we should take away the ability to note professional presentations, we should make that field generic enough that it can be used with multiple professions.

I don't know if we call it community, but outside of tech, going to an event literally does or means nothing for one's professional experience. Other professions do have professional training seminars that they go to, which is comparable. We should make whatever field generic enough for at least events and/or training, if not events + training + projects.

[stp-ip]

Thing is with various professions, when a project actually means client, one wants to list some highlights. Merging them won't work and client work is quiet generic in my opinion.

I would have said training would be an event too and so would seminars. Still don't think projects are the same.

Almost in all scientific professions conferences and seminars are quite important. So is for students and as you said training in other professions.
That should validate the events section in my view.

[chrisdotcode]

Here's what we should do at this point: we should start throwing out some examples schemas for different professions, and see how they look with suggested changes.

And if they look wrong, we iterate on them.

[stp-ip]

I think before doing that extra work we should get some feedback from @aloisdg @KOLANICH @PeterDaveHello on the general direction to cut away some of the ideas and then move into iteration mode.

[stp-ip]

And I forgot @JD-Robbs

[chrisdotcode]

I think they can be done in tandem. Here's my thoughts:

work: [{
    "company": "Carpenters-R-us",
    "position": "Carpenter",
    "date": ...,
     "summary": ...,
    "clients": null,
    "achievements": [
        "did the thing",
        "built an awesome house"
    ]
}],
events: [{
    "name": "Carpenter Con"
    "location": "New York City",
    "role": "attendee",
    "date": ...,
    "summary": ...,
    "achievements": [
        "signed autographs",
    ]
    "type": "non-paid",
},
    "name": "Carpenter training"
    "location": "New York City",
    "role": "trainee",
    "date": ...,
    "summary": ...,
    "achivements": [
        "learned how to use a hammer",
    ]
    "type": "sponsored",
]

Yeah, okay. You're right. Events and projects should be two different things. What would follow after this event list would be a list of projects, similar to work, but with the type field (non-profit|non-paid|paid) added.

EDIT: I like achivements for the combined highlights/task field.

[stp-ip]

One thing so would clients be an array of clients?
Achievements would than be not client/project specific, but just ways to describe work related achievements ^^. Still not sure, if that's enough.

[chrisdotcode]

Should it be an array of clients? I figure one project can be done for more than one client?

I think achievements should be attached to each work item, a project, or an event. Any achievement I can think of would fit in one of those categories.

[stp-ip]

I think clients as it's own entity is wrong and so is the position right under work.
Calling highlights achievements is less ambiguous, which might not be so useful.
We are getting closer :)

[chrisdotcode]

I think you're a bit confused, what's in the work array is one element of the work list, not the work object.

work: [{
       ^ Array of objects, not a single object

[stp-ip]

Ah now I get the hierarchie. You are reducing one layer to make it simpler, but add another field, which might not be used.
So a work item without clients would just have null clients.
A work item with a client and projects would list the clients and use achievements for the "achieved" projects.
A work item with only client projects would list the client and use achievements for defining the projects done on behalf of the clients.

Another thing, which was suggested was having a role per project. As one could be team lead on project A in company 1 and glue maker on project B in company 1.

[KOLANICH]

I think that first we should decide which kinds of events should be included into a resume. I know only one such a type: talks on conferences. Another events such as some charity events, semihooligan artistic performances, visiting festivals, taking part in amateur open lectures for everybody etc shouldn't be included into a resume: they are irrelevant and tell nothing about skills of applicant, but tell that applicant spends his time on the things irrelevant for hirer, I don't think I should paste such things in my own resume.
Events describing achievements such as "took the critical part part in succesful landing of a robot onto a comet" or "invented " should be listed as achievements, not as events. Achievements should be divided into local and global, local achievements are achievements per project, global are achievements per life of applicant he is most proud of, like "got Nobel prize". Location and other irrelevant fields shouldn't be included into schema (but allowed w/o validation in arbitrary form); who really cares about them?

[chrisdotcode]

So @KOLANICH brings up a point I believe we should discuss.

I think jsonresume, while having 'resume' in the title, should also process CVs. In which, such things like performing, charity outreaches, etc. are notable.

I personally have my CV, and my resume, which is a proper subset of my CV that I modify for different companies, depending on the job. The CV never gets changed, and only gets added to as time goes on.

I would not like to fork jsonresume into json_CV_ just to add the fields a CV has, but a resume doesn't.

[stp-ip]

I agree that local achievements and global achievements are quite important and I think we should provide a default set of data for each.
As @chrisdotcode said one might use it as a CV and therefore wants all possible data in there and then use a subset of this data for a resume. Makes it much easier.

Talking about events, we also wanted to include training and seminars. These are all things, which add to the overall value for the employer.
I would probably not use it to list festivals etc., but an Artist might list prior performances, which would be more accurate as event than as work item. With prior performances even location, video, url might be important.
As we are trying the be generic, we should provide a generic schema including some defaults. Sure we do not need to add event attendance count for example, but location, url is something generic enough and having a schema for that will result in more generic themes.

[chrisdotcode]

+1 global achievements

And let's try to think of a generic name for "events" that encompasses "training" + "seminars" + "conferences" + any other generic sort of "event". Is event good enough, do you guys think?

[KOLANICH]

Talking about events, we also wanted to include training and seminars.

I think that trainings should be in "education" section.

[stp-ip]

One thing with global achievements so. Right now we have the section awards. Would one list the nobelprice really under achievements or under awards. I would probably move to achievements than instead of awards.

[chrisdotcode]

Yes, achievements is more generic.

[KOLANICH]

may be achievements should be typed?

[chrisdotcode]

@KOLANICH That makes sense for education and training.

---

Yes, achievements is an array of strings.

[PeterDaveHello]

Oops, a long discussion, sorry that I need to take a while to take a look at all the comments ...

[stp-ip]

@chrisdotcode thing is that it makes the standard unclear. As one can do it both ways. I think the first example with an additional subsection makes the hierarchy and work items much cleaner.

If we are against an additional hierarchy, I at least vote for differentiating the work name and the employer. How much information is added for the employer we could see.
An additional hierarchy is in my opinion not that bad, as people can easily not use them as there are also achievements for each work item.

The flat structure using the employer attribute introduces more duplication, which I find bad.

The data makes much more sense having projects under work items. Themes still could show each item as it's own work item, but the data should not do that.

[KOLANICH]

Why not

"definitions":{
    "achievementsList":{
        "type":"array",
        "description":"Specify multiple accomplishments",
        "items":{
            "anyOf":[
                {
                    "$ref":"#/definitions/achievement"
                },
                {
                    "type":"string"
                }
            ]
        }
    },
    "achievement":{
        "type":"object",
        "additionalProperties":true,
        "properties":{
            "type":{
                "type":"string",
                "default":"general"
            },
            "summary":{
                "type":"string"
            },
            "date":{
                "$ref":"#/definitions/uniDate"
            },
            "url":{
                "type":"string",
                "format":"url"
            },
            //etc
        },
        "required":["summary"]
    }
}

[stp-ip]

And via the type one could set "project", "client" right? This basically adds another layer, but hides it behind the achievements. I'm not sure achievements is the right word then, but I could live with something like that. As long as it has almost all the data a project would have had aka role, name, etc.

You seem to like anyOf stuff :P

[KOLANICH]

one could set "project", "client" right?

Yes, but it'd be stupid. I meant "award", "discovery", "invention" and similar.

[stp-ip]

Which not really solves the client use case, it just adds another achievement type.

[olivif]

trying to follow the thread but it's getting a bit heavy 😄

I feel like we reached some consensus on the other threads about projects, last we agreed was to have them under work items, no?

I am unclear on what this new achievements section is meant for, is this the same as projects?

[thomasdavis]

Excellent work guys, should we split, a lot to digest but I think everyone is mostly on the same page.

Here are some of my notes:

• Stray away from hyphens in property names
• Prefer highlights over achievements, mostly because it would be consistent with what is already in place and legacy data would still work. (I think it semantically works still too)
• Don't think type is necessary when talking about non for profit or volunteer. You can place it in role or summary if you must.

[jargnar]

Hi all, how about projects that you do outside of work? Maybe pro bono work, or open source contribs?

It might not be true that all of my projects need to come under an employer? How would I represent a hobby project?

[stp-ip]

That could be done via either achievements, if it is something in that area, or projects, which will probably come out of the pre-v1 volunteering section.

So for the current version use the volunteering section.
After v1 use the most likely called projects section.

[jargnar]

Thanks @stp-ip, the separate projects section would be perfect.

[stp-ip]

First iteration is now merged into the v1.0.0 branch thanks to @ashes74.

[jmatraszek]

Is there an ETA for v1.0.0? It would be really cool to use project in the resume. :)

[stp-ip]

No ETA on v1 unfortunately. We do rely on contributions to speed it up. If anyone wants to help, take a look at these issues: https://github.com/jsonresume/resume-schema/issues?q=is%3Aissue+is%3Aopen+label%3A%22PR+Needed%22

Also adding to the discussion or even writing proposals from discussions might help.

[jmatraszek]

Will look at those issues and see if I can help!

Anyway, is there a change for a 0.x release having this merged in, so one could use projects before whole 1.0.0 gets released?

[stp-ip]

I don't have access to the server infra, but if @thomasdavis agrees, we could push the projects change into a new 0.x release.

[jmatraszek]

That would be really cool!

[stp-ip]

@thomasdavis could we do an intermediate release of 0.x to push the project changes into the open. This would already test them and show progress.

[aloisdg]

We need a 0.x to see a bit better, what we got. When we are near a v1, with a stable schema, we will use an alpha am a beta tag to get the time to fix stuff and get template.

[jmatraszek]

Hi @thomasdavis,
any decision on a new 0.x release? Thanks!