Contributing

So you'd like to contribute to TaskBotJS? Awesome!

Bug Guidelines

• Bugs aren't support requests. "I'm not sure how to do X" does not then imply "X is broken." Please prepend any issue based around support requests with the string SUPPORT: so I can prioritize them appropriately.
• Working code speaks volumes! If you've got an example that illustrates a bug or a problem in TaskBotJS, an example is worth multiple paragraphs.
• Don't pressure. I'm sure that your bug is important to you, and building solid software is important to me. But attempting to hurry along the process of bug fixing by describing how urgent it is to your company is unhelpful and just creates noise.

If your issue is sufficiently urgent, I offer commercial support for urgency and business-critical cases, which (in addition to a bunch of features) offers e-mail support with 95% turnaround within 24 hours and priority consideration for issues and fixes.

Code Guidelines

• I'll need a CLA signed before I look at your code. TaskBotJS Pro is an income stream for me, and while TaskBotJS proper is LGPL and will remain so, I do have to ask for a license to use your code commercially. If that's a deal-breaker, I totally understand, and would be happy to instead accept bug reports.
• I'll never ask somebody to write code for TaskBotJS Pro/Enterprise. That'd be really weird, wouldn't it? For the open-source version, pull requests win: if I don't think much of a given feature I may still gratefully accept a pull request. For TaskBotJS Pro and Enterprise, these things are feature requests. ;-) I suppose that, if you're really into a feature, I'd consider it for inclusion into TaskBotJS so that you don't have to maintain a fork, but the bar will probably be a little higher.
• New code needs tests. We've got ts-jest; we should be using it. A lot of TaskBotJS's base code is pulled from other, existing projects, and so while I've tried to write composable and very testable code our coverage is below where I want it to be (and below where it will be). New code must be exerciseable via tests if at all reasonable. If you're new to unit and integration testing, that's totally fine--I'm happy to help contributors who come with a PR in hand figure out the best way to test their code!
• Avoid stateful globals. The global namespace should support multiple fully-independent instantiations of the TaskBotJS service within a single process space. We don't recommend doing this, but designing with that in mind often leads to better code with cleaner separation of concerns.

Documentation Guidelines

• Try to adopt an informal, but precise style of writing; consider the rest of the documentation as examples.
• Eighty characters is preferable. If your editor doesn't support hard wrapping, consider something like Visual Studio Code and its Rewrap extension.
• We use Oxford commas.