# What we want from our Jobs page - An issue to collect our wants
**URL:** https://discourse.opensourcedesign.net/t/what-we-want-from-our-jobs-page-an-issue-to-collect-our-wants/2525
**Category:** Uncategorised
**Created:** [May 5, 2021, 6:28pm UTC](https://discourse.opensourcedesign.net/t/what-we-want-from-our-jobs-page-an-issue-to-collect-our-wants/2525 "2021-05-05T18:28:50Z")
**Posts on this page:** 3
**Page:** 1
I created a GitHub epic for what we as a community want to improve for our jobs page:
>
>
> In the community meeting held on May 5th 2021 we talked about what we want from …our jobs section and form.
>
> The jobs section of opensourcedesign.net can be improved in multiple ways.
>
> This is now an Epic issue that will collect all issues about the '\[Jobs\](https://opensourcedesign.net/jobs/)' page underneath it.
>
> \------------
> What community members suggested for the Jobs page in terms of improvements:
>
> \* Better structure for the form for jobs 'original posters'.
> \* Clearer in form support for the jobs 'original posters' as they fill in the form.
> \* Clear and accurate form validation for job 'original posters'
> \* Ability to have more than one contact method
> \* 'Contributors' have a clear set of steps to contact the 'original poster' of the job that is clear and easy to follow for any designer regardless of proficiency with OSS and comms platforms.
> \* Keep the feature where a new job is automatically cross-posted to the discourse forum.
> \* An easy way to see the status of a job for both the 'original poster' of the job and any potential 'contributors' to the job.
> \* Easy way to update the job that doesn't include editing the .md file in the\[jobs repository\](https://github.com/opensourcedesign/jobs/tree/master/jobs).
> \* Review stage for the job so that abuse of 'contributors' or 'original posters' is avoided.
> \* Include a notice that states that jobs that are open and unchanged/not commented on in a time frame (agreed by OSD community, suggest 6 months - 1 year) then the job post will be automatically closed.
>
>
> We welcome further comments on improvements to the job page as we grow this epic.
Designs are WIP in Figma at the moment:[https://www.figma.com/file/Epo7gdfwJCDAVknWnpvfn1/Open-Source-Design?node-id=107%3A263](https://www.figma.com/file/Epo7gdfwJCDAVknWnpvfn1/Open-Source-Design?node-id=107%3A263)
---
> [@Monthly Open Source Design call](https://discourse.opensourcedesign.net/t/monthly-open-source-design-call/253/117):
>
> **AP: Eriol** will look at the issues that already exist about web page design, job page improvements and then start to build a collaborative brief.
From the last community call I had this action above
I changed the issue above into an ‘Epic’ on our repo (I use Zenhub chrome browser extension to create and view epics) and the issue that is an epic is here: [Improving the Jobs page: Improvements to the way the jobs page works · Issue #323 · opensourcedesign/opensourcedesign.github.io · GitHub](https://github.com/opensourcedesign/opensourcedesign.github.io/issues/323) however, I know not everyone uses Zenhub so I’ll link all the associated job issues in a comment on that issue.
The Issues that were already in our repo related to the jobs page are:
>
>
> As per @evalica comment in opensourcedesign/jobs#91 she asks:
>
> \> We need filte…rs for active posts, payed/free and specialization required.
>
> Yes. These are the two most needed ones. As \[I suggested\](https://github.com/opensourcedesign/jobs/issues/91#issuecomment-261949075), here
>
> \*\*Status\*\*
>
> \`\`\`
> \- Searching
> \- Negotiating
> \- Started
> \- Complete
> \- Rejected
> \`\`\`
>
> \*\*Specialization\*\*
>
> \`\`\`
> \- Unsure / General Help
> \-------------------------------------
> \- Font Design
> \- Logo Design
> \- Icon Design
> \- Styleguide
> \- Website Design
> \- App Interface Design
> \- User Experience Design
> \- Usability Testing
> \- Wireframe Prototyping
> \- Data Visualization
> \- Information Architecture
> \- Product Design
> \- Print Design
> \- Packaging Design
> \--------------------------------------
> \- Other
> \`\`\`
>
> \*\*Payment\*\*
>
> \`\`\`
> \- Gratis
> \- Negotiable / Trade
> \- $500 or less
> \- $1000 or less
> \- $5000 or less
> \- Greater than $5000
> \- Part Time Position
> \- Full Time Position
> \`\`\`
>
> One we agree those are the default "allowed" entries for those fields, @evalica if you want to go through and standardize the items, that would help me doing my next step!
>
>
> \*Moved from opensourcedesign/jobs#128 by\* @Miserlou
>
> Currently one has to scro…ll through all to see which are paid opportunities. As @evalica pointed out
>
> Some more ideas about filtering (although this issue was perfect since it was specific, I still want to make this comments in order for the implementation to be extendible):
>
> \- There is no way to see the resolved jobs (in order to determine the board's success)
> \- The filtering is by date of posting, but this is not obvious. Apparently there is no order in the listing. Having that said it's hard to know which entries are still relevant/recent. We should have a rule to deprecate/close older than x entries.
>
>
> \*Moved from opensourcedesign/jobs#131 by\* @evalica
>
> While usually we start ha…ving the need for this kind of functionality when we are flooded with posts (not quite yet, although we have 56 entries, from which 39 are searching), the problem we have is that:
>
> \- we don't know if the job post is still active
> \- people from our organization might forget to mark a post as "closed"
> \- people that initially added the post might forget to close it in our repo.
>
> A solution would be to:
>
> \- \[\] allow people to add in the job template the expiration date;
> \- \[\] have a filter on the website and just display not expired job posts;
> \- \[\] have a listener and automatically change the status to "expired" if the date passed (although I don't think this is possible on the platform used).
> \- \[\] notify poster of job that it has "expired"
>
> The first two tasks can be done with Jekyll, but the later two will require some sort of server daemon / service that checks and monitors things!
>
> \---
>
> Added an implementation suggestion from #101
>
> \`\`\`
> \