Add CONTRIBUTING.md

[Potherca]

This is not finished yet, hence this MR is merged as "draft". Feedback on what has already been written is welcome.

The "Release" section is a continuation of the list from #248

Not to forget:

• define a "Release (issue) template"

[kirchsth]

Hi @Potherca,

I like the idea.

What do you think if we directly define a "Release (issue) template" and defined there all checks which should be done. And the constributing.md contains only a reference to the template.
A generic issue template could be added and referenced too.

Best regards
Helmut

[kirchsth]

I found this CONTRIBUTING.md and the corresponding CODE_OF_CONDUCT.md and other links, ...

It contains a lot of guidelines, e.g "Write good commit messages". Or it contains a description of the folder structure, ....

[Potherca]

In my experience it helpt to have both the prose in the CONTRIBUTING.md and the template, but yes, I was also thinking about issue templates!

I don't like the defaults GitHub offers, so I was thinking about defining what it is we want first, and then creating templates from that.

This contributing file is from another FOSS project I am part of. I tend to add a directory structure as wel (see here for an example) as it helps get a quick overview. So, yeah, the contributing you linked to is similar to the end goal here. 👍

For the code of conduct I would rather reach a consensus at the plantuml-stdlib organisation level. We'd probably have to open a discussion at the org level for that. I've just not had the bandwidth for that yet. (The current focus is on getting a few release out the door first, getting the PlantUML lib updated, and then focus on the rest of the org, automation, etc.).

As for commit messages, I'm not that bothered, honestly. At this point I think the contributions themselves are more valuable than how they are described in the commit message. However there is no reason why you and I shouldn't start by defining at least some order to our madness. I already have some conventions I follow and I've been party to several more rigid regimes for various companies I've worked with. That might also be worth starting a discussion at the org-level, I think...

[kirchsth]

I see you have much more experiences in this area than I have. You are right we should start with smaller steps.

Related to the commit messages, I only saw it and thought it is a very complete description which covers nearly everything. Personally I'm happy if I can check in some files into git (without deleting other local files during a merge process ;-) )

[Potherca]

Personally I'm happy if I can check in some files into git (without deleting other local files during a merge process)

Yeah, I keep coming back to this:

Git may be simple but it is not easy.

The highest voted questions on StackOverflow:

• Top 3: 60% git
• Top 10: 50% git
• Top 25: 40% git
  

With the other almost 40%¹ of the Top 25 (marked blue) is taken up by javascript and JSON.

Footnotes

1. 36% to be precise ↩

[stale]

This issue has been automatically marked as stale because it has not had activity in the past 60 days. It will be closed in seven days if no further activity occurs. Thank you for your contributions.

[kirchsth]

cleanup stalled pull request.
If still a concrete solution is planed please reopen it or create a new issue/pull-request.