CONTRIBUTING.md

   1 # Contributing to GNU social
   2
   3 First of all, if you're reading this intending to contribute to GNU social,
   4 thanks! Free software development only happens when people like you take an
   5 interest in giving back to the software they themselves use, and their
   6 community.
   7
   8 When contributing to this repository, please first discuss the change you wish to
   9 make via issue, email, or any other method with the owners of this repository before
  10 making a change.
  11
  12 There's a few files you should read before going forward with a merge request
  13 or a patch submission.  They detail what this file touches on in brief.  They
  14 are:
  15
  16 * `DOCUMENTATION/DEVELOPERS/CONTRIBUTING/coding_standards.md`: How your code should be structured and formatted to be
  17   accepted into the GNU social codebase.
  18 * `/DOCUMENTATION/DEVELOPERS/CONTRIBUTING/merge_request_checklist.md`: A quick checklist to review before submission.
  19
  20
  21 ## Merge Request Process
  22
  23 1. Ensure you strip any trailing spaces off and checked the file with php-cs-fixer
  24 2. Increase the version numbers in any examples files and the README.md to the new version that this
  25    Pull Request would represent. The versioning scheme we use is [SemVer](http://semver.org/).
  26 3. You may merge the Pull Request in once you have the sign-off of two other developers, or if you
  27    do not have permission to do that, you may request the second reviewer to merge it for you.
  28
  29
  30 ## Coding Standards
  31
  32 Since we will be expected to maintain your code once it's submitted, we ask you
  33 to adhere to certain coding standards that make it easier for us to do so. If
  34 code doesn't follow them, it will be rejected, so please read up on these.
  35
  36
  37 ## Bug Reports
  38
  39 Please report bugs to the issue tracker at
  40 <https://notabug.org/diogo/gnu-social/issues> Avoid assigning the labels
  41 yourself, as these are for the development team to assign priority and area of
  42 coverage to a subject. Please only submit something here if you are certain it
  43 is a bug or represents a feature enhancement that we do not presently have. If
  44 you are uncertain whether it's a bug, please feel free to ask
  45 at #social IRC channel on freenode.net https://www.freenode.net/.
  46
  47 When reporting a bug, please try to include as much information as possible,
  48 including the environment being run on (if it's a common LAMP stack just give
  49 us version numbers of the main stack components, that's fine), and the specific
  50 error you get. If you do not get a client-facing error, please check the PHP
  51 error_log and ensure there isn't something silently reported there, as well as
  52 the GNU social log. Try to include steps to reproduce the error as well, as if
  53 we cannot reproduce the error, we can't fix it!
  54
  55 It is perfectly acceptable to reference the archive page of a discussion on the
  56 mailing list for the bug report, by the way, as long as it includes all the
  57 information we need for a bug report.
  58
  59
  60 ## Submitting Feature Requests / Enhancement Requests
  61
  62 Social media is constantly evolving, and we welcome ideas about how we can
  63 change and evolve GNU social to keep it the excellent piece of software that it
  64 is. However, there are a few things we ask you do when submitting feature
  65 requests:
  66
  67 1. Understand that since we have a limited amount of developers and these people
  68 contribute in their free time, we may prioritize things differently than you
  69 value them. Oftentimes this is because certain requests involve less changes
  70 to the existing codebase than others, and therefore this makes them easier
  71 to add.
  72 2. Please search the existing feature requests and enhancements to see if a
  73 similar request exists. If one does but you have different ideas about how
  74 to do it or what it should entail, please add a comment to the existing idea
  75 rather than create a new one for your "version" of it. Duplicate submissions
  76 mean we spend more time maintaining the tracker and less time actually
  77 working on the codebase!
  78 3. When outlining the way that you see something working, don't be afraid to be
  79 as detailed as possible! We may not implement it exactly as you describe for
  80 any variety of reasons, but the more concrete and fleshed out an idea is, the
  81 easier it is for us to know what you want and be able to implement it in a
  82 sane and secure fashion.
  83 4. When describing a possible new idea and its mechanisms of operation, the key
  84 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
  85 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the issue submission
  86 are to be interpreted as described in RFC 2119.
  87 <https://tools.ietf.org/html/rfc2119>
  88
  89 Finally, and just as a call back to the first point, realize just because we
  90 might not rush to implement something, doesn't mean that we don't want to
  91 implement it! We would rather take the time to do something right the first
  92 time, then hurriedly apply a new idea, or a fix, only to have to patch it later.
  93
  94
  95 ## Branch of Code Submissions
  96
  97 Unless you've been specifically directed otherwise, all submissions of code
  98 should be against the `nightly` branch, so make sure any modifications are based
  99 on Nightly.
 100
 101
 102 ## Copyright / Licensing
 103
 104 You acknowledge that by submitting code to GNU social, you are licensing it under
 105 the GNU AGPLv3 unless there is an extenuating circumstance where it would be
 106 licensed differently (such as modifications to an external library we include
 107 such as Stomp).
 108
 109 You also acknowledge that unless you assign a copyright explicitly, it will be
 110 assumed to be assigned to GNU social.
 111
 112 Thanks for considering submission, and happy hacking!