Offer `CONTRIBUTE.md` (was: Unittest not running)

[buhtz]

While writing a long Issue text about why unittest isn't running I found out that you use pytest.

Please offer information's like this in your README or in separate CONTRIBUTE.md. How to create a PR; against which branch? Naming conventions about new branches? Code guilelines? etc.?

[buhtz]

What is the maximum allowed line length in your project? I need that for configuring my linters. Some of your line longer than 80 chars (linter default).

[karlicoss]

Hey, I'm very relaxed about all this. There is just one branch in the repo, so obviously it's just created against master :) I don't care about branch naming. No code guidelines within reason -- the only thing I care about is tests and perhaps type annotations. As long as you don't reformat the whole project in a different code style I don't care about style, line length etc. Usually when I want to find out how to run tests etc for a project, I look at the CI configuration, e.g. https://github.com/karlicoss/orgparse/blob/master/.github/workflows/main.yml I find it is more self explanatory, and will always be up to date unlike maintaining CONTRIBUTE.md. You look like an experienced developer judging by your github so I'm sure you could figure that out too :)

[buhtz]

Dear karlicoss ,

thanks for your feedback.

Hey, I'm very relaxed about all this.

It is up to you because you are the maintainer. But IMHO this will drive some contributors away.

Usually when I want to find out how to run tests etc for a project, I look at the CI configuration, e.g. > https://github.com/karlicoss/orgparse/blob/master/.github/workflows/main.yml I find it is more self explanatory, and will always be up to date unlike maintaining CONTRIBUTE.md.

The github ci yaml file belongs to a proprietary system and is not self explanatory. And if it was it doesn't answer all questions which answers I would write into a CONTRIBUTE.md or a Contribute section of a README.md.

You look like an experienced developer judging by your github so I'm sure you could figure that out too :)

What you name "figuring out" is wasting time for each potential contributor to your project. The maintainer should figure it out, document it somewhere (e.g. CONTRIBUTE.md) and save a lot of time for other people and their resources so they can invest it in real problems and issues related to orgparse. Even that you are "relaxed" about all this could be written down somewhere. In that case new contributors do know what do deal with.