Addition of contribution guidelines.

[tabeth]

I was wanting to contribute to this, but I noticed that there wasn't a formal set of guidelines for contributing. Does anyone want to take the lead on this? I don't mind, but I would most likely just borrow from a well maintained project like erlang/otp.

[dfreeman]

My inclination would be to pull from contributing guidelines from other addons in the top 100. Interestingly, though, the only top-10 addon with formal guidelines is Ember Data, which has a much more complex rollout process for new features than most addons.

What specifically would you be looking to see covered in such guidelines?

[tabeth]

Nothing too complicated. I think answers to common questions like these would be a good start:

1. Are issues for feature requests, bugs, general questions, comments, or all of the above?
2. I want to contribute! Do I just open a pull request? Should it be from a pre-existing issue, or should I open an issue first and then a pull request?
3. What should I do to increase the likelihood that my pull request is merged into master?
4. Are tests required?

[dfreeman]

@tabeth Sorry for the long delay on this. I had a conversation with a couple other addon maintainers in the Ember Community Slack, and we all seemed to have very similar ideas of what the de facto contribution expectations are in the community, but it seems no one has written them up.

To your specific questions (all of these answers apply to ember-css-modules, but are also more generally applicable to most other addons/maintainers that I've interacted with):

Are issues for feature requests, bugs, general questions, comments, or all of the above?

All of the above — issues are the typically easiest way to start a conversation with the addon maintainer(s), as most addons don't have a large enough community to warrant other dedicated communication media (though many widely-used ones do have channels in Slack, e.g. #e-css-modules for this addon)

I want to contribute! Do I just open a pull request? Should it be from a pre-existing issue, or should I open an issue first and then a pull request?

It depends on the size and impact of the change. For a documentation typo or a small bugfix, usually opening up a PR is an ok way to kick things off. For anything more involved, generally filing an issue first is a good idea to make sure the maintainer(s) are on board with the change. Often they'll also be able to provide some up front guidance on an implementation approach, which can be helpful for larger-scale changes.

What should I do to increase the likelihood that my pull request is merged into master?

Make it as easy as possible for a maintainer to just click the big green Merge button 😄 . This means including test coverage for any added features or fixed bugs and updating documentation to reflect any visible behavior changes.

Are tests required?

See the answer to the third question. In general, including test coverage for any changes made makes it much more likely that a PR will be merged. If you're unsure how to test something specific, usually a maintainer can point you in the right direction if you ask ahead of time in the motivating issue (or even call it out in the PR).

I'll aim to write up a CONTRIBUTING.md at some point that attempts to capture as much of this as possible, but in the meantime if you (or anyone else) would like to take a stab at it, I'd be happy to iterate on it collaboratively!