Display featured jobs on Jobs Page

[jjhampton]

Feature

Why is this feature being added?

To highlight specific job opportunities for both our community, and potential funders. If we can spotlight specific job opportunities, specifically ones that we can provide a direct reference for, we could help get vets into jobs a bit more easily.

What should your feature do?

We are still scoping this out, so the following requirements are in flux. @hollomancer @ksmacleod99 @dmarchante please add anything else from recent Slack discussion:

MVP:

• Job sponsors can request Job Openings to be posted on a board at https://operationcode.org/jobs - the same page we currently have the ZipRecruiter job search
  • Job Openings can be requested via email or Slack (contact info should be posted on site somewhere)
• Job Openings data can be maintained in static JSON hardcoded in front-end repo (similar to the first iteration of Code Schools / Team Member data)
• PeopleOps (@ksmacleod99) or other personnel will coordinate adding/updating/deleting of Job Openings data with our dev team
• Front-end React app will display the Job Openings data above the searchable ZipRecruiter job results
  • Needed: Mockup or minimal wireframe (see comment below)

Post-MVP Ideas:

• A form could be created to allow job sponsors to request a new Job Opening be added to our page (possibilities: Google Forms, a form in our front-end app, or something similar to the PyBot form in development for requesting Code Schools by @wimo7083 ).
• Back-end will store Job Openings from sponsors, and expose to front-end via API.
• Allow admins to perform CRUD actions on Job Openings via Admin Dashboard.
• Automate removal of Job Openings after a specific time interval (30 days, for example), so that PeopleOps doesn't have to manually remove them after following up with job sponsors
• Integrate this page somehow with Slack #job_board channel

[hpjaj]

@jjhampton - re:

@hpjaj How difficult would it be to add a table to the DB for 'job postings', so we could perform CRUD actions on sponsored job postings as described above via Admin Dashboard?

Np at all.

1. What attributes would you be looking for on a JobPosting db table?
2. Would there be any relationships to any other db tables?

Wondering if that data could be exposed via API to a front-end React component, which could fetch them via http call and then display on our page.

Can you pls expand on this? Do you just mean endpoints that the BE exposes to the FE for the CRUD actions? If yes, np.

cc: @hollomancer

[jjhampton]

@hpjaj re: 'Can you pls expand on this? Do you just mean endpoints that the BE exposes to the FE for the CRUD actions?' - Yes, that's correct. Mainly an API endpoint to GET featured/highlighted Job Openings, so the FE can then display them on the page. I'm envisioning the other CRUD actions (create, update, delete) could be handled via Admin Dashboard.

[hpjaj]

@jjhampton - Gotcha. Questions for you:

1. What attributes would you be looking for on a JobPosting db table? Here are some ideas. Additions/removals/changes?

• title
• source
• location
• description
• status (i.e. active, inactive)

We could also associate a job with tags. i.e. a job could be tagged with JS, ruby, rails, Java, etc. etc.

2. Would there be any relationships to any other db tables?

[jjhampton]

@hpjaj

re: 1) 'What attributes would you be looking for on a JobPosting db table'?
Those attributes you suggested look pretty good for a minimal set of requirements.

For location, perhaps we could have individual city/ locality / country attributes instead for eventual sorting/filtering/searching? (example: 'Detroit', 'Michigan', 'USA').

Is source the organization which is sponsoring the Job Opening and requesting it to be posted on our board?

We could probably also use a url that would link to an external website of the sponsor where they could list additional details.

I'm thinking that description could be a "catch-all" attribute that sponsors could use to display any additional info of their choosing, things like compensation, benefits, employment type, job requirements, etc. If any of those pieces of data seem to repeat themselves, we can move them to separate attributes later.

re: 2) 'Would there be any relationships to any other db tables?' - not sure about this myself - cc @hollomancer @ksmacleod99

[jjhampton]

@hpjaj re: Tags for specific jobs types (JS, Java, Ruby, etc) - That could also be useful, we can plan to do that for now, too.

For the back-end side of things, if it's helpful, we can first develop a purely static FE client-side MVP of this feature, before we go into detail on adding in back-end DB & API implementations. During that process, we may discover some other data types that we need to add.

[hpjaj]

@jjhampton @hollomancer - What is the priority level for this feature set?

If the priority level is low, and since this is not fully teased out yet, it would make sense to hold off on any BE work until the client-side MVP is in place.

If the priority level is higher, they can be done in parallel, and I can create an issue (or update OperationCode/operationcode_backend#363) for a contributor to get started with what we have discussed here.

If the priority level is high, I can do the above, as well as do the work myself.

Thoughts?

[hollomancer]

My gut reaction is to replicate the data model Ziprecruiter currently has as an MVP. Priority level is a bit higher, as we were discussing getting a design for the client-side MVP started by the end of this week.