earthengine-community: user written tutorials for Earth Engine

A content collection, not a code dependency

The repository description is precise about what this is: tutorials and content created by Earth Engine users, for Earth Engine users.

The README says the same thing in the first line of its body. This repository contains content submitted and or maintained by the Earth Engine developer community.

That single distinction explains almost everything about the project, and it is worth holding onto before looking at any individual directory. This is not a Python package, there is no pip install, no versioned release and no API to call. The primary language is recorded as Jupyter Notebook, which is the format the content takes rather than a statement about a distributed library.

What the repository is for is publication. A user writes a tutorial in a notebook, adds it to the tutorials directory, and the file appears in the community tutorials section of the Earth Engine Developer's Guide. The Developer's Guide is the documentation surface where Earth Engine users learn, and this repository is how the community feeds that surface.

So the audience is two groups at once. The first is the Earth Engine user who has a technique worth sharing and wants it indexed, reviewed and findable. The second is the Earth Engine user who searches the guide for a method and lands on a tutorial written by someone who had the same problem.

The licence is Apache 2.0, the default branch is master, the homepage is earthengine.google.com, and the last push to the repository was on 2026-10-20, with no GitHub releases, which is the expected shape for a repository whose unit of delivery is a document rather than an artefact.

Adding a file to tutorials/ is the entire publishing process

The publishing mechanism is described in two sentences, and it is worth noting how little machinery sits behind it.

Files added to the tutorials directory will appear under the community tutorials section of the Earth Engine Developer's Guide.

There is no build step described, no index file to update, no registration call. The path is the contract. Put a notebook in the right folder and it becomes part of the published documentation.

That simplicity is a deliberate choice with a real consequence. It removes the barrier to contributing, because there is no registration process to learn, and it puts the burden of consistency on the review step instead of on tooling. The README's Community Tutorials section links to three entry points that make this explicit: browse tutorials, request a tutorial, and submit a tutorial. The request link opens an issue form with a title prefix for tutorial requests and a body that asks for a description, a technical level and a length, while the submit link goes to the Developer's Guide page for writing one.

The separate request path is the interesting part of the workflow. A user can ask for a tutorial on a subject that does not exist yet, which is a way of saying that the gap is known and the content is wanted. Whether the guide then solicits a specific author, the README does not say.

The other visible community machinery is small but conventional. There is a CONTRIBUTING.md that the contributing link points to, an AUTHORS file, and a contributors link that goes to the GitHub contributors graph. The README asks people to join the team of Earth Engine Community contributors, which is the sentence that turns a folder of notebooks into a project with a community around it.

The request template encodes the editorial contract

The issue template for tutorial requests is the most revealing artefact in the repository, because it tells you exactly what the editors want.

The form asks for a description, then a technical level with three options, beginner, intermediate or advanced, and then a length with three options, short of under 250 words, medium of 250 to 500 words, and long of 1000 words or more.

Those two axes shape every tutorial in the collection, and they are worth understanding separately.

The technical level is an editorial decision with a practical meaning. A beginner tutorial is expected to assume no prior Earth Engine knowledge and to be self contained, while an advanced one is allowed to assume the reader already works in the Code Editor and to skip the fundamentals. That is a larger difference than it looks, because most of the length of a beginner Earth Engine tutorial is setup.

The length options are unusually specific for a community project. The short band, under 250 words, is for a single method or a single function, the medium band of 250 to 500 words is for a focused workflow, and the long band of 1000 words or more is for a full analysis. The three bands are separated by a wide gap between the upper end of medium and the lower end of long, which means a tutorial that does not fit the middle band has to be a short one or a substantial one, and that is a deliberate signal.

For a contributor, the practical advice is to read those three fields before writing anything, and to pick a band and stay inside it.

Six directories that separate stable content from experiments

The top level listing shows a repository organised by kind of content rather than by a single flat set of tutorials.

There are tutorials, guides, samples, skills, datasets and experimental directories, alongside examples, and the presence of experimental as a named category is the most informative thing here. It is a signal that the project distinguishes work that is ready to be read by others from work that is not, and it gives contributors somewhere to put a half finished idea that would otherwise clutter the tutorial collection or sit in a pull request forever.

The datasets directory is the other one worth noticing, because it changes what a tutorial can be. A notebook that loads a published dataset is reproducible in a way that a notebook pointing at a local file or a bucket URL is not, and a shared dataset directory is the mechanism by which a community can make that true without each author shipping large files.

The skills directory is newer looking than the others and the README does not explain it, so what it holds and how it differs from samples is a question for the contributing guide rather than something to guess at from the file listing.

The examples directory has its own README and two subdirectories, adk_agents and google-cloud-next-2025, which tells you the shape of it. Those are event resources rather than a library of reusable snippets, tied to a specific conference session and to agent work, and the fact that they sit in a separate top level directory rather than in samples says the project treats them as a different genre of artefact.

Two licences, and the split is not explained in the README

The licence handling is where this repository is least documented, and it is a fair thing to flag for anyone who plans to reuse the content.

The repository is licensed under the Apache License, Version 2.0, and the LICENSE.md file at the root carries the standard notice with copyright 2019 The Google Earth Engine Community Authors.

At the same time, the README's list of link definitions includes a reference to the Creative Commons Attribution 4.0 licence alongside the Apache 2.0 one. That pairing, in a repository whose unit of content is a tutorial written by a third party, is the usual arrangement for a project where the scaffolding and the contributed content are licensed differently, with the Apache licence covering the repository structure and the Creative Commons attribution licence covering the tutorials themselves.

That is a reasonable reading, but the README does not state it, and the difference matters if you plan to reuse a tutorial, adapt it into your own documentation, or reuse a dataset. Under an attribution licence you must credit the author and the licence; under Apache 2.0 you also inherit patent and trademark grants. Those are different obligations, and the difference is worth ten minutes of reading before you copy anything.

The AUTHORS file at the repository root is the place to look for who wrote what, which is also the natural starting point if you want to credit an individual tutorial correctly.

A Travis badge from the early days, and a repository that still changes daily

The build status in the README points at Travis CI, on travis-ci.org, for the master branch. That is a detail from an earlier era of the ecosystem, and it raises a fair question about what, if anything, the continuous integration here does today.

The repository does contain a .travis directory, so the configuration is still in the tree. But a content repository has an unusual build, since most of what is added is a notebook with images and text, and the useful check is whether the notebook runs and whether its assets are present, not whether a library compiles. The README does not describe a test suite, a style check, or a validation step for submitted tutorials, so what the pipeline enforces is not something this document answers.

What the file listing does show is a .github directory, which in a GitHub hosted project usually means workflow definitions, issue templates and the like, and an .eslintignore file, which hints at a JavaScript linting setup somewhere in the tree, plausibly for the notebooks that carry JavaScript.

Against that, the commit cadence is clearly active. The last push to the repository was on 2026-10-20, which is the same day as this writing, and the directory layout with skills and experimental directories suggests the collection is still being reorganised as it grows.

The version story is the simplest part. There are no GitHub releases, and a repository of tutorials does not need them, since a notebook is versioned by its own commits and the guide always serves the current state of master. If you want to cite a specific tutorial, the commit hash is the identifier you want, and the AUTHORS file is the attribution you need.

Editorial conclusion

earthengine-community suits an Earth Engine user who has solved a real problem and wants the solution documented where other users will find it, since adding a file under tutorials/ is what puts a piece in front of the Developer's Guide audience, and the request template tells you the length and technical level the editor expects. It does not suit a team looking for a versioned library with releases and semantic versioning, because this is a content collection with no published releases and a default branch of master. Before you submit, read CONTRIBUTING.md, match the requested length and level, and check the licensing split, since the repository itself is Apache 2.0 while the content it hosts is credited under a Creative Commons attribution licence, and remember that the last push to the repository was on 2026-10-20 with the work still flowing through a Travis badge from an earlier era.

Frequently asked questions

Official sources

1. google/earthengine-community on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README