Gatsby: Individual, Organization, and Jobs pages

[calcsam]

As a follow-up to the Site Showcase (#4392), we want to create individual & organization pages highlighting the individual community members and what they've built. We also want to create a free Job Board highlighting opportunities for employment building Gatsby websites at agencies and companies using Gatsby!

This is part of #5927 with more detail. Below is a proposed draft outline of these pages. Please comment & we can improve any deficiencies this may have!

Pages

All people / agencies / companies

One template with multiple URLs, each of which apply different filters:

• /people/ (all people)
• /agencies/ (all agencies)
• /companies/ (all companies)

Filter buttons should be at the top and should be easy to toggle between them (select-one). Filters should include:

• Individual
• Agency
• Company
• Open to new contracts (people & agencies with this field toggled)
• Now hiring (agencies & companies with this field toggled)

Person / agency / company page

One template with multiple URL patterns, depending on the Creator type:

• /companies/[company-name]
• /agencies/[agency-name]
• /people/[person-name]

Data Structures

Showcase sites (listed here) can have multiple Creators.

Creators can either be an Individual, a Digital Agency, or a Company. .

Creator has the following fields:

• an id, in slug format (eg mike-allanson)
• type -- Individual, a Digital Agency, or a Company. We use the word Organization below to refer to either a Digital Agency and Company.
• a description of them in the third person “Eg, Mike Allanson is a developer living in London"
• Personal website
• GH handle (?)
• Open for Work [boolean]
• A photo / logo (depending on Individual / Organization type)
• Org they are affiliated with (if Individual)
• People they are affiliated with (if Org)
• A list of open jobs (if they are Organization type)
• A list of all the sites they’ve built.
• A location with:
  
  
  
  • A description (“London, UK”)
  
  
  • Lat / lng
  
  

_Data Format_: all creators should live in a creators.yml file, similar to sites.yml.

Jobs have the following fields:

• Title
• Location
• Organization (FK)
• (Optional) salary low end
• (Optional) salary high end
• (Optional) salary currency
• Contact email or application link.
• Excerpt (short version)
• Description

_Data Format_: Jobs should be stored in markdown files in a /jobs folder. Jobs should be stored in markdown files. Frontmatter should have all fields except description. Body of the file should be the description.

Notes on long-term data strategy

• Right now, the data is in YAML in the GitHub repo. At some point, we may move all of our data to a format with a UI making it easier for people to submit & edit their own data, without imposing a review burden on Gatsby maintainers
• Option 1: use Airtable or a CMS
  
  
  
  • Airtable doesn’t have an easy way to allow users to edit individual forms in a record.
  
  
  • We could build something on top with Lambdas, or utilize the Zapier => Airtable integration: https://support.airtable.com/hc/en-us/articles/115007655568-Using-forms-to-edit-tables-with-Zapier
  
  
  • We could also make job postings go down after 60 days
  
  
• Option 2: Build an application ourselves
  
  
  
  • Could do this, but what’s the value here?
  
  
  • We probably don’t want to spin up an application to do this
  
  
  • Firebase as backend?
  
  
• Option 3: Stick with YAML in Github for now (what we’re doing)
  
  
  
  • We know this works, although it does add additional maintainer burden reviewing these files
  
  
  • If we find a good global “application” type solution, we probably want to migrate the sites in the site showcase here as well.
  
  
  • Almost certainly the right move for now.
  
  
• Option 4: Use seeker.company or another TBD service
  
  
  
  • Upside: seeker.company provides a UI to allow people to create job postings, and a job board to list those postings.
  
  
  • Downside: No control over look and feel, not built with Gatsby, no way to customize submissions or link to organizations, no way to edit postings.
  
  

[jlengstorf]

@calcsam What would you think about making the individual/organization pages part of the maintainer dashboard?

For example, you would log in and see "my account", where you could enter relevant details (e.g. name, email, "I'm accepting contracts").

We could add company pages in the same way.

This would have the added benefit of showing off dynamic Gatsby capabilities and opens the door for a unified "Gatsby Account" that could integrate with future services. This might involve moving the dashboard to a new URL, e.g. account.gatsbyjs.org

[berraknil]

@jlengstorf From what I gathered the Individual/Orgs pages are supposed to be sort of listings that you can filter through? Unless you are talking about putting them to the dashboard as an additional feature which would be a data entry point for individuals/orgs? Although @calcsam obviously will have a clearer answer about the purpose/placement of these pages

[jlengstorf]

@berraknil Yeah, that's what I was thinking. The workflow I'm imagining would be something like this:

• Individual/Org page has a "add your info to this page!" button (or something similar)
• Clicking that takes you to the account login/registration step
• You enter your details
• Select the "I would like to be listed on the 'available for hire' page" option
• Details are saved somewhere secure/easy to access/easy to update later (e.g. Firebase); this is separate from credentials, which are stored in Auth0
• Saving the details fires a webhook that rebuilds the site
• We pull public account details from the account store for display on the org/individuals page

My thought here is that we already have a dashboard for claiming discount codes, so the auth workflow already exists to manage this. It's a bit more work upfront to create this, but it will cut down on OSS management time/PR noise in the long run because it won't require a PR to add/edit orgs and individuals.

Does that make sense/seem like a reasonable approach? (I'm also happy to have a short video chat about this to discuss details — let me know if that would be helpful.)

[jlengstorf]

Unrelated, but do we need a separation between "people" and "organizations"?

If the goal is to list people who are available for hire to do Gatsby projects, would it make more sense to group everyone and maybe add a toggle (e.g. "I'm an individual developer/contractor/freelancer", "We are a company/team for hire") and allow filtering by that instead of fully separating the two?

From the perspective of someone trying to hire help with a Gatsby project, I'm not sure I see the value of searching two pages. (I'm also saying this with very little context behind the project, so forgive me if I'm way off-base or rehashing conversations that already happened.)

[berraknil]

@jlengstorf thanks for the explanation! I think that sounds like a good idea, just that I want to keep the part of this work that is in my responsibility (namely creating the pages in question) in scope for the moment, but as an additional feature (since it will also involve an account page etc) that sounds like a good user flow to have in the future!

[jlengstorf]

Sounds good, @berraknil — I haven't seen the scope you agreed to, so apologies for the scope creep. 😅

Can we ensure that the pages are built with swapping the data source in mind? Ideally, I'd love to be able to change nothing about the components and just change the GraphQL query to load org/individual data.

[berraknil]

@jlengstorf I think Individuals & Orgs pages are for showcasing people's (and organizations') work. Them being for hire is like an additional "checkbox" next to them. Given how popular Gatsbyjs is (and getting more and more each day) for showcase purposes separating orgs/agencies from individuals seems like good UX to me. But of course I have only joined like 10 seconds ago, so we should hear what others are thinking as well :)

[berraknil]

@jlengstorf

Can we ensure that the pages are built with swapping the data source in mind? Ideally, I'd love to be able to change nothing about the components and just change the GraphQL query to load org/individual data.

I would love to chat more about this sometime next week when you are available, I want to first start working on the wireframes, layout, but data source is an important concern as well, so it would be great to pick your brain about it!

[jlengstorf]

Sounds great! If there's a slot that works for you here you can grab it: https://calendly.com/gatsbyjs-jason/30min — otherwise let me know your availability and we'll connect next week.

[calcsam]

great comments! responding by category:

_Maintainer dashboard_

@jlengstorf -- we don't want to gate this to maintainers. The purpose of agencies / individuals here is two-fold:

(1) for organizations like agencies to be showing off their Gatsby work.
(2) for community members who have built Gatsby sites to show off their Gatsby work.

(2) _could_ be contributors, and insofar as they submit a PR to get their name in here they will be, but this is only incidental. The goal here is that anyone who builds a Gatsby site can show off not only their sites but themselves here.

_Separate pages for individuals and orgs_

It's quite possible we don't need one page for individuals and another page for organizations. What we _do_ want is a page where you can see lots of logos of organizations that have built Gatsby pages, and we could achieve this with clever filtering.

_Hiring_

Re: hiring, you're getting at the point that there's two use-cases here, which are (A) organizations looking to hire, and (B) people / agencies looking to get Gatsby-related work. We could actually do both of these as views on the people / organization page with clever filtering. And then skip the dedicated "Jobs" page altogether, since org pages will let you see their "jobs" pages.

(We also want to add a map view as well at some point, but that's not in scope for this project.)

_Putting data in an actual application_

Agreed -- as mentioned in "Notes on long-term data strategy" -- using eg Firebase and Auth0 is a good idea, because it simplifies the UI for entering data, but shouldn't be in scope for this project in order to keep things simpler. So let's keep the data in yml files for now since that's a workflow we know is solid & plan migration as part of another project.

[KyleAMathews]

YAML files are by _far_ the easiest solution. Setting up a custom app takes ~weeks and a YAML file takes ~hours and zero ongoing maintenance time. I don't think they'd add much burden with Peril validating the data. We get lots of submissions of sites and they take 30 seconds tops to merge — most of that is having fun playing a bit with their site before merging.

I'm doubtful an external service would ever be a good idea given the high building/maintenance cost. One way to make editing the YAML files better is if each company puts their site data in a separate folder and YAML. With that it would be easy to create a little form where they enter info, authenticate to GitHub, and then we submit a PR with their info.

[jlengstorf]

(2) could be contributors, and insofar as they submit a PR to get their name in here they will be, but this is only incidental. The goal here is that anyone who builds a Gatsby site can show off not only their sites but themselves here.

I was unclear — the dashboard we have now doesn't require anyone to be a contributor. It has extra features for contributors, but the dashboard itself is open to everyone. (It just doesn't do much right now.)

It's quite possible we don't need one page for individuals and another page for organizations. What we do want is a page where you can see lots of logos of organizations that have built Gatsby pages, and we could achieve this with clever filtering.

💯 I'd vote for this over separate pages.

Re: hiring, you're getting at the point that there's two use-cases here, which are (A) organizations looking to hire, and (B) people / agencies looking to get Gatsby-related work. We could actually do both of these as views on the people / organization page with clever filtering. And then skip the dedicated "Jobs" page altogether, since org pages will let you see their "jobs" pages.

If it doesn't make the filtering unnecessarily complex, I think this makes the most sense. At the very least, this should be shared data (e.g. a checkbox or boolean flag for "I'm for hire" rather than a separate YAML file).

I'm doubtful an external service would ever be a good idea given the high building/maintenance cost.

I'd argue that we have to build this anyways for any Gatsby Inc. services, so adding community-related features like these should be somewhat trivial. (Not the initial work, but upkeep, etc. should be more or less managed in the normal maintenance of commercial products.)

My main concern with YAML is that it tends to sprawl over time. Lots of YAML files tucked in lots of directories, which makes it hard to know where data lives. I agree that the PRs don't take much time to review/merge, but as the community grows even 30s x 1,000 PRs is a full day spent merging PRs that could have been self-managed through a dashboard. With context switching costs that's _really_ expensive over time.

It may not be worth it now, but I definitely think we should consider automated workflows over maintainer touchpoints sooner rather than later.

[calcsam]

Let's keep our eye on submissions & maintainence workload. Could even do automated tagging with Peril of these at some point.

If we're finding it's sprawling and unwieldly over time, we can consider an automated solution. I'm with @KyleAMathews that our current workflow works for both individual submissions, individual edits & bulk edits we shouldn't add a UI until it's painful.

[lindaleebumblebee]

Love this project as it will not only help highlight Gatsby developers, agencies, and the projects they work on, but it's good for our SEO as well. Win win!

I see the individual and agency pages making sense as most/many will be looking to showcase their work. The company pages, however, seem to have a different purpose as I'm not sure how many companies will want to showcase their website work (unless they're in the website building business). However, I do see them wanting to showcase their website to promote their brand, product, etc. It's a slightly different purpose which we should keep in mind for the company pages.

[calcsam]

Definitely! The Companies page is primarily useful for us as a "logo showcase" showing who's using Gatsby. It does have some additional benefits for companies that are hiring for their website team.

[fk]

I'm going through the existing site showcase issues and just stumbled upon https://github.com/gatsbyjs/gatsby/issues/6549. @shannonbux and @calcsam—can/should we consolidate the two (and given the discussion here close #6549)?

[calcsam]

@shannonbux made the great point that this is going to be important to everyone in the community and deserves an RFC rather than just an issue, so I've moved the text of this over to an RFC and added more detailed justification for "why" as well. Design & development on this is starting pretty soon so make sure to get your comments in everyone :)

Given that, I'm going to close this issue, and we probably want to close #6549 as well.

https://github.com/gatsbyjs/rfcs/pull/8