Open bnvk opened 7 years ago
hi @bnvk what a nice idea :) can we move it to the JOBS repo? :) anyway, until we figure that out, some mentions:
We are using in code and in the template the term "searching" instead of "open". It's true that the label can be different than the id, but we should try to stay consistent for the people that will do a manual PR. Currently, the status value for our 56 entries is:
I'm going to fix the "Searching" variations, but indeed we should think about the final status values, document them and use them accordingly.
Related issue: https://github.com/opensourcedesign/jobs/issues/128
Current Status values:
Since the status is something that it's hard to change (since it's need a PR for it) we should limit the states (not having "started", "rejected", etc.)
The main objective is to know if a job post is still valid or not, so "searching" and "closed". In theory "open/closed" are antonyms. So if we want to we could change "searching" to "open" (but we need to update the code, template and posts).
Regarding https://github.com/opensourcedesign/jobs/issues/131 for the close status there could be also "expired" that states that nobody closed the post (so it might be or not still valid). "Solved" is interesting from a success pov, but since this is a manual process I would just limit ourselves to the "success" label (which btw has a very low count).
So my proposal for filters is:
Status
- Searching [Open]
- Closed
Relevant only if we were to do some time filtering:
Monthly distribution:
Regarding "Payment", it's not "compensation" or something else. We used "rate" until now. Let me fix this.
Current Rate values:
Until now there are only 3 posts that provided some numerical values, and only 1 can be filtered, so the intervals don't make sense.
Since the template was free text, there are additional information in the rate field that will need normalization, but the initial preference can be deducted.
So I propose we use the fields "rate" and "paid_details" and transform the current entries, for example:
rate: gratis / in-app and website credit
should be transformed in:
rate: gratis
paid_details: in-app and website credit
For this we would need to modify 10 entries for 'gratis'; 9 entries for 'paid' and decide what to do with 'unspecified' (since the jobs form doesn't allow this value anymore).
Also the 'paid_details' need to be added to the job entry's layout.
So my proposal for filters is:
Rate
- Gratis
- Paid
The original roles:
21,4% entries provide more than 1 role [(0,1,2,3)Roles - (2,44,7,3)]. So we might need to consider allowing selecting multiple roles when using the job form.
Excepting some very specific positions (like Design focused Cocoa developer, Three.js Developer), transforming (Template Designer into Web Designer and GUI Designer into UI Designer) and breaking down the multiple roles (and listing them separate), we have the following 'desirability':
With the values:
Designer 4
Front-end Developer 2
Front-end Developer / Designer 4
Icon Designer 5
Illustration 1
Logo Designer 16
UI Designer 8
UI/UX Designer 7
Usability 1
UX Designer 10
Visual Designer 1
Web Designer 3
It's hard to debate:
Trying to oversimplify, but without dropping everything in just one big 'Designer' :) , the posts can be categories in:
So although I like @bnvk's proposal and categories, there will always be things missing, like 'User Research', 'Information Architecture', 'Interaction Design', etc. Some users might not know all the minor differences between them. Still, looking at the oversimplification, it makes me ask questions if they are explicit enough (I dislike the UI/UX Designer in particular since everybody understands what they want). Also some organizations might have some particular needs that are not covered by the oversimplification.
I don't have a proposal for this filter :) except stating the fact that we don't use "specialization" but "role".
(<3 these graphs, will read and contribute later)
I want to add that the new job form doesn't even ask for roles. Should we include those again? It might be an idea to have a form giving the top five, and then a "show more" option that lists more niche things. I see no issue with letting people filter by all of them.
How do you all see this being implemented? We can't do back-end filtering.
About the role in the new form: it is asked somehow in the "Job Title" section. We would need to ask it separate (as we did until now) and display it. Related issue is https://github.com/opensourcedesign/jobs/issues/132
Regarding implementation, I don't know. An idea would be to add some classes in the layout displayed if some criteria are met (like 'job-gratis', 'job-searching', 'job-logo', etc.) and do the filtering from JavaScript.
Another interesting filter could be: 'remote / location'. Our majority of entries are Remote - Gratis - UI/UX Designer or Logo Designer. People should draw this conclusion in the first minutes of seeing our Jobs board.
@jdittrich proposed we use the GitHub kanban board style for job listings. This would involve switching to tracking jobs through issues rather than through PRs.
This would involve moving the current jobs to the issues?
Not necessarily moving to issues, since we still need them for the website. But when creating a job post, we should also make sure it has an issue assign to it.
This would involve moving the current jobs to the issues?
@simonv3 are interpreting this as "away from markdown files"? If so, that is not what I was I meaning.
Not necessarily moving to issues, since we still need them for the website. But when creating a job post, we should also make sure it has an issue assign to it
Bingo @evalicia. Yes, as @simonv3 suggested in opensourcedesign/organization#47 this bit could (should) be automated.
Here are some really nice renderings that the uber talented Mike Finch made for OpenDesign.io site / project that he is involved with that looks almost EXACTLY what I've always had in mind for the OSD job board + people tags
To keep it simple and as also said in the »categories for job board« issue #198 I’d propose a very concise few categories you can choose from and filter through:
Maybe 1–2 more but not a lot to make an overview simple. Remember they need to be quickly understandable for people who potentially do not know a lot about design.
We would put these very prominently on the top with icons to filter. And same in the submission form for defining the category. Basically we make the current »Job role« a dropdown where you have to choose a specific category from, instead of a freeform field.
Ideally then we also correspond these to the categories we have in the job board to the ones in the Discourse forum: https://discourse.opensourcedesign.net
I think this platform is a very good example: https://www.youvo.org/ – it’s German only, but basically a job board for creatives & designers who want to get involved with social projects (only pro bono though): We can learn a lot with them since in their onboarding process they also have a good intro, regarding that there should be a proper person of contact, no design contest, that the goal should be to actually use the design etc: https://www.youvo.org/organisationen/projektvorschlag (maybe run it through a translator, it’s really good.
cc @simonbaese with whom I talked to about Youvo, and @timonweber as well
As per @evalica comment in opensourcedesign/jobs#91 she asks:
Yes. These are the two most needed ones. As I suggested, here
Status
Specialization
Payment
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!