A Better Job Board

[simonv3]

There are a couple of problems with our Job Board. This came after some discussion between @bnvk and @elioqoshi and me on IRC.

1. 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.
2. It isn't syndicated anywhere. Job postings should at least be posted to Twitter, as well as probably to our Facebook page (@razetime?). We could use IFTTT.
3. It's hard for people with jobs to find designers. There's no real feedback except for on PRs.

The reason 3 is a problem is because we've got some very active people doing great design work for FLOSS projects (eg. @elioqoshi), doing most of the work on the job board for keeping it active and relevant. However, there's no real incentive for these people to keep looking at the job board once people start coming to them directly (partially because of (1), our job board is hard to use).

If our job board doesn't land the people posting things to it with designers doing the work, then they're going to stop posting things to it.

I propose a way of giving some "kickback" to these awesome people - any group of designers or singular designers that have a proven track record of doing good work could be listed as "partners" and a first line of "these people will guaranteed do great work, here's how you can reach out to them". I think anyone should be able to become a partner, but they should show a commitment to actually responding to job listings.

A quick sketch:

What do other people think @jancborchardt @jdittrich @neynah @jsimplicio @paulproteus @garrett (I'm sure I'm missing some people).

[elioqoshi]

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?

[gillisig]

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.

[elioqoshi]

@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/

[gillisig]

@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.

[simonv3]

Get your own thread! :P

Not that anyone is commenting on this thread :(

[neynah]

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.

[simonv3]

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.

[neynah]

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.

[simonv3]

@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?)

[elioqoshi]

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?

[bnvk]

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!

[simonv3]

wb @bnvk!

[elioqoshi]

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

[jdorfman]

@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.

[jdorfman]

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.

[simonv3]

@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?

[simonv3]

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?

[jdorfman]

@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.

[simonv3]

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?

[jdorfman]

Looks like Google Forms is out (via IFTTT):

[simonv3]

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.

[simonv3]

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

[jdorfman]

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

[jancborchardt]

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. 🎉 😄

[evalica]

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.

[bnvk]

@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?!

[simonv3]

Should we mention our Code of Conduct in the form?

[neynah]

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"

[bnvk]

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

[belenbarrospena]

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.

[gillisig]

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!

[belenbarrospena]

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

[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

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

[simonv3]

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/

[ei8fdb]

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

[simonv3]

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

[belenbarrospena]

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! ;)

[belenbarrospena]

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"

[simonv3]

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

[belenbarrospena]

Wondrous! :) Thanks @simonv3 for the work.

[bnvk]

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!

[simonv3]

@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!

[simonv3]

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

[simonv3]

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

[evalica]

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.

[simonv3]

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