organization
organization copied to clipboard
opensourcedesign
How to handle "Jobs" pertaining to OSD job board
There are many issues (in multiple repos) talking about the job board- that range in content from technical, to design, to organizational, to actual jobs being done- I figured: why not start another thread :grimacing: some of those are:
- opensourcedesign/opensourcedesign.github.io#69
- opensourcedesign/opensourcedesign.github.io#70
- opensourcedesign/jobs#91
- opensourcedesign/jobs#139
I propose is looking at the properties each aspect offers and determining from there, as using Github + Markdown + Issues + Pull Requests for our purposes is experimental in nature.
Markdown Files in Jobs Repo
Is for the content of the "job" and it's permanent record of what work performed or not performed.
We are using markdown files as "content" which has relevance and meaning to the job (being published and tracked), but this does not relate to the work performed. Initially, I thought we should use Markdown + Jekyll because it is nimble, flexible for changes (as the variable data @evalica highlights in opensourcedesign.github.io#70 shows), it 100% open and transparent, and it makes our discussion and history (as a collective) 100% transportable / cloneable.
Pull-Requests
For items on the OSD job board being modified in "state" and thus our record being modified.
I think using pull-requests for tracking a job is correct use, while using them for discussion (about job being performed) is a misuse.
- Are needed for any modification to content (markdown files)
- Are used by "admins" who approve said content changes (is job suitable, job status, etc)
- Offers comments & discussions about content in code/text being submitted
Issues
Discussions about jobs whereby they "choose" to have community feedback or people participating in a design process of a job.
- Made to report an issue with software
- Offers non-specific comments & discussions around "repo name"
- Does not modify or relate to content in repo
This also means that we SHOULD NOT use the issue tracker of the jobs repository for discussion about designing, coding, and policies of the job board itself.
Consider, if we were to migrate away from Github and build a custom CMS to manage jobs- it would probably have email (and other notifications) with similar aspects of Issues and Pull-Requests, as well as how we are using markdown files. I think we should think that eventually this will happen (even if it's 3 yrs down the line).
One thought is that we could (I haven't verified that this is possible) auto create an issue when doing a PR and link it in the PR.
Eg in the form have a boolean field "do you want us to provide a place for you to discuss the progress of this issue?" If yes - create issue, if no - do nothing. That way we don't lose the content in our "repo" but still give a space for that conversation (even if that conversation doesn't get moved across.
I'm finding it a bit hard to parse your comment, @bnvk. I'm sorry about this! Can you explain more clearly why you posted this issue, and what actionable items you want us to take away // offer discussion on? The PR, Issue and Markdown subsections look like descriptions, and I'm not sure how to engage with them. Could we be doing something better? Should this information be written in a README? Is there something controversial?
Consider, if we were to migrate away from Github and build a custom CMS to manage jobs- it would probably have email (and other notifications) with similar aspects of Issues and Pull-Requests, as well as how we are using markdown files. I think we should think that eventually this will happen (even if it's 3 yrs down the line).
What do you think that this system would look like? Why do you think it is inevitable? What needs are we not getting to, now?
One thought is that we could (I haven't verified that this is possible) auto create an issue when doing a PR and link it in the PR.
I'm sorry, Simon. I'm a bit new. Can you explain the current process, from start to finish, for posting a job? Why would this improve on that?
No problem! People fill in this form:
opensourcedesign.net/jobs/job-form/
which gets automatically submitted as a PR to the https://github.com/opensourcedesign/jobs/ repo. We then merge the PR and it appears in our feed and on our job board. This is the "markdown" file that @bnvk is talking about. It acts as the permanent record of the job.
However, there's no way for us to follow up on a job after it has been merged to the repository. We used to ask people to make their own PR, and then in the PR thread people would comment and there was some back and forth, but since the job form gets used (which is way easier and we have definitely seen an uptick in jobs submitted) that connection has disappeared.
So we don't have a way of tracking what the status of a job is, and we don't have a platform for people who posted the job to interact with possibly interested people. It could be that this gets done in a means that the job submitter specified in the form, but if they don't have a forum or place to have that conversation we want to provide them with a means of doing so.
Automatically creating an issue if the job submitter wanted to would provide a forum to the creator and a means of keeping track of the job.
What is the process for automatically opening a PR? Can I look at that sourcecode? Might be easiest to change that to also automatically open a corresponding issue, and direct conversation there in the Markdown and link it in the PR. That way, the people submitting know that they can talk about stuff there.
@RichardLitt You're more than welcome to look at the sourcecode, but it's outside of OSD. We use staticman:
https://staticman.net/
I suspect that the easiest might be to use IFTTT on an RSS feed event https://ifttt.com/applets/197941p-create-a-new-github-issue
I'm finding it a bit hard to parse your comment, @bnvk.
Sorry for being confusing.
The PR, Issue and Markdown subsections look like descriptions, and I'm not sure how to engage with them.
Exactly, the biggest issue is making it really clear to people submitting jobs, people working on jobs, and community observers / participants how to engage- namely around discussion and give feedback.
What do you think that this system would look like? Why do you think it is inevitable? What needs are we not getting to, now?
For one thing we're using Github which has various barriers to entry and is mostly aimed at "code review and merging" processes instead of "design" processes. Also, concepts like forking, etc. while (abstractly) apply to both- the usability and terms would all be quite different in a design centric platform.
Ah. Ok! Static man looks interesting. I see the process more clearly now.
I suspect that the easiest might be to use IFTTT on an RSS feed event https://ifttt.com/applets/197941p-create-a-new-github-issue
We might be able to make an applet that just watches for PRs and automatically makes an issue. Alternatively, I could run a cron job or a poller that would just look for new PRs, and then open an issue when it gets one. I'd run it on Heroku. @simonv3 do you have experience with building custom IFTTT applets, or should I go ahead and build that?
@bnvk Thanks for clearing that up - this makes more sense.
Consider, if we were to migrate away from Github and build a custom CMS to manage jobs- it would probably have email (and other notifications) with similar aspects of Issues and Pull-Requests, as well as how we are using markdown files. I think we should think that eventually this will happen (even if it's 3 yrs down the line).
Perhaps we should just do this now.
Consider, if we were to migrate away from Github and build a custom CMS to manage jobs- it would probably have email (and other notifications) with similar aspects of Issues and Pull-Requests, as well as how we are using markdown files. I think we should think that eventually this will happen (even if it's 3 yrs down the line).
Perhaps we should just do this now.
Time and resources. I am not opposed to anyone starting this, but we have to consider whether we have the time and resources as a team to maintain this.
@RichardLitt you're pretty familiar with the GH API right? I have next to no experience with building IFTTT things. The issue right now though is that the opensourcedesign username is being used but we have no idea who uses it, which fills me with chagrin.