Skip to content

Latest commit

 

History

History
29 lines (15 loc) · 3.08 KB

CONTRIBUTING.md

File metadata and controls

29 lines (15 loc) · 3.08 KB

Contributing to Quelea

Contributions are always welcome! There's three main ways you can contribute to Quelea - you can report issues, maintain and add translations, and contribute to the code directly.

Reporting issues

No qualms here - any issues you find, or anything you feel should be included, just create an issue and we'll get to it. Don't worry if you're not sure if it's something that's already been added, if so we'll just point it out to you and then close it off.

Translations

In brief, the guidelines for contributing to translations can be found here: https://quelea.org/lang/

We're always happy to receive pull requests containing missing labels, or corrections to existing labels - so long as these are in the correct format, there's no reason we'd reject these pull requests (and hey, if they're in the incorrect format somehow then we're always happy to work with you to fix it!)

It's also fantastic when someone contributes a new translation, and we gladly accept these too! The only caveat is that you must speak the language fluently, and most of the labels must be translated. We don't mind if the bulk are done and you aim to fill in the rest at a later point, but we won't accept new translations that just have a few lines translated.

Code

It's always fantastic when new code contributors come on board! We generally accept bug fixes, so long as the commit comments are clear, the fixes clearly won't introduce any new issues (or at least have a very low probability of doing so), and the code is well written and clearly documented. In the case where any of these aren't the case, then we won't accept right away, but where possible we'll happily work with you to bring your contribution to the point where we can accept it.

We're usually a little more cagey about accepting pull requests for new features out of the blue - they're great to have, but we have to make sure that they're implemented well, not rushed, and the core team agrees on any UX implications they may have. If you're thinking of a new feature, then talk to us first (feel free to create an issue for it if one doesn't exist already.)

Major refactorings of the project, or a significant part of it, are very unlikely to be accepted unless specifically discussed and agreed in advance. (This is usually something that we'd leave to the core developers though.)

Final notes

Please don't let any of the above put you off contributing! We love contributions, and we're always happy to work with you where we can. We just can't promise to accept everything - Quelea now has a reasonable user base and the decisions we make around the code have real world implications, so we have to be convinced that contributions are definitely going to have a positive effect on our users before we accept them.

Of course, if you want to make changes you don't have to push them back to us - that's the beauty of open source! If you've got a bunch of changes you think would make Quelea better for your particular use case, then feel free to fork it, make all the changes you like and then use it how you please!