Contributing to Dinit's development =================================== At the time of writing there have been only minimal outside contributions, but I'm writing this contribution guide in readiness for contributions being made by other persons. Before making a contribution ---------------------------- Many open-source project have limited resources, in particular people-power. While this might seem to make any outside contribution desirable, that's not always the case. Before making a contribution, you should consider: - whether or not the contribution is generally useful (is it just scratching a personal itch?). - whether the contribution being accepted will create a maintenance/development burden going forward, and whether you are prepared to assist with that burden (or whether the benefit outweighs the cost generally). - whether the change fits in with the philosophy and design direction of the project. For contribution of new features, the only way for sure is often to ask the maintainers - preferably before you've done the work, since it isn't so nice to put work into someone else's project only to be told it's not wanted! - whether the change will be convenient for users and other developers. Introducing build-time dependencies, for example, may cause inconvenience. Does the benefit of the change really outweigh this? Documentation contributions are often appreciated, though you should be careful to ensure that the style and conventions used match those of the existing documentation. Bugfixes, likewise, are usually appreciated. However, it's important to understand whether what you are fixing really is a bug, or whether it's intended behaviour - if there's any doubt at all, you should ask the maintainers. Also, if the proposed fix is not completely straight-forward or is "hacky", you should consider discussing it with maintainers first. Remember: - submitting a merge request is an act that, by itself, creates work for the maintainer(s)! - always talk to the maintainers before doing a significant amount of work on a project, and consider doing so before commencing even minor work - if you disagree with a maintainer, you need to consider who has invested more in the project. Maintainers will often have a good "feel" for how their software should work, and they may have a philosophy that doesn't align with your own. Arguing over subjective issues may frustrate both parties. It may be better to let it go! Code contributions ------------------ In general, code contributions: - should follow existing style and conventions - should keep the design considerations in mind (read the DESIGN document) - should be accompanied by appropriate documentation additions/updates - should include tests where practical As the maintainer and original author, I maintain the right to reject or request modification to contributions, for failure to comply with the points listed above, for failure to adhere to a reasonable standard of conduct (see Contributor Conduct below), or because I deem that the contribution includes features outside the intended scope. Feel free to contact me to sound out whether I would be likely to accept a submission for a particular feature. Contributors should feel free to add themselves to the CONTRIBUTORS list as part of the patch/pull request. I will endeavour to respond to all offered contributions with civility and respect, even if I choose not to accept them. Contributor Conduct ------------------- There is no complete "code of conduct" for Dinit contributors, but contributions will only be accepted from those who are civil and respectful towards others. Specific behaviours that won't be tolerated from contributors include but are not limited to: - discrimination generally, and especially if based on race, gender or gender identity, sexual preference, etc - personal attacks, insults, or harassment, or incitement thereof, against others - unnecessarily drawing attention to another's personal issues or conditions, or other personal details If a person is deemed to have engaged in negative behaviour such as from the list above, contributions from them will not be accepted and the perpetrator may be blocked from communications related to Dinit development. Note that such negative behaviours need not have occurred in a public forum, and need not be related to Dinit development. In short: don't be nasty to others; arseholes won't be tolerated. If you feel that a contributor has behaved inappropriately, please feel free to contact me to discuss it; such communication will be kept confidential (unless and until otherwise agreed).