CONTRIBUTING

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 (also: read and follow CODE-STYLE)
 - should be appropriately* commented in accordance with existing style
 - should keep the design considerations in mind (read the DESIGN document)
 - should be accompanied by appropriate documentation additions/updates
 - should include tests where practical

[*] There is a little lee-way for comments, "truly obvious" code does not need to be and should
    not be commented.

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. I encourage anyone who is considering
making a contribution to contact me to sound out whether I would be likely to accept a submission
for a particular feature or behavioural change.

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 private or 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).