adding instructions for contentprovider extension
MODIFY
docs/source/architecture.md
docs/source/architecture.md
-# Architecture of repo2docker
+# Architecture
This is a living document talking about the architecture of repo2docker
from various perspectives.
+```eval_rst
+.. _buildpacks:
+```
+
## Buildpacks
The **buildpack** concept comes from [Heroku](https://devcenter.heroku.com/articles/buildpacks)

MODIFY
docs/source/contributing/buildpack.md
docs/source/contributing/buildpack.md
-# Adding a new buildpack to repo2docker
+# Add a new buildpack
A new buildpack is needed when a new language or a new package manager should be
-supported. Existing buildpacks are a good model for how new buildpacks
-should be structured.
+supported. [Existing buildpacks](https://github.com/jupyter/repo2docker/tree/master/repo2docker/buildpacks)
+are a good model for how new buildpacks should be structured.
+See [the Buildpacks page](buildpacks) for more information about the
+structure of a buildpack.
## Criteria to balance and consider
@@ -17,7 +19,7 @@ Criteria to balance are:
this using one of the escape hatches in (2), so let us make it easy and add
native support".
-## Adding libraries or UI to existing buildpacks
+### Adding libraries or UI to existing buildpacks
Note that this doesn't apply to adding additional libraries / UI to existing
buildpacks. For example, if we had an R buildpack and it supported IRKernel,

ADD
docs/source/contributing/contentprovider.rst
+==========================
+Add a new content provider
+==========================
+
+Adding a new content provider allows repo2docker to grab repositories from new
+locations on the internet. To do so, you should take the following steps:
+
+#. Sub-class the `ContentProvider class <https://github.com/jupyter/repo2docker/blob/master/repo2docker/contentproviders/base.py#L17>`_.
+ This will give you a skeleton class you can modify to support your new
+ content provider.
+#. Implement a **detect()** method for the class. This takes an input
+ string (e.g., a URL or path) and determines if it points to this particular
+ content provider. It should return a dictionary (called
+ ``spec`` that will be passed to the ``fetch()`` method. `For example, see the ZenodoProvider detect method <https://github.com/jupyter/repo2docker/pull/693/files#diff-a96fcf624176b06e21c3ef7f6f6a425bR31>`_.
+#. Implement a **fetch()** method for the class. This takes the dictionary ``spec`` as input, and
+ ensures the repository exists on disk (e.g., by downloading it) and
+ returns a path to it.
+ `For example, see the ZenodoProvider fetch method <https://github.com/jupyter/repo2docker/pull/693/files#diff-a96fcf624176b06e21c3ef7f6f6a425bR57>`_.

MODIFY
docs/source/contributing/contributing.md
docs/source/contributing/contributing.md
-# Contributing to repo2docker development
+# Contributing to repo2docker
Thank you for thinking about contributing to repo2docker!
This is an open source project that is developed and maintained entirely by volunteers.

MODIFY
docs/source/contributing/index.rst
docs/source/contributing/index.rst
@@ -15,3 +15,4 @@ repo2docker package.
../design
tasks
buildpack
+ contentprovider

MODIFY
docs/source/contributing/roadmap.md
docs/source/contributing/roadmap.md
-# The repo2docker roadmap
+# Roadmap
This roadmap collects "next steps" for repo2docker. It is about creating a
shared understanding of the project's vision and direction amongst

adding instructions for contentprovider extension