Contrib doc updates

Author: alandipert

CONTRIBUTING.md

@@ -2,12 +2,9 @@
 
 Why, hello! :wave: Thank you for your interest in contributing to Boot.
 
-There are a lot of reasons you might be interested in contributing to Boot.
-Because of all the possibilities, there's a chance nothing here will help you.
-
-You should know that we have a friendly and active community that's generally
-happy to answer any questions you might have that might not be served by this
-document. The best places to find us are:
+Before reading, please know that we have a friendly and active community. We're
+generally happy to answer any questions you might have that aren't served by
+this document. The best places to find us are:
 
 * [The `#boot` channel on Clojurians Slack][slack]
 * [Our Discourse site][discourse].
@@ -86,7 +83,72 @@ the [General Contribution Guidelines](#general-contribution-guidelines).
 
 ## Contributing a Feature
 
-TODO
+Features are things like new tasks, new arguments for existing "builtin" tasks, or
+anything else that changes or augments the behavior of Boot.
+
+### New arguments to builtin tasks
+
+We accept these pretty regularly. They're backward-compatible from a naming
+perspective because we the Boot maintainers "own" the namespace of argument
+names. That is, builtin task arguments are not user-extensible, and so can't
+conflict with users' `build.boot` files.
+
+However, the number of available argument names for a task is finite, because
+arguments are limited to the alphabetic short option character, and there are only 25
+available: 26 - 1 for `h`.
+
+The best new task arguments:
+
+* Don't change the behavior of any existing argument or combination of
+  arguments. That is, if an argument `-c` is made available, the meaning of `-a
+  -b` should stay the same. `-a -b -c` can do something different.
+* Are clearly documented.
+
+### New tasks
+
+We're least likely to accept these, because from a naming perspective, they can
+interfere with names a user creates in `boot.user` via `build.boot`. All of the
+builtin tasks are referred by default into the user's `build.boot`, and each
+time we make one, we effectively take away a potentially good name from a user.
+
+Of course, the user can `ns-unmap` names they don't want to conflict with, but
+this requires a `build.boot` or `~/.boot/profile` code change on their part. We
+try very hard to avoid requiring Boot users to change code because of incidental
+changes.
+
+#### Your own task library
+
+If you have an idea for a task that you'd like to distribute because you think
+it would be useful to others, you should first consider making your own library
+that contains that task. It's best to do this when:
+
+* The task doesn't *need* to run inside Boot: it doesn't influence other builtin
+  tasks or leverage Boot's ownership of the filesystem, classpath, and entry
+  point.
+* You want to distribute the task before the next Boot release.
+
+For example, Boot has no built-in `new` task. Instead, there is a `boot/new`
+library that provides one. The `new` task can be invoked like:
+
+    boot -d boot/new new -t app -n my-app
+    
+This works because `boot/new` exports
+the
+[`new`](https://github.com/boot-clj/boot-new/blob/19c0cf2f585cfe0a3d379af854f5e77f4834bf04/src/boot/new.clj#L4) task
+in its `ns` declaration. The `-d` option to Boot looks for exported tasks when
+it loads dependencies, and makes them available at the command line.
+
+If you had idea for a better `new` task, you could create it, and push it to
+Clojars yourself. It would then be accessible to Boot users like this:
+
+    boot -d YourName/new new -t app -n my-app
+    
+This task is also available to users programmatically. They could use your task via:
+
+```clojure
+(set-env! :dependencies '[[YourName/new "1.0.0"]])
+(require '[YourName.new :refer [new]]')
+```
 
 [api-docs]: https://github.com/boot-clj/boot/tree/master/doc
 [changes]: https://github.com/boot-clj/boot/blob/master/CHANGES.md