CONTRIBUTING.md

   1 # Welcome to libgit2!
   2
   3 We're making it easy to do interesting things with git, and we'd love to have
   4 your help.
   5
   6 ## Licensing
   7
   8 By contributing to libgit2, you agree to release your contribution under the terms of the license.
   9 For code under `examples`, this is governed by the [CC0 Public Domain Dedication](examples/COPYING).
  10 All other code is released under the [GPL v2 with linking exception](COPYING).
  11
  12 ## Discussion & Chat
  13
  14 We hang out in the #libgit2 channel on irc.freenode.net.
  15
  16 Also, feel free to open an
  17 [Issue](https://github.com/libgit2/libgit2/issues/new) to start a discussion
  18 about any concerns you have.  We like to use Issues for that so there is an
  19 easily accessible permanent record of the conversation.
  20
  21 ## Reporting Bugs
  22
  23 First, know which version of libgit2 your problem is in and include it in
  24 your bug report.  This can either be a tag (e.g.
  25 [v0.17.0](https://github.com/libgit2/libgit2/tree/v0.17.0) ) or a commit
  26 SHA (e.g.
  27 [01be7863](https://github.com/libgit2/libgit2/commit/01be786319238fd6507a08316d1c265c1a89407f)
  28 ).  Using [`git describe`](http://git-scm.com/docs/git-describe) is a great
  29 way to tell us what version you're working with.
  30
  31 If you're not running against the latest `development` branch version,
  32 please compile and test against that to avoid re-reporting an issue that's
  33 already been fixed.
  34
  35 It's *incredibly* helpful to be able to reproduce the problem.  Please
  36 include a list of steps, a bit of code, and/or a zipped repository (if
  37 possible).  Note that some of the libgit2 developers are employees of
  38 GitHub, so if your repository is private, find us on IRC and we'll figure
  39 out a way to help you.
  40
  41 ## Pull Requests
  42
  43 Our work flow is a typical GitHub flow, where contributors fork the
  44 [libgit2 repository](https://github.com/libgit2/libgit2), make their changes
  45 on branch, and submit a
  46 [Pull Request](https://help.github.com/articles/using-pull-requests)
  47 (a.k.a. "PR").
  48
  49 Life will be a lot easier for you (and us) if you follow this pattern
  50 (i.e. fork, named branch, submit PR).  If you use your fork's `development`
  51 branch, things can get messy.
  52
  53 Please include a nice description of your changes with your PR; if we have
  54 to read the whole diff to figure out why you're contributing in the first
  55 place, you're less likely to get feedback and have your change merged in.
  56
  57 If you are working on a particular area then feel free to submit a PR that
  58 highlights your work in progress (and flag in the PR title that it's not
  59 ready to merge). This will help in getting visibility for your fix, allow
  60 others to comment early on the changes and also let others know that you
  61 are currently working on something.
  62
  63 ## Porting Code From Other Open-Source Projects
  64
  65 `libgit2` is licensed under the terms of the GPL v2 with a linking
  66 exception.  Any code brought in must be compatible with those terms.
  67
  68 The most common case is porting code from core Git.  Git is a pure GPL
  69 project, which means that in order to port code to this project, we need the
  70 explicit permission of the author.  Check the
  71 [`git.git-authors`](https://github.com/libgit2/libgit2/blob/development/git.git-authors)
  72 file for authors who have already consented.
  73
  74 Other licenses have other requirements; check the license of the library
  75 you're porting code *from* to see what you need to do.  As a general rule,
  76 MIT and BSD (3-clause) licenses are typically no problem.  Apache 2.0
  77 license typically doesn't work due to GPL incompatibility.
  78
  79 If you are pulling in code from core Git, another project or code you've pulled from
  80 a forum / Stack Overflow then please flag this in your PR and also make sure you've
  81 given proper credit to the original author in the code snippet.
  82
  83 ## Style Guide
  84
  85 `libgit2` is written in [ANSI C](http://en.wikipedia.org/wiki/ANSI_C)
  86 (a.k.a. C89) with some specific conventions for function and type naming,
  87 code formatting, and testing.
  88
  89 We like to keep the source code consistent and easy to read.  Maintaining
  90 this takes some discipline, but it's been more than worth it.  Take a look
  91 at the
  92 [conventions file](https://github.com/libgit2/libgit2/blob/development/CONVENTIONS.md).
  93
  94 ## Starter Projects
  95
  96 So, you want to start helping out with `libgit2`? That's fantastic? We
  97 welcome contributions and we promise we'll try to be nice.
  98
  99 If you want to jump in, you can look at our issues list to see if there
 100 are any unresolved issues to jump in on.  Also, here is a list of some
 101 smaller project ideas that could help you become familiar with the code
 102 base and make a nice first step:
 103
 104 * Convert a `git_*modulename*_foreach()` callback-based iteration API
 105   into a `git_*modulename*_iterator` object with a create/advance style
 106   of API.  This helps folks writing language bindings and usually isn't
 107   too complicated.
 108 * Write a new `examples/` program that mirrors a particular core git
 109   command.  (See `examples/diff.c` for example.)  This lets you (and us)
 110   easily exercise a particular facet of the API and measure compatability
 111   and feature parity with core git.
 112 * Submit a PR to clarify documentation! While we do try to document all of
 113   the APIs, your fresh eyes on the documentation will find areas that are
 114   confusing much more easily.