jsonresume / resume-website

Website for JSON Resume. 🏡 DEPRECATED - SEE MONO

Home Page:https://github.com/jsonresume/jsonresume.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Change branding

aloisdg opened this issue · comments

Are we still dev-centric?

resume

Should we change it for "For everybody, by developers."? It is not very catchy, but we are making it with all professions in mind. I would love a new motto for the v1.

What do you think?

What about: "Standards based resumes for everybody."
We are trying and incorporating feedback from everyone, who can argue their point logically.

Agreed that it should be changed :)

Maybe just remove the "by devs for devs" part?

I agree with... everybody actually. I like all of those solutions. How about a coin flip?

That being said, there was another issue in which @aloisdg mentioned a rename, and I was on board with it. If I can't find that issue while clearing out my queue, let's discuss it here:

The gist was that we are the _resume_ standard, and the fact that we're currently using JSON is incidental. We might one day change to another format, but for non-developers, that change will be transparent. That being the case, is a rename from "_JSON_resume" necessary to just "Resume" (too generic, IMO, but if we can create a resume standard under the name "Resume", fantastic!!), or something else?

Found it, #207.

We'll centralize that discussion here.

When we talk as "we", we are referring to us, the users of JSONResume. Generally, most contributors use the actual tool itself. It's incidental that we also happen to be developers.

I haven't taken a look at the cli code, but it likely does need a re-write in several place - if there is silent data uploading, I'll be sure to gut that entirely. I'm also not hired by hired, but I don't see anything wrong with a commercial entity backing an open source project (but now that you mention it, I don't personally know how hired supports the project, and IMO, if they are not anymore, then their sponsorship should be removed on the homepage as you said).

It was true that the various repositories went unloved for extended periods of time, but as proof of the 40 issues I just had to look through that piled up over the holidays, we're giving this project the love it deserves now. In fact, the decision to create v1.0.0 was a recent decision by myself to break away from the old features, code, etc. and start afresh to show the community more love.

What was in the past isn't anymore. We're actually making a lot of new progress, and your contributions have also helped us along the way, too.

I think JSON is a fine fabric of the standard: a standard doesn't necessarily have to support every format possible, it just needs to be unilaterally consistent. I think supporting multiple formats at once isn't needed, and supporting certain formats at all (i.e.: XML) is going backwards.

I agree. Our keys to gaining adoption will be:

  1. Winning (back) the community by showing them that the project is alive, active, and open to contributions.

  2. Offering converters to and from various resume formats (LinkedIn, etc.) such that a non-developer user can work in our standard format, and export as necessary. When we've gained critical mass, these converters will be deprecated, and our format will be used.

    (I discuss this in some other issue that I might find later and link here).

  3. Creating a GUI-ish/website in which non-hacker users can easily access all of the functionality we have access to.

@chrisdotcode We can keep the name and change the motto. We dont have to change both.

+1 for changing the appearance and cleaning out the presentation. active++, open++, generic++.
+1 for a rebrand away from JSON resume. At least we should think about a catchy name. I mean what is the best time for a rebrand than a v1 release right.

I think the JSON part was a bit misleading originally and would love to support YAML going into the future.

JsonYamlResume.com? j/ks

I believe the project will always be dev centric and the projects who depend on jsonresume will eventually become more accessible to a wider audience.

  • Doesn't matter if it is dev centric too much e.g. devresume.com
  • Has to represent that it is a specification that we work on
  • Catchy, easy to spell
  • Not too divergent from what we already have hopefully. e.g. ****resume.com
  • Try to remove the association with JSON because we might support YAML and any other key/pair systems, although the spec will remain in JSON

That all being said, JSON is the only format with a well written specification where as YAML does not. So maybe we should remain JSONResume.org with much great support to convert between YAML and such.

This has just become a brain dump -1/+1, I am unsure.

genericresume, libreresume, collectiveresume, centralresume, baseresume to just push out a few suggestions and get the ideas started.

how about StandardResume?

.com already taken. :(

OnlyResume or Resumely :P

ElementResume, SeedResume, ResumeSeed, RootResume...

Acronym:
Ocuvi (One CUrriculum VItae)

with recursion:
Risar (Risar Is Simply A Resume)
Risar (Risar Is Standardized Amazing Resume)

(the first letter can be change at will. If the first letter is a vowel, we can change the second letter for another verb easily.)

MetaResume ?

@olivif IssueResume ? 😉

haha @aloisdg ! you out-meta-d me!

Yet another Resume Standard (YARS) :P

SRIBOC (Standard Resume Initiated By Open Community) Ok ok I better stop now.

Just gotta keep in mind, we are building the specification under the constraints of the JSON specification. So JsonResume is still quite applicable. But keep it up with the suggestions=)

@thomasdavis in the same idea, could we just use "Resume.json". I saw it somwhere. If someday, we decide to switch for another format we just have to switch the extension aka "Resume.yml", etc.

We seem to agree that we should move away from "from devs for devs" to something in the area of "open, generic, (usable)"

On the rebranding side we are still not at a consensus. If we ever plan to rebrand I think the time would be with v1. Sure we use JSON now and we could still advertise "$name the open, generic, $atribute built on JSON", but having the non implementation specific name in the open with v1 would make things easier later on.

open.cv or something in that vein?

@phumke opencv is a popular computer vision framework. I like the .cv though.

How about Open.Resume ?

@olivif

So we have a Open.Resume.json or we use Resume as the extension?

@aloisdg I was thinking of using .resume as the extension. It's more generic. I see what @thomasdavis is saying and he is right, we are building the spec according to the constraints of JSON, but from a branding perspective I would like us to be generic 😄

@olivif ok but we are going to have a problem ...

I think that extensions look too much like a domain especially with the new gTLDs going mainstream. Therefore I would only see that being a good branding, if there is a gTLD and we hold it.

resu.me is already registered I tried...

ah bugger ..

I like it as JSONResume. Because people associated this project with the term JSONResume & now if we suddenly change the brand name, the connection will be lost? Also, it involves alot of additional work, renaming github repo name, domain name changes, npm packages & update jsonresume-theme-X (there are so many npm dependent packages). And I think we can put this effort into building features at this stage.

It's great that we are planning to add additional formats but the name JSONResume will perhaps signify that it all started with a json format?

Or maybe just change the github organization name to some generic name & JSONResume, YAMLResume, etc will reside in their own repositories under the organization(Reminds me of Alphabet Inc, Google etc 😉 )

Again this is my personal opinion :)

I am looking into a few options to get some re-branding ideas, but that's a side task during the v1 implementation.

Decision for now:

  • re-branding is not mandatory
  • re-branding, if a new name is proposed and accepted
  • re-branding most likely only before the v1 release

Migrating this issue to resume-website as it has nothing to do with the schema.

(Closing auto-manually because after 4 years, this might no longer be relevant. If this still does concerns anyone, give me a holler.)