Make usage of Repos & Issues more clear

[bnvk]

As per @libreanne comment in #66 and @evalica bringing up fixing the Job Board board in opensourcedesign/jobs#91

I think we should only use this repo for site design, UI / UX improvements. Whereas the more specific repo's (jobs, events, etc...) should be used in a more task + discussion focused way (e.g. feedback about design jobs like opensourcedesign/jobs#116 as this approach has these advantages:

• Makes "subscribing" simple & granular - for conversation / watching / participatory purposes
• Github as a mailing list - we're effectively using the OSD repos as a mailing list / Slack channels.

Does that sound ok to everyone? If yes, we should add this to the README and Contributing pages and use this issue to track that effot. I think this will help with "contributing" feeling @LibreAnne mentioned.

[bnvk]

Also, using this repo's issue tracker, when it comes to design / site improvements to a given repo, I advocate that we use labels for each repo + skill based label, such as this

[evalica]

I think this is something we need to agree on and document it (as you said put in README - although it should be intuitive :) and not really needing some documentation - easier to say than do).

Also the labels could be documented (for example I'm not sure what "docs" and "core" means), but that's another story.

You mentioned issue opensourcedesign/jobs#91, but actually in the JOBS repo are already 20 issues related to website (9 open and 11 closed).

Now, for your question and regarding the JOBS repo there are 2 particular interesting labels, and those are: "website" and "job".

• "website" is used to mark issues related to changes to the website

  • some sub-labels are: "bug", "improvement"

• "job" marks issues related to a particular job post, in order for the designers and community to discuss the proposals

  • some sub-labels are: "proposal" that states if some solutions/iterations/proposals have been created for it; "success" if a proposal has been accepted by the organization

• there are some generic labels like "invalid", "duplicate", "wontfix" that can be used in multiple cases

• and some other like "feedback" (used for feedback on non job posts entries - maybe it should be moved, but we are needing a place to discuss proposals) and "question" (which again is generic and should stick to JOBS).

---

Now your question is about how we decide to structure the issues: having the separation per deliverable (website, etc) or per topic (jobs, events, etc).

IMO I like the "current" structure and that is: "separating per topic" - all the issues about the JOBS goes to the JOBS repo, even if it's about the website, the jobs, iterations or questions about them. One advantage in having it this way is that the metadatas/template of the jobs posts are closely related to the layouts and they impact each other. Also the source code for the JOBS is in the JOBS repo.

There are also advantages in having all issues related to website in a single place (one would be that we wouldn't need to create bug/improvement/etc. labels for each repo), but I still prefer the topic separation, instead of deliverables (a.k.a all website issues together).

[Erioldoesdesign]

This seems like a product manager task to me and certainly can be picked back up now, especially since I'm going into the repo and making epics and commenting on issues :)