Add CONTRIBUTING.md

[rom-rb]

Add CONTRIBUTING.md

[jeremyf]

What are the considerations for contributors?

• Are we enforcing a style guide? I've seen and implemented a few projects that enforce style by having Rubocop be part of the build.
• Are there any licensing considerations to draw attention to?
• Do we recommend a single commit per pull request?
• What are the responsibilities of those merging code?
• What is the tone you are after? Exhaustive information? Light and brief?

I have a handful of contributing information I could bring into the conversation.

[solnic]

Oh wow those are great questions. Let me try to give you some answers:

Are we enforcing a style guide? I've seen and implemented a few projects that enforce style by having > Rubocop be part of the build.

I'm planning to plug rubocop in at some point if I see the need. For now I'm fine with reviewing things manually and asking for some adjustments if something is really off

Are there any licensing considerations to draw attention to?

Not really. ROM is under MIT

Do we recommend a single commit per pull request?

No, in fact I am against that. Reading commits is usually a good story and can tell you a lot.

What are the responsibilities of those merging code?

The biggest responsibility is to make sure that a change makes sense. Sometimes people would like to implement a feature and they look at it only from their perspective without seeing the bigger picture. My biggest concern is to keep rom libraries small and focused. Thus a person who's responsible for merging needs to understand the scope of a given project and what kind of functionality should be there.

Apart from that - checking code style and applying post-merge style improvements should also be responsibility of a person who's merging a PR. I think for most of contributors it is often a major task to just make something work or fix a bug especially when they are new to the codebase. Overwhelming them with code style nit-picking in a PR is potentially harmful and may discourage them to contribute in the future. It's much harder to come up with a solution to a certain problem than it is to beautify the code later on once the hard part is done. That's why I'm perfectly fine with "polishing" things later once a PR is merged in.

I can see this approach to become a problem when a project is really huge and receives hundreds of PRs on a regular basis but that's something we can improve using tools like rubocop. I definitely don't want to start with this though.

What is the tone you are after? Exhaustive information? Light and brief?

Light and straight to the point :)

[elskwid]

I second everything @solnic said and would add:

• Larger ideas should be presented to everyone in a pull request, the earlier the better. We're all busy so using the PR mechanism is a good signal that something is changing.

Thank you for getting the conversation started @jeremyf.

[solnic]

Ah I'm glad you mentioned that @elskwid - even if somebody has commit access opening a PR is the recommended way.

[chastell]

I'm planning to plug rubocop in at some point if I see the need

Let me know if you do (disclaimer: I’m not pushing for it, this is just in case you indeed see the need) – I like this kind of clean-up work; just did that for Reek. :)

Reading commits is usually a good story and can tell you a lot.

👍 – there’s a difference between squashing two commits where one is clearly a fixup! for the other and killing a development story by squashing everything together. Git diff over a range of commits is trivial to generate, discerning a squashed commit much harder, and git bisect can pinpoint a culprit better when the commits are smaller.

[solnic]

Thanks @chastell I have a very limited experience with rubocop but I definitely see the value. We can plug it in sooner or later :)

[solnic]

OK so thanks to @chastell we have rubocop setup now. I guess code guidelines are not needed then. We should just mention that rubocop runs by default via guard and default rake task. Turned out it already has the auto_correct feature which makes it a no-brainer to use.

[chastell]

✨ I’m still learning how to handle a certain new process at $HOME, so had to fall back a bit from development, but will follow up on my ROM & RuboCop adventures eventually. :)