notebooks-contrib is a community shelf where the RAPIDS team stops maintaining

Four folders decide how much support a notebook has

The repository is organised so that the directory a notebook lives in tells you its maintenance status, which is unusual and useful. The getting started folder holds the how-to-start notebooks, with hello world examples, tutorials around RAPIDS concepts, and an intro covering cuDF, Dask, cuML and XGBoost. `community_tutorials_and_guides` holds the workflow examples, algorithm demonstrations, benchmarking tools and some complete end-to-end workflows. `community_archive` is where notebooks with known issues that have not been fixed for 45 days or more end up, and it also holds the shared notebooks referenced in blog posts that demonstrate RAPIDS workflows. `the_archive` is the older layer, containing notebooks from community members and ones the RAPIDS team no longer updates, including archived blog notebooks, archived event notebooks and competition notebooks. A `data` directory holds the small samples used for functional demonstrations, and the documentation notes that some notebooks include cells which download larger datasets from external sites. If you are choosing where to look, the folder is the cheapest signal available.

Community notebooks are explicitly not maintained by the RAPIDS team

The naming of the collection is the point, and the documentation is unusually direct about it. These notebooks are for the community, which means two things. Anyone can contribute workflow examples, tips and tricks or tutorials, with the request that they follow the testing and pull request process. And there are community responsibilities, stated because the RAPIDS team is not maintaining these notebooks. If you write a notebook, the ask is that you try to keep it maintained, and you will be mentioned on the issue. If you find an issue, the ask is not to file it but to attempt the fix. And a notebook with a problem, or whose last tested RAPIDS release version is in legacy, may be removed to the archives. That is a different contract from an official documentation set. Here the author of a broken notebook is the person expected to fix it, which is a fair model for contributed work and a poor model for anything you intend to depend on in production.

The RAPIDS team notebooks and the event notebooks carry different terms

Three tiers of notebook exist with three different maintenance promises, and the distinction matters when you are reading one. The team-built notebooks are built by the RAPIDS team and are maintained by them, and the documentation adds the detail that when the team removes a notebook it becomes community maintained until it reaches the archive. The RAPIDS event notebooks are the ones presented at conferences or meetups, and they live in a separate repository at rapidsai-community/event-notebooks. The event collection has two explicit caveats. It is frozen in time and not maintained as RAPIDS progresses, so you should download the RAPIDS version those workflows were built against or expect to update them yourself. And while the aim is to use open source or easily accessible data, some notebooks may require datasets with restricted access. The practical rule is simple: check which tier a notebook belongs to before you spend an afternoon adapting it, because a team-maintained notebook may be updated under you and an event notebook will not be.

Building the container means an old CUDA base image and a renamed path

There is a Dockerfile at the repository root and a Makefile that wraps it, and both are short enough to read in full. The container starts from `rapidsai/rapidsai:cuda9.2-runtime-ubuntu16.04` and installs a set of conda packages on top, including matplotlib, scikit-learn, seaborn, python-louvain and jinja2, then graphistry and mockito through pip. A second conda install pulls cugraph from a mix of channels including nvidia/label/cuda10.0 and rapidsai/label/cuda10.0. The image also installs graphviz through apt and pip, and kaggle, with a comment that asks for a ToDo about letting a user supply kaggle credentials. The data folder is moved to /data and symlinked back so it can be browsed inside JupyterLab, and the entry point starts Jupyter through a script in the image. The working directory and the whole layout still refer to the older name of the collection, notebooks/extended, which is a reminder of how the project was renamed.

The Makefile is two targets, and the ports tell you what runs

The whole build is a Docker build followed by a container run, and the published ports reveal what the image serves. The build target tags the image as notebooks-contrib, and the run target starts it interactively with three published ports: 8888, which is the Jupyter port, and 8787 and 8786, which the RAPIDS image uses for other services. The rest of the repository's machinery sits in three files that the README points to. CONTRIBUTING.md holds the guide for contributing to notebooks-contrib, TESTING.md holds the instructions for testing a notebook before opening a pull request, and SECURITY.md and THIRD_PARTY_LICENSES.md sit alongside the Apache-2.0 LICENSE. The working tree also has a `utils/` directory, a `.dockerignore` and a BUILD.md, plus a `conference_notebooks/` directory at the top level. The contribution workflow the documentation asks for is therefore: follow CONTRIBUTING.md, then test the notebook per TESTING.md, then open the pull request.

The two Docker commands are the whole workflow, and they are quoted from the Makefile in the repository:

	docker build -t notebooks-contrib .
	docker run -it -p 8888:8888 -p 8787:8787 -p 8786:8786 notebooks-contrib:latest

The Makefile invokes exactly these two with a tab-indented recipe, and the first target runs both in sequence. The image itself is assembled from a base that already contains RAPIDS:

FROM rapidsai/rapidsai:cuda9.2-runtime-ubuntu16.04

and it ends by starting Jupyter from a script that lives in the image rather than in this repository:

CMD source activate rapids && sh /rapids/notebooks/utils/start-jupyter.sh

A reader following this path should expect the container to expose the notebook interface on port 8888, and should be aware that the base image is old enough that the RAPIDS version inside it is not the current one.

A curated link list is a real part of what this repository offers

The README carries a long topic-indexed link list, and it is worth reading as a resource in its own right rather than as decoration. Under RAPIDS libraries basics there are teaching notebooks and user guides, a crash course, an intro set covering cuDF, Dask, cuML and XGBoost, a link to the official user guides, a ten minute tour of cuDF and Dask cuDF, and a set of hello world notebooks with direct links to individual .ipynb files such as the Dask hello world. A second block collects official cheat sheets as PDF downloads for cuDF, BlazingSQL, cuGraph, RAPIDS-Dask, CLX and cyBert, and cuSignal. A deploying section links the official deployment guide plus walkthroughs for AWS Sagemaker, AzureML, Google Cloud with Dask Cloud Provider, IBM Virtual Server Instance and IBM Kubernetes Service. A multi-GPU section links a Dask hello world, an introduction to Dask, a Dask using cuDF notebook, and further RAPIDS resources. For a newcomer, this index answers the question of where to start faster than any single notebook does.

Why a notebook in this repository is not something to build on

The archive policy is the honest limitation. A notebook that has known issues and has not been fixed for 45 days or more goes to `community_archive`, and the rule about the last tested RAPIDS release version being in legacy means that a notebook tied to an old release can be moved out from under you without any code change on your side. A community notebook whose author has moved on is not necessarily broken, but nobody is contractually obliged to maintain it, and the documentation says so. There is a second cost specific to this collection: because the base image is pinned to a CUDA 9.2 runtime on Ubuntu 16.04, the container is a fixed environment rather than a current one, so reproducing a notebook means using the RAPIDS version it was written against rather than a recent one. The event-notebook warning applies here too, with frozen-in-time workflows and the possibility of restricted datasets. The honest summary is that this repository is excellent for learning the shape of a RAPIDS workflow and for publishing one, and unreliable as a dependency.

Editorial conclusion

notebooks-contrib is a good place to find a working RAPIDS example quickly or to publish a workflow of your own, since the contribution process is documented in CONTRIBUTING.md and testing in TESTING.md, and since a submitted notebook that is good enough can be featured. It is a poor home for a production workflow, because the repository's own policy is that a notebook with known problems that has not been fixed for 45 days or more moves to `community_archive`, and a notebook the RAPIDS team stops updating becomes community maintained. Before relying on any notebook here, check which RAPIDS release it was last tested against and whether its folder is `community_archive` or `the_archive`, and if you intend to contribute, read TESTING.md and run the notebook yourself rather than assuming the team maintains it, because the last push to the repository was on 2026-07-10 and the collection is explicitly not maintained by the RAPIDS team.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. rapidsai-community/notebooks-contrib on GitHub
4. README