A Better Job Board about jobs HOT 59 CLOSED

Awesome, and it looks like I got staticman app working, albeit with the old form.

Test here: http://opensourcedesign.net/opensrcdesignjobs/

Which created this test PR: https://github.com/opensourcedesign/opensrcdesignjobs/pull/2

Still needs some tweaking, but we're definitely getting somewhere.

Update: just brought in the changes from the new form, so that is up to date. What now needs to happen is that this needs to all point to the jobs repository.

Woot! #121

from jobs.

Ahoy everyone 😄 I am just catching up on things from a few months of ignoring the world.

I saw this tweet and was chatting with uber talented @jdorfman who gave OSD a nice shout out in his OSCON talk and invited him to the GitHub org and to help with this specific issue!

I hope to put in a few cycles as well soon!

from jobs.

Hi,

An idea for point 1: the website seems to be on Jekyll, so I thought you might have a look at StaticMan. It sends a pull request whenever a new form is submitted (with optional premoderation).

I did not try it myself, but looks promising.

from jobs.

@simonv3 Here is a first go for that form

https://belenbarrospena.github.io/opensrcdesignjobs/

There is a short design document explaining things at

https://github.com/belenbarrospena/opensrcdesignjobs/blob/master/jobs_form_design_spec.pdf

Let me know if it needs any changes!

from jobs.

Hi all,

I've done a version 2 of the job submission form:

https://belenbarrospena.github.io/opensrcdesignjobs/

Updated design document at

https://github.com/belenbarrospena/opensrcdesignjobs/blob/master/jobs_form_design_spec.pdf

The changes:

• Add a link to the code of conduct (in the form and the thank you page)
• Remove the role field (we will go back to it later)
• Structure the form content with some headings
• Change the blurb text at the top, to make sure it's clear you must submit the form in this page
• Change the "Required skills and experience" label to "Deliverables"
• Use radio buttons instead of a drop down menu for the "Compensation"

from jobs.

I've actually started a Patreon page for ura, my open source design startup, which rewards open source projects in need for design when people pledge:
https://www.patreon.com/ura

So the idea here is that people pledge, and that budget helps me give more time back to the community, doing design for open source projects, coming from Open Source Design.

What do you think about this?

from jobs.

Good to see you back @bnvk !
I noticed also @jdorfman tweeting re helping with OSD so that's great!

from jobs.

Somewhat boring but simple idea:

A Mailing list for design requests.

Alternatively, a sub-reddit, where people can post requests, vote, comment, etc.

Both of these come with moderation tools.

from jobs.

Thank you so much @bnvk, @neynah and @simonv3 for taking the time to give feedback. After so long working as a team of one, this feels like a total luxury! :)

I'll reply to the different issues / comments:

From @simonv3: "Should we mention our Code of Conduct in the form?" > I don't see why not. Where do you see it fitting? As part of the entry text at the top, or close to the submit button? Also, dumb question: where can I find the Code of Conduct? Is it somewhere in opensourcedesign.net? If not, we should probably put it there if we are going to mention it.

From @bnvk about "Role" as a dropdown menu > I found the drop down a bit too draconian, that's why I didn't use it. We cannot expect to list all the roles possible, and some people might want to combine two roles and crazy stuff like that :) I agree with @neynah that if we change the control to a drop down we need an "other" category that provides a free text field, so that people can write whatever they see fit. About your suggestion of adding an "unsure" entry, that would indeed be very revealing for us as a community, but do we really need an "unsure" and an "other"? How many entries would that drop down menu end up having?

From @neynah about removing "role" > I am all for removing stuff, which also happens to solve the above discussion :D As she observes, you can normally gather that information from the job description and other information provided. If nobody objects, I will take it away from the version 2.

From @bnvk about adding headings > totally agree. I'll add those in v2.

From @bnvk > about Openness & Contributors section. To be honest, I find that a bit too much. This is just about advertising the job to the world. I suspect most projects posting here might not have any kind of process to engage with designers (but I have no proof of if: it's just the general sense you get from the submissions we've received so far). Having said that, as long as we clearly explain what the section should contain, and we make it optional, I can see no harm in adding it. Could you explain what would you expect in that question from job submitters? The content you linked to is a bit too sparse.

From @neynah about the wording > yes, you are right, that text might be misleading. I will replace with the suggested text in v2.

From @bnvk > about changing "Required skills & experience" to "Deliverables". I added that section because we've had submissions from RedHat and Mozilla, and those kinds of submitters tend to have a more formal job description that includes this type of information. However, I can see your point, and I have no strong feelings about replacing one heading for the other. If noboby objects, I will change in v2.

Thanks all! I will send a v2 soonish.

from jobs.

Looks really nice @belenbarrospena. Very good work. 👍

Main bit of feedback (based on some assumptions):

Starting the form with role

I wonder if role is the field best to start with? I can imagine someone sitting at this form saying "ROLE?well...um, a designer...".

If it started with "job description", the "role" information would fall out of that?

Job description is like the problem description and the role needed is the problem statement - writing a description is easier to start with than statement.

If role is included

My feeling so far is that not all project (developers) are 100% sure of what different roles make up the UX world. We don't have a fully defined list of roles: "I'm a UX designer", "I'm a UX dreamer", "I'm a UI/UX developer"..etc.

If the role field is going to be present, it needs to be able to handle to the "Um, I'm not exactly sure" input.

As @belenbarrospena says a dropdown of 15+ (@bnvk: you missed user researcher ;)) can be difficult to make accessible (for screen readers, for people with motor skill difficulties), and becomes unwieldy.

A few options: instead of role, what about some tags for skills needed? As a user researcher, a free-text field tells me a lot about what users think.

If role is removed

The person who wants the job needs to parse the content and decide whats needed. This might be a good idea, and might save jobs being miscategorised as the wrong thing.

On the other hand, if jobs are being submitted by organisations who, like you said @belenbarrospena have more formal job descriptions, then what happens in those cases?

My feeling is:

• begin with job description (required field)
• follow with job title a freetext (optional) field

see how it performs and change if/as necesary

• as others said group information together

from jobs.

Good idea @elioqoshi. I'm all for it.

I do wonder though if there will be enough incentive for people to pledge. Usually it seems people mostly pledge when there is something in it for themselves. Like a comic or something being released.

from jobs.

@gillisig You are right, what do you suggest in this case? I'm currently doing also Logobridge, where I release logos for public domain use:

http://ura.al/logobridge/

from jobs.

@elioqoshi I don't know, that's the difficult part :/

You are off to a decent start though, 5 patrons. Hopefully people will just continue financing you and be happy with supporting more design for open source.

from jobs.

Get your own thread! :P

Not that anyone is commenting on this thread :(

from jobs.

For issue 1 perhaps we can also provide a form/email for those that don't have GitHub. I would be happy to turn some of the requests into PRs for the board. This "should" be quick & easy.

Issue 2 & 3 are related. We can brainstorm some ways to increase visibility of these postings, I think Twitter is a great start.

Unrelatedly, do we have a Facebook group yet? Would be a great way to grow our community & also share articles/ideas/discussions.

from jobs.

We do, I think, and @razetime organizes it, but I don't use Facebook so I'm not sure.

1. • yeah I think the simplest solution for now is just a form that e-mails a group of people with a job posting. Any suggestions for software? Google forms is free. Ideally Quick-Survey would do something like that, but it doesn't yet :P.

from jobs.

I mostly favour linking a Quick-Survey form(because open source), but I could live with Google forms as well. I'm happy to help set up the form & help maintain it/do PRs.

from jobs.

@neynah If you could set that up that'd be great. I think the form fields would be the same as those listed here: https://github.com/opensourcedesign/jobs/blob/gh-pages/job-template.md

Though a couple of them are very optional, people haven't tended to fill them in (though they're encouraged). To make the form shorter, maybe some can be pruned?

Feel free to add my e-mail address to it as well (which I think you have?)

from jobs.

I feel like we need an update here. As well, I do realize that many projects have really no budget to pay a designer, but if we want to communicate clearly the value of good design, people need to reconsider if they are requesting design work completely gratis.

I do realize this might be a bit of a problem but I have no solution as of now, admittingly.
At Ura we are balancing this out by encouraging people to pledge monthly, which allows us to have a monthly budget which we can use to dedicate our time to gratis projects.

What do you think?

from jobs.

wb @bnvk!

from jobs.

@elioqoshi been a fan of your work for a while, just didn't know it was you...

@bnvk @simonv3 I finally got some time to wrap my head around this issue. I will see what I can do.

from jobs.

It is hard for non-githubers to create job postings. This is a serious flaw. I would love to hear proposals to make this better. Form hosting? Etc.

What if we reversed this IFTTT Recipe to do this:

Google Form ➡️ New GitHub Issue ➡️ Current Logic

I believe Google Forms is the way to go because it is one less thing OSD has to maintain. Another option could be in-kind sponsorship from Wufoo.

Not sure if this helps or not.

from jobs.

@jdorfman interesting. Has this been done?

So someone fills in a google form, we watch the spreadsheet for a new line, that creates a PR. What account creates a PR? Whomever has done the IFTTT set up? (I'd be cool with that, but maybe we want a bot account?).

The issue there is I'm not sure that Google Drive triggers anything, so I'm not sure you can use it as a trigger. Maybe if responses were available as an RSS?

from jobs.

I've just had a look and something that is possible is to send a notification e-mail when someone submits a form, that might be something to tap into?

from jobs.

@simonv3 I think a bot account would need to be in order to pull this off.

If we can't do email notifications, we could insert a url to the jobs Pull requests below the confirmation (after submitting). That way they will see that their PR has been created.

from jobs.

Bot account 👍

What I meant for the e-mail notifications is that you can get google forms to send you (the owner of the form) an e-mail whenever someone submits the form. I can't see an other way of creating a "ping" (or "trigger") that IFTTT can pick up on to create the PR, and even then I don't think the e-mail will contain the actually submitted data? I may be missing something here though?

from jobs.

Looks like Google Forms is out (via IFTTT):

from jobs.

So what is a possibility is that Quick-Survey gets tweaked to allow publishing of an RSS feed with results. I'm not quite sure what that entails as far as Sandstorm goes, but I think it is documented. If that is possible then it should be possible to use that RSS feed as a trigger for IFTTT, resulting in a PR for GitHub?

I can probably bump the priority of that up, but it's still a factor dependent on my free time. And it's got the downside of needing one of us (me) to maintain it. Though this is pretty trivial I think. Figuring out static publishing of a meteor app on Sandstorm is something I've been meaning to figure out for other things.

from jobs.

(That would actually be a neat thing to implement because that RSS feed could be used for all sorts of user input).

from jobs.

@simonv3 didn't forget about this, just swamped.

from jobs.

@jdorfman no worries, me too!

from jobs.

@hrj I agree, simple is better. This could be a maintenance nightmare which will lead to burnout. In fact I would like to focus on the logos project, partner up with instantlogosearch.com among other things.

from jobs.

I have added StaticManApp as a collaborator. That means that the only step left for doing this is adding a form to our front-end. Look at steps 2 and 3 here: https://staticman.net/docs/

StaticManApp is pretty exciting.

from jobs.

Hi @simonv3

I'd be happy to design the form for submitting jobs. Would it be of help?

from jobs.

@belenbarrospena massively! Yes please :)

from jobs.

@simonv3 great. I'll put something together

from jobs.

Nice work @belenbarrospena !

from jobs.

@belenbarrospena that's awesome. We should document that spec as well.

from jobs.

Thanks @gillisig and @simonv3 :)

If you need me to do anything else, let me know.

from jobs.

Next steps are to add this to our website and then link it up to StaticManApp using an appropriate config file. Any takers?

from jobs.

One thing which is missing in our current job board and which is really important is a visual for each project. People should upload a logo or other visual to represent the project. That will convert the job board from a wall of text into something nice to browse. 🎉 😄

from jobs.

Regarding @jancborchardt 's comment: in practice the orgs post to this design job board just because they don't have a logo. It might not be that nice to browse 'not that nice' logos :) But sure, more graphical elements would make the board look nicer.

from jobs.

@belenbarrospena awesome work, thank you 😄 will be great to get this implemented with a back-end ASAP!!!

A few suggestions I have are:

1. Perhaps "Role" should be a drop-down menu instead of free-form text. Reasons being: will help constraint jobs to be more focused in scope and also help inform posters of the many different types of design work
2. Group things into "sections" i.e. Poster Information (org, org URL) and Job Info (heading, description, rate)
3. Add section Openness & Contributors so as to account what sort of "process" a client and designer wants to engage in.

How does everyone feel about the "Required skills & experience" bit? To me, I think we could do without that section. Often times, people in need of "Work Type X" is unaware of what skills are needed to do a given job. Also, with digital design skills, I think these lines get blurry- a really talented young logo designer might be great at interface design (they just have never tried), thus putting "good at interface design" may discourage attempts at new forms of work. Instead, perhaps a section called "Deliverables" which outlines what the job poster needs to get out of a design gig... just an idea?!

from jobs.

Should we mention our Code of Conduct in the form?

from jobs.

This form is pretty great! Thanks so much for putting this together; I think people will get a lot of value out of it.

1. IMO, I don't think the "Role" ask is necessary. It's quite a burden for the poster to be able to identify the specific "Type/Role" of designer they are looking for. This assumes they're knowledgeable about the specific capabilities of each role; roles are also not necessarily well-defined and there is quite a bit of overlap in capabilities. Specifying the deliverable/type of design work they're looking for (in Job Description) is sufficient to accomplish their goal of communicating their request.
   Not a big deal but just thought I'd comment. If the "Role" ask remains in the form then there should definitely be an "Other" option.
2. The current wording hints at clicking on the "Open Source Design" link to proceed with submitting a job rather than using the form on the page they're currently on.

"If your free / open source project needs some design work, submit a job to Open Source Design" -> "If your free / open source project needs some design work, use this form to submit a job to be posted on Open Source Design"

from jobs.

Interesting point by @neynah about the "Role" attribute

It's quite a burden for the poster to be able to identify the specific "Type/Role" of designer they are looking for.

Is selecting from a drop-down that much of a burden? For someone who knows the difference between interface design and logo design is, I doubt that is burden. Yet, like you say

This assumes they're knowledgeable about the specific capabilities of each role;

So perhaps that is a significant "signal" we can capture that is helpful to community- if we were to add an item (perhaps default selected) like Unsure to a dropdown, that inform the community / job seekers that they are dealing with someone unfamiliar to working with designers, our terms, and skillsets.

Would be helpful to filtering, planning, etc... IMHO

from jobs.

Oh I have one tiny comment. Radio buttons might be better for the compensation part rather than a dropdown since it only has two options.

Cheers!

from jobs.

@gillisig very true. I will add that change for v2. Thanks!

from jobs.

about "Role" as a dropdown menu > I found the drop down a bit too draconian that's why I didn't use it. We cannot expect to list all the roles possible

Defining "all the roles" would be hard and is not my goal. Yet, the majority of digital design jobs do fit into a handful of broad categories. If I understand your point something like jQuery Chosen's "Multiple Select" that suggests items might be ideal.

About your suggestion of adding an "unsure" entry, that would indeed be very revealing for us as a community, but do we really need an "unsure" and an "other"? How many entries would that drop down menu end up having?

Having an "Other" option also makes sense 👍 but I see "Unsure" meaning a person who does not know anything about design, where "Other" means, a user who knows what they need and it's not listed.

The problem with leaving this free-form text input is that makes it very hard to add any sort of display filtering or search on the Jobs viewing page. Take for instance the rate: field and how jobs posted vary quite widely even within the context of "gratis"

- gratis
- gratis / Negotiable
- gratis (open source)
- gratis / we provide 1 to 1 support

I've wanted to make clear visual separation on the website for months of "Gratis vs. Paid Gigs" but now one must go through each item and edit past entries. So, my goal with categories is to offer some level of discreetness that makes visually filtering manageable and balancing this with real world designer's skillsets. For instance, I would never apply for "font design" work and I seldom do "logo work" as neither are my specialty or interest. I see the more gigs that get posted, the more this filterable aspect will become an issue. The menu items I propose are:

- 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

From @bnvk > about changing "Required skills & experience" to "Deliverables". I added that section because we've had submissions from RedHat and Mozilla, and those kinds of submitters tend to have a more formal job description that includes this type of information.

Makes sense about RedHat & Mozilla. I suppose (despite adding a few gigs like that) i've seen our job board primarily as a tool to facilitate work being done directly with open source projects than something to handle job placement at large open source companies, as those orgs usually have (or hire) HR teams and use entire platforms for staffing. Based on how a lot of our postings have played out, I think we've had more success with smaller more specific gigs.

However, I can see your point, and I have no strong feelings about replacing one heading for the other. If noboby objects, I will change in v2.

Glad that makes sense 😄 I'm just seeing this as a problem that has occurred in jobs like Apache Camel logo where there is misaligned understandings of processes and expectations.

Radio buttons might be better for the compensation part

👍 to @gillisig idea. Perhaps even a few items preened from existing submissions like:

- Gratis
- Negotiable / Trade
- $500 or less
- $1000 or less
- $5000 or less
- Greater than $5000
- Part Time Position
- Full Time Position

from jobs.

where can I find the Code of Conduct? Is it somewhere in opensourcedesign.net? If not, we should probably put it there if we are going to mention it.

Not a dumb question at all. It's here, but I don't think we link to it anywhere. http://opensourcedesign.net/code-of-conduct/

from jobs.

In the mean time I took the form and tried to glue StaticManApp to it, but ran into some issues. See here: eduardoboucas/staticman#59 (comment)

Edit: forked repo I'm using here: https://github.com/opensourcedesign/opensrcdesignjobs

from jobs.

Hi @ei8fdb

Your comments make a lot of sense: starting with the role doesn't seem the right thing to do. I think I am going to remove that field for v2, in order to keep things simple for @simonv3. Once we have something up and running, we can return to @bnvk's points (filtering by role is bound to come handy as - and if - the number of jobs grows).

However, requesting the description before the title seems a bit counterintuitive, since it reverses the structure of the page you are creating through the form (not a huge deal, but it can be misleading as to what that title actually is and how it will be shown).

Also, I am afraid the title cannot be optional: it is the main heading of the job details page. We should not have a headingless page.

Thank you all for the comments: who knew web forms could raise such passions! ;)

from jobs.

Wondrous! :) Thanks @simonv3 for the work.

from jobs.

This works, right? Is there a reason this is not linked to live on the site or am I missing some context? I'm going to just link to it instead for the old forking method. If there is some issue I will fix it or roll back my update!

from jobs.

@bnvk there is no reason except that no one has done what you said you'll do. I was meaning to write that up as a comment here to be done, but if you're going to do it, yay!

from jobs.

Hmm, the path for which Staticman creates files is pretty wrong.

from jobs.

Done. I've also updated the README.md with the new instructions. And the website itself already pointed to the form. Woop.

from jobs.

I think we really need some filtering of the job posts and having dropdowns would help a lot in order to provide filters. So I truly agree with @bnvk . Instead of being free text, I would love to be able to find out if I can help in any way the job posts, instead of needing to read each one of them (especially since they start to pile up).

We need filters for active posts, payed/free and specialization required.

from jobs.

(@evalica - feel free to re-open this issue if you think it needs to be reopened).

from jobs.