CONTRIBUTING

   1 I encourage everyone to contribute. If you want to contribute but do not have a
   2 GitHub account or wish to remain anonymous, you can send an e-mail to the author
   3 directly.
   4
   5 1. Bug reports
   6
   7 To submit a bug report please identify clearly what happened and what was
   8 expected; the configuration used at the time and some system attributes. The
   9 configuration options can be obtained from running matilda --info. The system
  10 attributes should include the kernel version, compiler version, and versions of
  11 other software used to communicate with Matilda. If the bug is reproducible also
  12 attempt to provide a script or SGF file that can reproduce it, plus running
  13 Matilda with logging enabled (--log ewpi) and submitting the log file generated.
  14
  15 2. Suggestions, questions, ideas, commentary
  16
  17 Just fire away. Include the details you think are pertinent. If you reference a
  18 scientific paper that is not available online for free, an excerpt or summary of
  19 its contents would be appreciated.
  20
  21 3. Pull requests
  22
  23 If you want to help but don't know where to start, start by reading the issue
  24 tracker. Sometimes smaller things are also marked TODO in the source code.
  25
  26 To submit a pull request first read the src/README file on some code guidelines.
  27 Before committing to a certain problem you may also want to get in touch to make
  28 sure that is a worthwhile endeavor. If you decide to go ahead with the pull
  29 request be reminded it is assumed to follow the licensing model (permissive free
  30 software) of the rest of Matilda. If you require a different licensing model, or
  31 want to submit something that is not yours, please state so clearly in the pull
  32 request and in the specific files. Also it may be possible that your employer
  33 owns your contributions to open source software, in which case their permission
  34 is also required.
  35
  36 Please test all pull requests locally before submitting them, this includes
  37 testing a few different board sizes, with some options on and off, and so on (to
  38 the extent that you think is reasonable). Please also clearly introduce the
  39 problem you identify in your pull request, your approach to it, and what you are
  40 committing. This is very important since you might make mistakes and it goes a
  41 long way to understand what you tested better and what part of your work was
  42 less worked on. If your work aimed at increasing the strength of the program,
  43 please report the results and settings of whatever benchmarking you did.
  44
  45 If you need any help before submitting a pull request, or have a great idea but
  46 don't have the time or experience on the project to implement it, just open an
  47 issue.
  48
  49 Most of all, have fun contributing to Matilda.