rapidsai · rapids-bot · Sep 8, 2022 · Aug 2, 2022 · Aug 2, 2022 · Aug 3, 2022
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,53 +1,3 @@
 # Contributing to cuSpatial
 
-If you are interested in contributing to cuSpatial, your contributions will fall
-into three categories:
-1. You want to report a bug, feature request, or documentation issue
-    - File an [issue](https://github.com/rapidsai/cuspatial/issues/new/choose)
-    describing what you encountered or what you want to see changed.
-    - The RAPIDS team will evaluate the issues and triage them, scheduling
-    them for a release. If you believe the issue needs priority attention
-    comment on the issue to notify the team.
-2. You want to propose a new Feature and implement it
-    - Post about your intended feature, and we shall discuss the design and
-    implementation.
-    - Once we agree that the plan looks good, go ahead and implement it, using
-    the [code contributions](#code-contributions) guide below.
-3. You want to implement a feature or bug-fix for an outstanding issue
-    - Follow the [code contributions](#code-contributions) guide below.
-    - If you need more context on a particular issue, please ask and we shall
-    provide.
-
-## Code contributions
-
-### Your first issue
-
-1. Read the project's [README.md](https://github.com/rapidsai/cuspatial/blob/main/README.md)
-    to learn how to setup the development environment
-2. Find an issue to work on. The best way is to look for the [good first issue](https://github.com/rapidsai/cuspatial/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
-    or [help wanted](https://github.com/rapidsai/cuspatial/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) labels
-3. Comment on the issue saying you are going to work on it
-4. Code! Make sure to update unit tests!
-5. When done, [create your pull request](https://github.com/rapidsai/cuspatial/compare)
-6. Verify that CI passes all [status checks](https://help.github.com/articles/about-status-checks/). Fix if needed
-7. Wait for other developers to review your code and update code as needed
-8. Once reviewed and approved, a RAPIDS developer will merge your pull request
-
-Remember, if you are unsure about anything, don't hesitate to comment on issues
-and ask for clarifications!
-
-### Seasoned developers
-
-Once you have gotten your feet wet and are more comfortable with the code, you
-can look at the prioritized issues of our next release in our [project boards](https://github.com/rapidsai/cuspatial/projects).
-
-> **Pro Tip:** Always look at the release board with the highest number for
-issues to work on. This is where RAPIDS developers also focus their efforts.
-
-Look at the unassigned issues, and find an issue you are comfortable with
-contributing to. Start with _Step 3_ from above, commenting on the issue to let
-others know you are working on it. If you have any questions related to the
-implementation of the issue, ask them in the issue instead of the PR.
-
-## Attribution
-Portions adopted from https://github.com/pytorch/pytorch/blob/master/CONTRIBUTING.md
+See [cuspatial contributing guide](https://docs.rapids.ai/api/cuspatial/nightly/developer_guide/contributing_guide.html)
diff --git a/docs/source/api_docs/index.rst b/docs/source/api_docs/index.rst
@@ -1,13 +1,12 @@
 =============
-API reference
+API Reference
 =============
 
 This page provides a list of all publicly accessible modules, methods and classes through
 ``cuspatial.*`` namespace.
 
 .. toctree::
     :maxdepth: 2
-    :caption: API Documentation
 
     spatial
     trajectory

diff --git a/docs/source/developer_guide/contributing_guide.md b/docs/source/developer_guide/contributing_guide.md
@@ -0,0 +1,98 @@
+# How to Contribute to cuSpatial
+
+`cuSpatial` is a part of the RAPIDS community. When contributing to cuSpatial, developers should
+follow the RAPIDS contribution guidelines. The RAPIDS documentation
+[contributing section](https://docs.rapids.ai/contributing) walks through the process of identifying
+an issue, submitting and merging a PR.
+
+## Directory structure and file naming
+
+The `cuspatial` package comprises several subpackages.
+
+- `core` contains the main components of cuspatial
+- `io` contains I/O functions for reading and writing external data objects
+- `tests` contains unit tests for cuspatial
+- `utils` contains utility functions
+- `_lib` contains Cython APIs that wrap the C++ `libcuspatial` backend.
+
+[`library_design`](library_design.md) further discusses high-level library design of `cuspatial`.
+
+### Cython code
+
+The `_lib` folder contains all cython code. Each feature in `libcuspatial` exposed to
+`cuspatial` should have two Cython files:
+
+1. A `pxd` file declaring C++ APIs so that they may be used in Cython, and
+2. A `pyx` file containing Cython functions that wrap those C++ APIs so that they can be called from Python.
+
+`pyx` files are organized under the root of `_lib`. `pxd` files are under `_lib/cpp`.
+`pxd` files should mirror the file hierarchy of `cpp/include` in `libcuspatial`.
+
+For more information see [the Cython layer design documentation](./library_design.md#cython-layer).
+
+## Code style
+
+cuSpatial employs a number of linters to ensure consistent style across the code base, and manages
+them using [`pre-commit`](https://pre-commit.com/). Developers are strongly recommended to set up
+`pre-commit` prior to any development. The `.pre-commit-config.yaml` file at the root of the repo is
+the primary source of truth for linting.
+
+To install pre-commit, install via conda/pip:
+
+```bash
+# conda
+conda install -c conda-forge pre-commit
+```
+```bash
+# pip
+pip install pre-commit
+```
+
+Then run pre-commit hooks before committing code:
+```bash
+pre-commit run
+```
+
+Optionally, you may set up the pre-commit hooks to run automatically when you make a git commit. This can be done by running the following command in cuspatial repository:
+
+```bash
+pre-commit install
+```
+
+Now code linters and formatters will be run each time you commit changes.
+
+You can skip these checks with `git commit --no-verify` or with the short version `git commit -n`.
+
+### Linter Details
+
+Specifically, cuSpatial uses the following tools:
+
+- [`flake8`](https://github.com/pycqa/flake8) checks for general code formatting compliance. 
+- [`black`](https://github.com/psf/black) is an automatic code formatter.
+- [`isort`](https://pycqa.github.io/isort/) ensures imports are sorted consistently.
+
+Linter config data is stored in a number of files. cuSpatial generally uses `pyproject.toml` over
+`setup.cfg` and avoids project-specific files (e.g. `setup.cfg` > `python/cudf/setup.cfg`). However,
+differences between tools and the different packages in the repo result in the following caveats:
+
+- `flake8` has no plans to support `pyproject.toml`, so it must live in `setup.cfg`.
+- `isort` must be configured per project to set which project is the "first party" project.
+
+Additionally, cuSpatial's use of `versioneer` means that each project must have a `setup.cfg`.
+As a result, cuSpatial currently maintains both root and project-level `pyproject.toml` and
+`setup.cfg` files.
+
+## Writing tests
+
+Every new feature contributed to cuspatial should include unit tests. The unit test file should be
+added to the `tests` folder. In general, the `tests` folder mirrors the folder hierarchy of the
+`cuspatial` package. At the lowest level, each module expands into a folder that contains specific
+test files for features in the module.
+
+cuSpatial uses [`pytest`](https://docs.pytest.org/) as the unit testing framework. `conftest.py`
+contains useful fixtures that can be shared across different test functions. Reusing these fixtures
+reduces redundancy in test code.
+
+cuspatial compute APIs should strive to reach result parity with its host (CPU) equivalent. For 
+`GeoSeries` and `GeoDataFrame` features, unit tests should compare results with
+corresponding `geopandas` functions.
diff --git a/docs/source/developer_guide/development_environment.md b/docs/source/developer_guide/development_environment.md
@@ -0,0 +1,16 @@
+# Creating a Development Environment
+
+cuSpatial follows the RAPIDS release schedule, so developers are encouraged to develop 
+using the latest development branch of RAPIDS libraries that cuspatial depends on. Other
+cuspatial dependencies can be found in `conda/environments/`.
+
+Maintaining a local development environment can be an arduous task, especially after each
+RAPIDS release. Most cuspatial developers today use
+[rapids-compose](https://github.com/trxcllnt/rapids-compose) to setup their development environment.
+It contains helpful scripts to build a RAPIDS development container image with the required
+dependencies and RAPIDS libraries automatically fetched and correctly versioned. It also provides
+script commands for simple building and testing of all RAPIDS libraries, including cuSpatial.
+`rapids-compose` is the recommended way to set up your environment to develop for cuspatial.
+
+For developers who would like to build from conda or from source, see
+[README.md](https://github.com/rapidsai/cuspatial/blob/main/README.md).
diff --git a/docs/source/developer_guide/index.md b/docs/source/developer_guide/index.md
@@ -3,4 +3,6 @@
 ```{toctree}
 :maxdepth: 2
 
-internals
+development_environment
+contributing_guide
+library_design
diff --git a/docs/source/developer_guide/internals.md b/docs/source/developer_guide/internals.md