Skip to content

Arrays for Social Media #57

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vote539 opened this issue Jul 8, 2014 · 15 comments
Closed

Arrays for Social Media #57

vote539 opened this issue Jul 8, 2014 · 15 comments

Comments

@vote539
Copy link

vote539 commented Jul 8, 2014

I don't know about you, but on some social media sites like GitHub I have multiple accounts: some for personal use and some for business use. If my usernames were thing1 and thing2, then in the current schema, I could do:

profiles: {
    drSeussPersonal: "thing1"
    drSeussBusiness: "thing2"
}

But this could lead to issues for parsers that look specifically for certain profile keys like "github" or "stackOverflow". A better solution might be something like:

profiles: {
    drSeuss: ["thing1", "thing2"]
}

We could even make them objects.

profiles: {
    drSeuss: [{
        username: "thing1",
        summary: "For my boring personal projects"
    }, {
        username: "thing2",
        summary: "For my sexy business projects"
    }]
}

Just a thought.

@wdoekes
Copy link

wdoekes commented Jul 8, 2014

But if you're sending a resume to an employer, would you add that "personal" social media account⸮

This same question has been raised in #27 about "work" email versus "personal" one.

@jayzalowitz
Copy link

Some people have multiple social accounts per service. That being said there is usually a most important in this context. My typical opinion is 1 per service is fine, but this is probably an ok thing to do.

@shea256
Copy link

shea256 commented Jul 10, 2014

One way to allow multiple accounts per service would be to do something like this:

{
    "twitter": "ryaneshea",
    "twitter.work": "onenameio"
}

That way, there is an implicit default (the entry with the key "twitter") AND there are multiple accounts that have all been indicated to be "twitter" accounts. And their labels are built right into the keys.

@osg
Copy link

osg commented Jul 10, 2014

Backing up a second, which Twitter account is most important for you to share with any given recipient.

I vote for reducing complexity here.

@jayzalowitz
Copy link

There is a possiblity for allowing additional detail with a network.more
detail and allowing more than one if it is unique but the first one should
default to primary means of contact.

That being said I agree with reducing complexity here.

On Thu, Jul 10, 2014 at 1:07 PM, Ursula Kallio [email protected]
wrote:

Backing up a second, which Twitter account is most important for you to
share with any given recipient.

I vote for reducing complexity here.


Reply to this email directly or view it on GitHub
#57 (comment)
.

@DonDebonair
Copy link
Member

I vote for reduction of complexity, a.k.a. allowing only one entry per Social Medium.

@ocram
Copy link
Contributor

ocram commented Jul 11, 2014

@opensourcegrrrl and @dandydev +1

@stp-ip
Copy link
Member

stp-ip commented Sep 10, 2015

One per medium seems reasonable. If any addition, my vote would go to the "twitter" as default and "twitter.work" as addition proposition.

@aloisdg
Copy link
Contributor

aloisdg commented Sep 10, 2015

I vote for reducing complexity here.

@olivif
Copy link
Collaborator

olivif commented Nov 22, 2015

+1 to what @stp-ip said

@olivif
Copy link
Collaborator

olivif commented Dec 24, 2015

Seems like we agree on KISS here. Closing for now, feel free to re-open 😄

@olivif olivif closed this as completed Dec 24, 2015
@chrisdotcode
Copy link
Member

I like "twitter.work", "email.personal", etc. But let's document it somewhere somehow.

Re-opening as a reminder.

@chrisdotcode chrisdotcode reopened this Dec 24, 2015
@chrisdotcode
Copy link
Member

Actually, account names are just strings, so you can do something like "Work Twitter".

@stp-ip
Copy link
Member

stp-ip commented Dec 24, 2016

No change to the schema required. Just documentation on how it is possible.

@thomasdavis
Copy link
Member

It's too uncommon to either support or document, but as @stp-ip said, it is still supported if those who wish to build it, do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests