Add a contributing guidelines with a CONTRIBUTING.md about skohub-vocabs HOT 5 CLOSED

@Phu2 @acka47 I think you both should do the review of the guidelines:

https://github.com/skohub-io/skohub-vocabs/blob/242-contributingGuidelines/CONTRIBUTING.md

For SkoHub this especially means focussing more on the distinction between functional and code review.
Currenty we do not assign functional reviewers and do both in the PR.
We should also pay more attention to the definition of ready. I added a note about features that requires a small user story (if possible and sensible) so we get a more detailed picture of how that feature is going to be used. As well should a small check list be provided that makes it easy to know, when the requirements are met.

from skohub-vocabs.

+1
The proposed changes sound reasonable to me.

from skohub-vocabs.

Other than the metafacture guideline I propose a workflow where the person, who opens the pull request is also the assignee of the pull request. (...)
Also I propose a workflow, where the issue remains assgined to the person originally working on it.

I don't see this being clearly expressed in the current draft. For example this reads as if un- and re-assignments are expected:

Issues in working are only reassigned by the person who is currently assigned. If the assignee thinks the issue is ready for review they add instructions and links for testing the changed behavior in the issue, move it to the Review column, assigns the previously announced functional reviewer (see Definition of Ready), and open an pull request for the feature branch. The assignee of the pull request is the original assignee of the issue.

Here are some more thoughts I had while reading it:

• I am not sure whether these two points should actually be listed in the "submitting enhancements" section (in this draft as well as in the Metafacure Contributing.md where it is copied from) as it rather sounds like a bug-related scenario:

• Provide specific examples to demonstrate the steps. Include copy/pasteable snippets which you use in those examples, as Markdown code blocks.
• Describe the current behavior and explain which behavior you expected to see instead and why.

• Not directly an issue with the CONTRIBUTING.md: In the "Definition of Done" I am missing the point that the functionality is actually deployed to production. We should make sure in our process that this is done. (Thinking about one or two cases in the recent past where the main branch wasn't deployed.) However, this does not need to be written into the CONTRIBUTING.md as it is instance agnostic.

from skohub-vocabs.

Also, I have a question re. the "Releasing SkoHub" paragraph: Is this something we already do or is it just a plan to do it like this?

from skohub-vocabs.

@acka47 Thanks for the feedback.

Re: Assignment:
I reworked the mentioned sections and hope it is now a bit clearer.

Re: Submitting enhancements
I think you are right. I removed the two points.

Re: Deployment
This should now be fixed with #217
A merge in main branch triggeres the built of a new docker image, which is then automatically pulled by skohub-webhook. Therefore vocabs are always built with the most current version now.

Re: Releasing SkoHub Vocabs
I think we did not yet decide if we need releases. I removed that part for now.

btw: I moved discussion here, because in the first draft I copied the approach from metafacture that discussion of functional review should happen in the issue. And this is kind of a functional review.
But after rework of that section I propose the approach that after an issue is ready and someone has a change ready and makes a PR the functional review and code review move to the PR. Therefore I will now open a PR and reassign you there.

from skohub-vocabs.