moving jobs to issues?

[jdittrich]

Problem: Changing the status of Jobs involves pull requests. This is tedious.
Possible Solution: We could change to issues (one issue per job) and change their state via github projects (kanban-style).

[jancborchardt]

I tend to agree with this. Especially because issues allow direct discussion via comments. We could even integrate it directly on the page.

cc @bnvk @simonv3 @elioqoshi what do you think?

[simonv3]

@jdittrich do you think this is still an issue with the new job form format?

The idea with the pull requests is that we want a permanent non-github record of all the jobs that we can take anywhere. That way we can move our site, etc without having to deal with the GitHub api.

What if we figured out a way for when a job gets created for an issue to also get opened and get linked to it? (as is discussed in opensourcedesign/organization#47)

[jdittrich]

@simonv3

@jdittrich do you think this is still an issue with the new job form format?

Yes, I think so. The form is great for Job creation (and I used it for it) but if I remember it right, our main concern was that Jobs don't get closed after they are taken, which is not resolved via the form.

What if we figured out a way for when a job gets created for an issue to also get opened and get linked to it? (as is discussed in opensourcedesign/organization#47)

It would probably not do away with the need for pull requests and the like, since it may be very tedious to manually check the linked issues to see if a Job is closed.

All in all, I think archiving/movability is a great thing, but it is a secondary concern compared to being able to create and change jobs.

[simonv3]

It would probably not do away with the need for pull requests and the like, since it may be very tedious to manually check the linked issues to see if a Job is closed.

FWIW I think this is possible to do with a quick check of the GitHub api on the page itself is an issue is linked to a job posting on the website.

What about organizations that don't want to have the conversation on GitHub and use their own issue trackers for this? Should they be expected to track the issue in two different places?

And what about the barrier to entry of using GitHub in general? I guess issues would still be readable by anyone who doesn't have them.

I'd be sad about all the effort pumped into getting the job form working right, but I wouldn't be opposed if people make this switch.

[elioqoshi]

I don't think we have the manpower to do this, but theoretically, issues would make a bit more sense. I'd be hesitant to switch to issues right now.

What if we figured out a way for when a job gets created for an issue to also get opened and get linked to >it? (as is discussed in opensourcedesign/organization#47)

I think that's a good compromise. Might be worth looking into

[jdittrich]

To provide a case (and ask for help), we currently have this Job on improving the UX of FreeCad (or the UX culture?).

It sounds interesting, but is naturally vague. The way of contact? Their forum. That is OK if one is already a community member there, but if not it is not a great way to draw someone in. If a projects wants design support (and I think it is great they do) people who may want to help should have an easier way of asking for feedback/description/payment etc.

If one knows that one likes to do the job, AND if one knows someone will actually want to put (dev) work into it, signing up to another projects infrastructure is no problem for any of us I assume but for the part before that our infrastructure is cumbersome.

(I mostly likely to to find the mail of the job poster and ask via that, but it is not public nor as easy as it should be)

[simonv3]

Q: why don't we just use the pull requests as issues? They're essentially the same thing and you can use the GitHub projects boards to move them around. It's essentially how @elioqoshi has been using the PRs I feel like.

The main downside at the moment is that the person who is submitting the job doesn't have get notified when the issue moves.

[jdittrich]

linking #199

[jancborchardt]

Closing in favor of opensourcedesign/opensourcedesign.github.io#100 in the correct repository – let’s continue there. :)

I’ll just close this issue cause we want to have all issues related to the website (including job board) in our website issue tracker at https://github.com/opensourcedesign/opensourcedesign.github.io/issues (less confusion where issues are ;)

[jdittrich]

I am fine with the closing – but I think commenting on Jobs does not solve the initial concern of changing the status easily (or would it?)

[simonv3]

It wouldn't, but it would be easier to see how the job developed rather than having to track down where the conversation happened.