add a contributing file

[d1rk]

Please take this as a starting point for contributions docs, according to https://github.com/blog/1184-contributing-guidelines

[nateabele]

Hey, good idea. We actually already have a contributor guide, that just needs to be deployed to the manual: https://github.com/UnionOfRAD/manual/blob/master/en/appendices/contributing.wiki

Maybe our CONTRIBUTING file should just be a link to that? (Once it's up on lithify.me).

[d1rk]

Sounds also like a good plan. Why is it not deployed over there, yet? Also, Do you use .wiki as extension for a reason? If you would rather use .md instead, it would be more easy to use on github and one could even link to the repository. I wondered about that some months/years ago, already.

[d1rk]

Oh, and as an addition, i would prefer having at least the main-points in the contributing file itself, rather than just a link to a different place. Of course, it would make sense to have these documentation linked for freshness. Nonetheless, having at least some information on display when clicking the "how to contribute" link by github is more friendly.

[mehlah]

@d1rk the .wiki thing discussed here: #5 ;-)

[d1rk]

@mehlah thanks for the info. Will read that up. :)

[nateabele]

The new manual with the contributor guide has been deployed: http://lithify.me/docs/manual/appendices/contributing.wiki

Maybe the 4 main points can just be copied here, and you can provide a link back.

[d1rk]

sounds like a plan - i will take care of that.

[d1rk]

Ok, i am done with it. Here is, how it looks like:

Contributing guidelines

Thank you for your interest in contributing to Lithium! This project is built by a thriving community of developers who value cutting-edge technology and concise, maintainable code. If you've found a bug, or have an idea for a feature, we encourage your participation in making Lithium better.

Here's what you need to stick to in order to have the best chance of getting your code pushed to the core:

• Integration: all pull requests should be submitted against the dev branch for integration testing
• Readibility: squash non-integral commits to make your pull request clearer
• Conceptual integrity: code should conform to the goals of the framework
• Maintainability: code should pass existing tests, have adequate test coverage and should conform to our coding standards & QA guidelines
• Comprehensibility: code should be concise and expressive, and should be accompanied by new documentation as appropriate, or updates to existing docs

Please see the full documentation over at the contribution guidelines at lithify.me