Contributing guidelines

[binaryoverload]

So, at the moment, our contributing guidelines are quite empty!

At the moment, the code style and repository structure are over on the wiki.

What should we add to this? I'm a bit stuck for ideas 😅

[JamesHawkinss]

Perhaps something about respecting and appreciating other contributors? So that when we release, we don't get scummy people being rude when given advice or suggestions to improve their PRs.

[binaryoverload]

That's sorta in the code of conduct but yeah it's a good possibility!

[JamesHawkinss]

Not sure if this is already written elsewhere, but something about not starting a task that someone else has started. Say if someone is assigned to an issue on the GH Project, then let them complete it unless they specifically say otherwise.

[JamesHawkinss]

Make it a necessity for contributors to be in our Discord server, so that we can communicate more easily with them and they're kept up to date with crap.

[binaryoverload]

I don't think it's a necessity but we'll strongly advise it. Along with this I was thinking something like:

Tips for contributing:

• Make yourself familiar with our codebase! This will help you avoid a lot of changes when it comes to PR time
• Make sure you are familiar with the JDA library. The docs can very helpful
• We recommend you join our discord server so we can help if you run into any issues!

[DeadlyFirex]

Ideas for on the guidelines

• Do not feature something useless, take a look at what is important and implement that.
• Behave respectfully to people on your PRs, take their advice seriously and be patient
• Fixes and improvements are to be put as much as possible in one PR
• When reporting an issue, be as complete as possible, try testing the bug and actually post stacktraces that will help the devs understand what is going on.
• When PRing, try to be as complete as possible, don't declare unnecessary variables and try to inline if possible
• Take a look at Cascade/CascadeBot-wiki and try to read all of that in advance of your PRs.
• If someone is already developing on an idea and you want to extend it, try suggesting on that same PR instead of making your own.
• If you know your code is not complete yet, PR it as a draft instead of an full PR.

(aside from that, maybe guides on E.G how do I debug, how do I post an issue, how do I test my changes, etc)

[binaryoverload]

That's a very thorough list, very helpful!