You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 10, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 10, 2019. It is now read-only.
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
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 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.
What attributes would you be looking for on a JobPosting db table?
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.
@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.
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
@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.
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.
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.
@dmarchante The front-end PR for the MVP is finished, but unmerged (displaying static data hardcoded in front-end, not fetching from API for the BE PR mentioned above) - see #985 .
However, it's marked as 'Blocked' because we're holding off on it until we actually get some Featured Jobs to display there. The POCs for that is @ksmacleod99 .
Activity
hpjaj commentedon May 27, 2018
@jjhampton - re:
Np at all.
JobPostingdb table?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 commentedon May 28, 2018
@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
GETfeatured/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 commentedon May 28, 2018
@jjhampton - Gotcha. Questions for you:
We could also associate a job with tags. i.e. a job could be tagged with JS, ruby, rails, Java, etc. etc.
jjhampton commentedon May 28, 2018
@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 individualcity/locality/countryattributes instead for eventual sorting/filtering/searching? (example: 'Detroit', 'Michigan', 'USA').Is
sourcethe organization which is sponsoring the Job Opening and requesting it to be posted on our board?We could probably also use a
urlthat would link to an external website of the sponsor where they could list additional details.I'm thinking that
descriptioncould 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 commentedon May 28, 2018
@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 commentedon May 28, 2018
@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 commentedon May 28, 2018
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.
hpjaj commentedon May 28, 2018
np, I'll take care of it myself. We can always update the db table, if/when needs be.
2 remaining items
kylemh commentedon Jun 2, 2018
looks great to me!
hollomancer commentedon Jun 2, 2018
Perfect!
[-]Display highlighted jobs on Jobs Page[/-][+]Display featured jobs on Jobs Page[/+]dmarchante commentedon Jun 19, 2018
@jjhampton how are we looking on this?
dmarchante commentedon Jun 19, 2018
Also @hollomancer is this truly a high priority? @hpjaj have you built out the BE for this?
hpjaj commentedon Jun 20, 2018
@dmarchante - BE PR is in progress: OperationCode/operationcode_backend#365
jjhampton commentedon Jun 20, 2018
@dmarchante The front-end PR for the MVP is finished, but unmerged (displaying static data hardcoded in front-end, not fetching from API for the BE PR mentioned above) - see #985 .
However, it's marked as 'Blocked' because we're holding off on it until we actually get some Featured Jobs to display there. The POCs for that is @ksmacleod99 .
hollomancer commentedon Jul 10, 2018
Getting the copy ready for this.
Future implementation reference; https://www.npmjs.com/whoshiring
hollomancer commentedon Jul 12, 2018
First entries;
Gitlab
Technical Product Marketing Manager - https://jobs.lever.co/gitlab/022890d6-549a-48fe-8891-51c13b8d1137
Senior Database Engineer - https://jobs.lever.co/gitlab/8b711f1c-d378-4383-a027-bac550aeee6d
Field Marketing Manager - APAC - https://jobs.lever.co/gitlab/f53275a2-bac6-43c8-9a7f-a1d3021c9521
jjhampton commentedon Jul 13, 2018
Closed via #985