Address PR comments

* Make GIT_INLINE an internal definition so it cannot be used in
  public headers
* Fix language in CONTRIBUTING
* Make index caps API use signed instead of unsigned values

1 files changed, 10 insertions, 9 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 0ae75c7ce..06aa4c1dd 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -89,7 +89,7 @@ code snippet.
 
 The public API of `libgit2` is [ANSI C](http://en.wikipedia.org/wiki/ANSI_C)
 (a.k.a. C89) compatible.  Internally, `libgit2` is written using a portable
-subset of C99 - in order to compiler with GCC, Clang, MSVC, etc., we keep
+subset of C99 - in order to compile with GCC, Clang, MSVC, etc., we keep
 local variable declarations at the tops of blocks only and avoid `//` style
 comments.  Additionally, `libgit2` follows some extra conventions for
 function and type naming, code formatting, and testing.
@@ -109,14 +109,15 @@ are any unresolved issues to jump in on.  Also, here is a list of some
 smaller project ideas that could help you become familiar with the code
 base and make a nice first step:
 
-* Convert a `git_*modulename*_foreach()` callback-based iteration API
-  into a `git_*modulename*_iterator` object with a create/advance style
-  of API.  This helps folks writing language bindings and usually isn't
-  too complicated.
-* Write a new `examples/` program that mirrors a particular core git
-  command.  (See `examples/diff.c` for example.)  This lets you (and us)
-  easily exercise a particular facet of the API and measure compatability
-  and feature parity with core git.
+* Look at the `examples/` programs, find an existing one that mirrors a
+  core Git command and add a missing command-line option.  There are many
+  gaps right now and this helps demonstrate how to use the library.
+* Pick a Git command that is not emulates in `examples/` and write a new
+  example that mirrors the behavior.  Examples don't have to be perfect
+  emulations, but should demonstrate how to use the libgit2 APIs to get
+  results that are similar to Git commands.  This lets you (and us) easily
+  exercise a particular facet of the API and measure compatability and
+  feature parity with core git.
 * Submit a PR to clarify documentation! While we do try to document all of
   the APIs, your fresh eyes on the documentation will find areas that are
   confusing much more easily.