Merge branch 'update-contrib' of github.com:skulpt/skulpt

Author: LeszekSwirski

CONTRIBUTING.md

@@ -5,15 +5,13 @@ This is the contribute.md of our project. Great to have you here. Here are a few
 
 ## Team members
 
-* [Brad Miller](https://github.com/bnmnetp) -- Current maintainer
-* [Scott Rixner](https://github.com/rixner)
-* [Marie Chatfield](https://github.com/mchat)
-* [Albert-Jan Nijburg](https://github.com/albertjan)
-* [Bob LaCatena](https://github.com/blacatena)
-* [David Holmes](https://github.com/david-geo-holmes)
-* [Charles Severance](https://github.com/csev)
-* [Scott Graham](https://github.com/sgraham) -- although not active at the moment, Scott is the father of Skulpt
+The list of people who have contributed to Skulpt is too big and dynamic to be accurate 
+in a document like this.  Luckily Github does an excellent job of keeping track of
+[people who have contributed](https://github.com/skulpt/skulpt/graphs/contributors)
 
+[Brad Miller](https://github.com/bnmnetp) is the current owner of the project.  But see below for 
+the full list of people with commit privileges.
+ 
 ## Learn & listen
 
 This section includes ways to get started with your open source project. Include links to documentation and to different communication channels:
@@ -62,6 +60,20 @@ We try to get to pull requests in a very timely way so they don't languish. Noth
 
 ## Coding Style and Conventions
 
+Here are some coding conventions to keep in mind:
+ 
+* ``Sk.ffi.remapToJs`` and ``Sk.ffi.remapToPy`` are your friends.  They take care of the details 
+of going from a Python type to a Javascript type and vice versa.  They are smart enough to work
+with common types and even work well recursively converting containers.  ``Sk.ffi.remapToJs`` is 
+**definitely preferred** over  ``foo.v``  
+* Use the ``pyCheckArgs`` function at the beginning of anything that will be exposed to a Python programmer.
+* Check the types of arguments when you know what they must be.
+* Explicitly return ``Sk.builtin.null.null$`` for functions and methds that should return ``None``
+* If you are adding a module or package to the library, respect the package/module conventions.
+    * modules should be named ``foo.js`` or ``foo.py`` 
+    * packages should be a directory with an ``__init__.js`` or ``__init__.py`` file, and possibly additional modules.
+
+
 In summer of 2014, we adopted the following style and conventions for our code:
 
 * Braces:  One True Brace style -- that means open braces go on the same line as the
@@ -87,6 +99,34 @@ Our Travis script will run jshint over all the source.  You should run jshint as
 Many editors and IDEs do this automatically for you -- Atom, PyCharm, TextMate has a
 nice plugin called JSLintMate.  You can easily install [jshint](http://jshint.org) using the ``npm`` package manager that comes with [node](http://nodejs.org).
 
+
+## Committers
+
+The committers are people who are responsible for reviewing and approving pull requests .  These are 
+generally people who have been around the project for a while and have "proven" themselves by contributing
+good code and ideas to the Skulpt.  This list may change over time as people gain or lose interest in
+Skulpt.  If you would like to volunteer contact Brad.
+
+Although a lot of our testing, and checking for adherence to the style guidelines is done automatically
+the review process I would recommend for committers is as follows:
+
+1.  Look at the diffs for each file on github, if it is pretty obvious what they are doing is correct then that is a good sign.
+2.  Look at the tests provided with the PR and try to think if there are additional tests that would provide better coverage. If you think additional tests are needed then you should let the owner of the PR know and have them add more tests. All new PRs that are adding new features should be using the new unittest framework, not the old numbered framework.
+3.  Pull the the PR down to your local machine and run all the tests locally.  (Unless it is really trivial)
+4.  If the code looked a bit more complicated when you examined the diffs, then you should bring it up in your editor and look over the code in context and try to understand it better.  If there are issues with how the code is written or if it is unclear about why something was done, then have that conversation with the owner of the PR.
+5.  Many of us have our own projects that exercise Skulpt to its limits. If you are particularly concerned about a PR then you may want to try out the built js files in your environment.
+6.  It is always appropriate to raise questions and have a group conversation about anything that looks particularly problematic or risky.
+7.  With the new style unit tests, You should ask the submitter to file issues for tests that they comment out.  This will let us track completeness over time.  Not every test needs its own issue.  Something like 'when blah feature is added enable  tests x,y,z in foo_test.py' should work.
+ 
+The current group of committers is as follows:
+
+* Brad Miller  bnmnetp
+* Scott Rixner rixner
+* Albert-Jan   albertjan
+* Meredydd Luff meredydd
+* Leszek Swirski  LeszekSwirski 
+* Ben Wheeler  bzwheeler
+
 # Documentation
 
 If documentation is your thing, have we got a job for you.  There are a few blog posts on how to write modules and work with skulpt but very little of the core is documented beyond the source.  Having some good documentation for developers would really help get more people involved.