CONTRIBUTING 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. Contributing to Dinit's development
  2. ===================================
  3. At the time of writing there have been only minimal outside contributions, but I'm writing this
  4. contribution guide in readiness for contributions being made by other persons.
  5. Before making a contribution
  6. ----------------------------
  7. Many open-source project have limited resources, in particular people-power. While this might seem
  8. to make any outside contribution desirable, that's not always the case. Before making a
  9. contribution, you should consider:
  10. - whether or not the contribution is generally useful (is it just scratching a personal itch?).
  11. - whether the contribution being accepted will create a maintenance/development burden going
  12. forward, and whether you are prepared to assist with that burden (or whether the benefit
  13. outweighs the cost generally).
  14. - whether the change fits in with the philosophy and design direction of the project. For
  15. contribution of new features, the only way for sure is often to ask the maintainers - preferably
  16. before you've done the work, since it isn't so nice to put work into someone else's project only
  17. to be told it's not wanted!
  18. - whether the change will be convenient for users and other developers. Introducing build-time
  19. dependencies, for example, may cause inconvenience. Does the benefit of the change really
  20. outweigh this?
  21. Documentation contributions are often appreciated, though you should be careful to ensure that the
  22. style and conventions used match those of the existing documentation.
  23. Bugfixes, likewise, are usually appreciated. However, it's important to understand whether what you
  24. are fixing really is a bug, or whether it's intended behaviour - if there's any doubt at all, you
  25. should ask the maintainers. Also, if the proposed fix is not completely straight-forward or is
  26. "hacky", you should consider discussing it with maintainers first.
  27. Remember:
  28. - submitting a merge request is an act that, by itself, creates work for the maintainer(s)!
  29. - always talk to the maintainers before doing a significant amount of work on a project, and
  30. consider doing so before commencing even minor work
  31. - if you disagree with a maintainer, you need to consider who has invested more in the project.
  32. Maintainers will often have a good "feel" for how their software should work, and they may have
  33. a philosophy that doesn't align with your own. Arguing over subjective issues may frustrate both
  34. parties. It may be better to let it go!
  35. Code contributions
  36. ------------------
  37. In general, code contributions:
  38. - should follow existing style and conventions (also: read and follow CODE-STYLE)
  39. - should be appropriately* commented in accordance with existing style
  40. - should keep the design considerations in mind (read the DESIGN document)
  41. - should be accompanied by appropriate documentation additions/updates
  42. - should include tests where practical
  43. [*] There is a little lee-way for comments, "truly obvious" code does not need to be and should
  44. not be commented.
  45. As the maintainer and original author, I maintain the right to reject or request modification to
  46. contributions, for failure to comply with the points listed above, for failure to adhere to a
  47. reasonable standard of conduct (see Contributor Conduct below), or because I deem that the
  48. contribution includes features outside the intended scope. I encourage anyone who is considering
  49. making a contribution to contact me to sound out whether I would be likely to accept a submission
  50. for a particular feature or behavioural change.
  51. Contributors should feel free to add themselves to the CONTRIBUTORS list as part of the patch/pull
  52. request.
  53. I will endeavour to respond to all offered contributions with civility and respect, even if I
  54. choose not to accept them.
  55. Contributor Conduct
  56. -------------------
  57. There is no complete "code of conduct" for Dinit contributors, but contributions will only be
  58. accepted from those who are civil and respectful towards others. Specific behaviours that won't
  59. be tolerated from contributors include but are not limited to:
  60. - discrimination generally, and especially if based on race, gender or gender identity, sexual
  61. preference, etc
  62. - personal attacks, insults, or harassment, or incitement thereof, against others
  63. - unnecessarily drawing attention to another's private or personal details
  64. If a person is deemed to have engaged in negative behaviour such as from the list above,
  65. contributions from them will not be accepted and the perpetrator may be blocked from
  66. communications related to Dinit development. Note that such negative behaviours need not have
  67. occurred in a public forum, and need not be related to Dinit development.
  68. In short: don't be nasty to others; arseholes won't be tolerated.
  69. If you feel that a contributor has behaved inappropriately, please feel free to contact me to
  70. discuss it; such communication will be kept confidential (unless and until otherwise agreed).