Proposed projects section

[olivif]

The current proposal is to add projects to work, education and volunteering sections and as a top level section.

Based on @stp-ip's proposed schema in #201 I've created a sample of a project.

projects: [
  {
    name: "Widget Service",
    description: "Worked on implementing the backend of the widget service",
    role: "Software engineer",
    source: "https://widgetservice.com",
    date: "...",
    achievements: [
      "Best widget maker 2015"
    ],
    keywords: [
        "Cobol", "Agile", "Cloud", "Bower", "Batman.js", "Kamoulox"
    ]
  }
]

Updated based on @aloisdg's suggestion

Related previous conversations
#166, #65, #11, #38, #138, #45

Open questions
#54 - should organizations be merged into projects?
#38 - should projects have a type/category?
#66, #162 - should projects contain a skills field?

projects: [
  {
    name: "JSON Resume",
    type: "opensource"
  },
  { 
    name: "Minesweeper"
    type: "personal"
  }
]

The previous discussions have been very lengthy and hard to follow so I've attempted to aggregate everything here. I would suggest we focus the conversation and agree on an iteration 1 as soon as possible for projects, and then we can keep iterating.

[aloisdg]

We can have more coherence by move to this:

projects: [
  {
    name: "Widget Service",
    description: "Worked on implementing the backend of the widget service",
    role: "Software engineer",
    source: "https://widgetservice.com",
    date: "...",
    achievements: [
      "Best widget maker 2015"
    ],
    keywords: [
        "Cobol", "Agile", "Cloud", "Bower", "Batman.js", "Kamoulox"
    ]
  }
]

see #223

[aloisdg]

should projects have a type/category?

Do you have an example? I don't see the usage.

[olivif]

thanks @aloisdg ! updated 😄

[aloisdg]

Right now, I am more confused than before. A project can be both. We can add a license or a motivation field if we want. but this? I don't see the need. it is going to be a foobar generic field?

[phumke]

Maybe an enum for type/category? It means an update to the schema every time a new type is needed, but it keeps things more standardized.

[stp-ip]

I will reread all the discussions and will add my summary of these later in the week. But I think @olivif summed it up nicely already.
With one project item we could just reference it for root sections.

[stp-ip]

So as far as I understand all the ideas and decisions:

We have these core sections (related to the issue) work, volunteering and projects.
All the core sections have basic fields such as website, description, name, location, date, organization/company etc.

All the core sections have a project subsection roughly as @olivif suggested. This is optional and might not be used for every resume, but enables a granular reflection of work/tasks etc.

All the core sections have an achievements subsection, which can be used for small achievements, which don't warrant it's own project subsection. On the other side of the usage for achievements are overall achievements done with multiple projects. "Grew revenue by 500% with project A, B and C".

All project subsections also have an achievements subsection to highlight specific tasks, solutions and sort of showcase, what one did during the project.

[aloisdg]

I think role could be roles as an array.

roles: ["Software engineer", "Designer", "Samurai", "Ring-bearer"]

for example ...

---

I don't really like the achievement section. "Grew revenue by 500% with project A, B and C" could be written in each project.

---

I would love an organization-based object similar than the logic in GitHub.

"organization": [
    "Berkley": [ // school
        {
            "name": "IsATriangle",
            "roles": [ "analyst developer", "designer" ],
            // more project's fields here
        }
    ],
    "Aloisdg": [ // volunteering
        {
            "name": "SeasonPaper",
            "roles": [ "maintainer", "developer" ],
            // more project's fields here
        }
    ],
    "JSONResume": [ // volunteering
        {
            "name": "resume-schema",
            "roles": [ "contributor" ],
            // more project's fields here
        }
    ],
    "RubyConf": [ // events
        {
            "name": "Why Ruby is not my favorite Pokemon game?",
            "roles": [ "organizer", "speaker" ],

            // more project's fields here like date, location, etc.
        }
    ]
]

[stp-ip]

I dislike the term organization and would still favor projects, as it allows for non entity controlled projects etc.

I'm not sure about the roles as an array. Seems to make it more complicated. How often does one have multiple roles, which shouldn't be described with their own project within the work section?

[aloisdg]

as it allows for non entity controlled projects

Like what? Do you have an example of a project controlled by nobody?

How often does one have multiple roles

Like most of the time? Also you can have an array of one.

project within the work section

We can rid of that.

   "Google": [ // work
    {
        "name": "Google Chrome",
        "roles": [ "Product Manager", "Developer Evangelist" ],

        // more project's fields here like date, location, etc.
    }]

[stp-ip]

as it allows for non entity controlled projects

Like what? Do you have an example of a project controlled by nobody?

Such as personal tooling open-sourced or podcast done on the side etc. These would in my mind be projects not controlled by an entity and making the entity the first level instead of the project seems like a hierarchical mismatch in my thinking.

How often does one have multiple roles

Like most of the time? Also you can have an array of one.

I would say that you don't just wanna list roles, but tell a story with them. And each role important enough to list would most likely warrant it's own project section within the work item.
But I might be wrong on that front.
The reasoning behind single field instead of an array was simplicity on the schema and theming side.

project within the work section

We can rid of that.

   "Google": [ // work
    {
        "name": "Google Chrome",
        "roles": [ "Product Manager", "Developer Evangelist" ],

        // more project's fields here like date, location, etc.
    }]

So instead of having work and sub projects we would just have an array of work items from one employer. It would make the overall structure simpler and I would love that. The issue I see here, is that you loose the overview data of the employer such as date, website, description and role. I think we would miss out on data that way. But I would love to get rid of the sublevels, if we could move from sub projects to projects and work with just items.

[aloisdg]

Such as personal tooling open-sourced or podcast done on the side

Personal? so you are behind it so your are the owner (aka organization).

simplicity on the schema and theming side

If we use a simple string, it will allow people to use a separator between role. I agree to keep this for know. And why not moving to an array later.

[stp-ip]

Such as personal tooling open-sourced or podcast done on the side

Personal? so you are behind it so your are the owner (aka organization).

I probably don't find that intuitive to call myself an organization, but I get the point. I still disagree on the hierarchie, but let's wait for some other arguments/ideas/thoughts.

simplicity on the schema and theming side

If we use a simple string, it will allow people to use a separator between role. I agree to keep this for know. And why not moving to an array later.

I am totally not opposed to the idea, I just wanted to get some more thought into the pros and cons.

[aloisdg]

to call myself an organization

entrepreneur. At least, owner. But I think an organization is more versatile.

[aloisdg]

I still dont understand why event or publication cant be in project. Can you explain it again?

[stp-ip]

As publication has so much more data or fields to it, I think it would be wrong to merge it into project. Especially, if you look at people writing 2-3 papers per year, you don't want to clutter up your projects section with this. I assume.

I am still undecided on the events front, but move more towards having events merged into projects and publications. A given talk for example would be a publication, an attended event could be seen as a course or project. I probably wouldn't see it as an education item, but it's not per se a project.

[aloisdg]

Why a talk is a publication? It doesn't seem natural.

If you are a writer, where should you share your books? As publication or as project?
If you are a lecturer or a speaker, most of your project are going to be publication?

[stp-ip]

If we merge publications (books, articles etc.) into projects. We need to support identifiers, publisher, etc. pp. This complicates the generic project section with one edge case. I think that's a good reason to just make them separate as most of the data would be different.

As a second note in my view a project is something bigger and usually non work related, on the other hand a written book or a lecturer or so might be work related.

I see a publication as something you published publicly therefore a book, article, thesis, lecture and a talk could fall into this section. All these have similarities. They have most of the data in common or at least more than projects.

What is the reasoning behind seeing a talk as unnatural as a publication, but a thesis could be done as a project, next to the non-profit work done in a dog-shelter? I would love to get more insight into the reasoning, as I might just have a wrong logic in my mind.

[jargnar]

A publication, I believe, should refer to any written work or papers that are featured in a journal, or magazine, or website, or conference proceedings, and so on.

A talk should be fundamentally different, it could be a workshop delivered, or invited guest lectures, or conference talks.

+1 to separating publications and talks.

[stp-ip]

@jargnar just to clarify. You would vote for a separate events section?

[jargnar]

@stp-ip, I'm not really sure about events to be honest :)

Thought I'd chime in on publications vs talks as they differ a lot in the academic world.

However I think events does sound rather too open-ended -- For example, did you attend the event, or conduct the event?

If you've attended an event, that's no reason to put it on your resume as a separate field unless it was part of some learning or a project. The average geek I know attends at least 10 - 20 meetups, conferences or hackathons a year. If however if you've conducted an event, maybe consider it a project?

What are your thoughts?

[phumke]

I agree, events seems a little too open ended at the moment.

+1 to split out publication from project, there are unique fields to both.

I'd say leave talks out for now mainly because usually a talk is over something that has already been published or otherwise could be included projects.

[olivif]

+1 for roles as an object, I see no need for an array. Let's say you're a dev on some project but you also did a bit of management and PM. You can easily set the role as the main role and explain in the description that you also did a bit of this and that.

undecided on highlights/achievements, still need to think about it.

+1 on current project structure (-1 on grouping by organization) - the structure seems a bit more clear to me like this. I also don't think the grouping should be done at the organization level, because the org is not the most important field in the project item, it's the project itself.

+1 to keeping publications, talks and events out of projects. I don't see much overlap and it sounds like we need to do some thinking on what we want to support there.

I need a bit more explanation on what we are saying here

So instead of having work and sub projects we would just have an array of work items from one employer. It would make the overall structure simpler and I would love that. The issue I see here, is that you loose the overview data of the employer such as date, website, description and role. I think we would miss out on data that way. But I would love to get rid of the sublevels, if we could move from sub projects to projects and work with just items.

[olivif]

Something else we should cover is whether the schema for projects should contain a skills field, as suggested in #66 and #162.

[jargnar]

@phumke

usually a talk is over something that has already been published

Not necessarily -- talks could include technology conferences for example (Pycon, Jsconf, etc.), or workshops conducted in local meetups, or hands-on sessions for your community, or invited guest lectures in universities, or various other speaking engagements that are non-academic in nature, hence not "published" as such.

publications however are more written-oriented, like articles in journals, papers in academic conference proceedings, magazines, etc.

+1 again for a separate section on publications, talks. Not sure about events though.

[stp-ip]

I reflected the ideas for the separation within my "root section overview meta issue" #227.

Awesome to get more and more input.

[indrif]

I would really like to see a projects section added! I was very interested in the previous hobbies section but for some weird reason it has been renamed to interests (which I believe has nothing to do with hobbies). For me hobbies are the projects I work on during my spare time while interests are that I like to snowboard during the winter.

As a developer I would like to have a designated section where I can add all my published projects such as indie games, apps, websites I created etc. They don't really go into any other sections from what I can see.

[stp-ip]

@indrif yeah the reasoning seems to be the same with our arguments and thoughts. The contributors are a bit time constraint still, so a PR is always welcome.

[indrif]

@stp-ip from what I can see there is an active PR available: #254. I don't know if that is really finished but looks like a good start to me. I'll jump into the discussion there.

[DNSH]

It seems that even after a year there is still no project section...
Are there any examples of how I can add projects to my resume using the existing schema?

[nikolay]

This is moving so slow that it's forcing people to come up with their own custom schemas and fork tools, templates, everything...

[stp-ip]

We are always open to accept PRs. There are issues with a finished discussion and even implementation suggestions.

[aloisdg]

@nikolay Any help is welcome. Really.

[stp-ip]

First iteration is now merged into the v1.0.0 branch.

[koichirose]

How do I use this? I tried adding the sample "projects" section and it does not get rendered (both in the online editor and with resume-cli). I tried with a few themes.

[stp-ip]

It is only available in the schema in the branch v1.0.0. As far as the editor and the other tools go they are still using the pervious version. Themes also need to support the new schema.