Move content of jobs repo to this repo.

[simonv3]

To make life easier, does it make sense to move the contents of the /jobs/ repo to this repository?

Why are we keeping it all separate? I feel like it just introduces a lot of complexities that we could easily avoid.

Benefits to moving things here:

• One site to rule them all
• Can switch to using netlify, which actually lets us use a bunch more things as far as gems goes in jekyll, and also is easy to use letsencrypt, and would let use use test and staging branches (:O)
• Clear where to file issues for a website thing
• Don't have to do weird things to keep the CSS and layouts the same across pages.

Down sides:

• everything is in one repository

I think the benefits outweigh the downsides, just for sake of simplicity and cost of maintenance. Thoughts?

[bnvk]

I think we absolutely should move ALL content is not strictly "job" postings from that repo here.

I think we should keep Jobs repo as it's own instance for these reasons:

• Interested parties can "subscribe" to just repo and get notification emails
• We can delegate permissions / access should we ever want to
• Keeps the size of the webiste repo smaller. Imagine we have thousands of job file as some point?

As for netlify & letsencrypt, we'll have to move all our repos into this one to get that benefit (events, resources, etc...). However, we could also build the site from a server (and use real letsencrypt).

[simonv3]

To address your specific concerns @bnvk:

1. I feel like that's what RSS feeds are for, but instead we're having people rely on closed source and non-standard notification system that is GitHub's notifications that doesn't integrate with outside feeds and also, again, isn't very designer friendly (are designers watching their GitHub notifications?)
2. I don't really see this happening, and if it does we can break it out again. But I honestly don't see why we would ever limit who can edit what on the website - that seems counter the way this organization is run.
3. This a non-issue to me. A) we're a long, long way from a thousand job files and b) I prefer a simple architecture with lots of files over a complex one that is harder to grok. If we do reach a thousand jobs we should probably consider a dedicated hosting platform.

As for your comment about moving all repos here - yeah, that's kind of what I'm getting at. Everything that is on our website should be part of our website.

[bnvk]

1. I feel like that's what RSS feeds are for

RSS is one method of publishing / subscribing content. It's not ideal (who uses RSS feed readers these days?), but we need to build more methods.

Github (notifications) are far from ideal. I'm all for exploring moving away from GitHub and/or designing + engineering more customized notifications, but that takes certain skills + enough time to dedicate. Currently, you and I are the only ones really working on the site. I'm not sure if that's because:

1. Lack of interest
2. Lack of required skills
3. The process and dev setup is too messy or complicated

Regardless, we should definitely work on 3. which informs rest of your points.

2. I don't really see this happening, and if it does we can break it out again

If we move away from Github (or stay, but customize more) we should use better utilize git-hooks, if everything is in one repo, we loose granularity

I honestly don't see why we would ever limit who can edit what on the website

Reasons: newcomers who get added to the Github org might not know what jobs are ok to accept "sounds like open source, but is really closed source" or the technical aspects of editing the markdown files correctly.

3. This a non-issue to me. A) we're a long, long way from a thousand job files

25% of the 77 jobs have been posted since Jan, 2017 (since the web-form added). What if we add scrappers to auto-add design jobs from FOSSjobs.net? I can see faster growth

b) I prefer a simple architecture with lots of files over a complex one that is harder to grok.

Totally agree we should always strive for simple, but are "single folders nested inside a parent folder" so complex to grok? Granted, developing locally seems a bit different from how Github pages treats Jekyll sites. That might be causing confusion / issues as it's not clearly outlined in a "developing OSD website".

If we do reach a thousand jobs we should probably consider a dedicated hosting platform.

Such as?

Everything that is on our website should be part of our website.

Hrm. I think I pretty strongly disagree as then we get no separation of content / subscription / organizing with our current platform (github).

What's the complexity at present and to what user persona are you most thinking about? The biggest thing I'm noticing is "discussion oriented people" and our structure being messy. In which case, I think we probably do need a dedicated platform / place for discussion only vs. adding content to the site folks.

[jdittrich]

Remark:

25% of the 77 jobs have been posted since Jan, 2017 (since the web-form added). What if we add scrappers to auto-add design jobs from FOSSjobs.net? I can see faster growth

If we do reach a thousand jobs we should probably consider a dedicated hosting platform.

…which makes me wonder why we don't just encourage people to use FOSSjobs? If we have a different scope (I assume Fossjobs is about longer term and payed ) we should tell people what we focus on.

[simonv3]

but are "single folders nested inside a parent folder" so complex to grok? Granted, developing locally seems a bit different from how Github pages treats Jekyll sites. That might be causing confusion / issues as it's not clearly outlined in a "developing OSD website".

That's exactly my point. I don't develop the website as nested folders, do you? I would prefer it if we did move to nested folders, all within this repo. The current set up doesn't automatically work with "single nested inside a parent folder" unless you explicitly set it up this way. And if that's the case I was never told how to do that. If I'm editing the website I have to remember that there's styles in the jobs repo that directly affect the job repo. This isn't clear cause and effect.

Such as? (re: hosting platform)

We probably want an actual database at that point. A static site just wouldn't cut it. I mean, right now we're hacking together a solution and we're probably putting more effort into it than a simple CRUD framework would grant us, all so we don't have to pay hosting costs. And then there's what @jdittrich suggests. Why not just merge with FOSSJobs? I'm not sure whether /jobs/ being "our most successful aspect" is a good reason.

I think I pretty strongly disagree as then we get no separation of content / subscription / organizing with our current platform (github).

The separation of content is in how the data is stored and the folders organized.

I guess I'm overall worried that we're relying too much on GitHub. It's starting to feel like everything we do is a hack around making our website work better with GitHub. You're right, the only people who are editing the site are you and I, and I wonder if that's because of the inherent blocker that is how our website is set up.

[RichardLitt]

You're right, the only people who are editing the site are you and I, and I wonder if that's because of the inherent blocker that is how our website is set up.

This would be hard to prove. But, anecdotally, I find the amount of issues and set up confusing enough to discourage me from helping. (I don't know if this comment helps, but I figured my perspective as someone who would like to, but doesn't, would normally be the kind of voice that you wouldn't hear due to the organizational issues I'm talking about).

[bnvk]

…which makes me wonder why we don't just encourage people to use FOSSjobs?

Because we're a community of designers focused on design work?

[bnvk]

So I just updated our README to reference the helper scripts I created to make things easier

https://github.com/opensourcedesign/opensourcedesign.github.io/tree/master/scripts

But upon testing with @pdurbin and verifying on the dev server I setup:

https://dev.opensourcedesign.net

This is a bit funky / harder than it should be to get jobs and events working. Give me a few days to tweak things before I conceded to move both over here.

[belenbarrospena]

You're right, the only people who are editing the site are you and I, and I wonder if that's because of the inherent blocker that is how our website is set up.

In my case, it's just lack of time. There are things I wouldn't be able to do (I am not a developer), but I know enough to fix small issues. Right now I am swamped though. Sorry that you guys have to carry all the work at the moment :(

Why not just merge with FOSSJobs?

A bit of history might help here. When we organised the first open source design devroom at FOSDEM, tons of developers approached us to ask where to advertise the need for design contributions. This is what prompted the jobs board. I am not opposed to merge with FOSSJobs, but we will have to do a bit of a communications campaign because maintainers don't seem to perceive it as a place to invite / request / encourage design contributions. It seems mainly focused on paid development jobs.

So the need for a place to bring together open source projects and designers still exists, and that's the gap we are trying to fill.

[jdittrich]

@belenbarrospena

Why not just merge with FOSSJobs? A bit of history might help here […]

thanks for providing the background!

[jdittrich]

I guess I'm overall worried that we're relying too much on GitHub. It's starting to feel like everything we do is a hack around making our website work better with GitHub.

That might be indeed a core issue of much of the discussions lately around Website, Jobs, Discussions.

[jancborchardt]

What if we add scrappers to auto-add design jobs from FOSSjobs.net?

They don't have nearly as many design jobs as we do.

I'm all for cross-posting jobs, but that doesn't mean our specific board shouldn't exist. We also want to build other things like a directory of designers.

Just putting all the content wr have into another platform and getting rid of it is shortselling what we achieved and also what we want to build in the future.

On the separate point I agree though that consolidating into fewer repos is good. But please let's keep the discussion focused.

[jancborchardt]

Just saw this relevant post about how to merge git repositories while keeping their history (which we should do, if we combine the repositories): https://stackoverflow.com/questions/277029/combining-multiple-git-repositories/618113#618113