Contribution Guidelines

[diegoperini]

It seems I will be needing to add more stuff to this for my personal use. Instead of forking the library and including it privately, I'd like to do it properly and send pull requests that can be merged to the main repository.

I can just go and hack some stuff but if there were some guidelines that would prevent me shooting in my foot, it'd be much easier. For instance, this can be an example of one such case.

[MichaReiser]

Hy @diegoperini

I appreciate it that you intend to invest your time to extend the library over forking it. And you are right, a contribution guideline is so far missing.

I'm not sure if I find time to create some contribution guidelines in the next few days since I'm in the middle of moving to another country. But who knows. Maybe I find some time.

In the meantime, I can maybe point out the most important things a PR should have:

• TS definitions are present in the typing file
• Build passes for node 4+ and all llvm versions >= 4 (checked by the Travis)
• A test for each added method that calls the method with valid arguments
• Added methods should validate the received arguments and throw in case the arguments are invalid.
• It is appreciated if the PR references the relevant LLVM documentation or links to an issue that contains the reference.

The most important thing. If you're stuck or are uncertain about anything feel free to create an issue or PR, and I will try to help you. You can also create WIP pull request if you are uncertain if you are doing it the "right" way.

Do you eventually know a good template for a contribution guideline that I could use?

[diegoperini]

I stumbled upon this. It maybe overkill to include all the headlines but at least it looks like a good start.