Welcome curators! This guide describes some of the curatorial tools iNat provides as well as some of iNaturalist's policies toward how we curate our taxa.

This document is both a how-to manual and a statement of our curatorial policies. If you cannot abide by our policies, we will start by warning you, but if you continue to reject our policies, we will remove your curator status.

Becoming an iNaturalist Curator

Being a site curator means you have the power to make new taxa, edit existing taxa, alter our taxonomic tree, delete taxon names, and generally maintain the state of iNat's taxonomy. You also have the ability to hide other users' comments and suspend them for violations of iNaturalist's Community Guidelines. You will not have the ability to remove or override anyone's identification, however.

If you are interested in getting the tools to help with some of the tasks outlined below, read through this Curator Guide in full then fill out the Curator Application here. In order to apply to be a site curator you must have had an account for 60 days or more, have added 100 improving identifications to anyone's observations, including your own, and made at least five flags.

Note that as of January 20th, 2021, curators can no longer promote another user to curatorship. Only iNaturalist staff and iNaturalist Network Site Admins can make someone a curator.

If you demonstrate by your behavior on the site, forum, or other communication that you are unwilling to abide by these curatorial policies, abusive to us or members of our community, or otherwise unreasonable, the staff will revoke your curator status, or just not grant it in the first place. What constitutes abusive or unreasonable behavior is at the discretion of the site staff.

Have a question or not sure how to respond to a specific situation? Always feel free to flag something for curation to have a discussion with other curators, or to reach out to the staff at [email protected].

Adding / Editing Taxa

Everyone on iNat can add new taxa to the system by searching external name providers using the taxon selector or by using the box at the bottom of the search page. Curators can make new taxa directly by going to https://www.inaturalist.org/taxa/new or by clicking the "Create a new taxon link" in the Curation box on their dashboard.

The taxon form looks like this:

Most of the fields include some explanatory text, but here are some extra explanations:

Name

Each Taxon record has a name, but it also has many Taxon Name records that include its scientific names (current and outdated) and vernacular names. The name field for the Taxon record should be the accepted scientific name for this taxon.

You Probably Don't Want to Change the Scientific Name on the Taxonomy Tab

Do not change the scientific name of a taxon if you're trying to make a taxonomic change, e.g. replacing an outdated name with a new one. The appropriate way to do this is to use Taxon Changes. Just changing the name of a taxon on the Taxonomy tab will not preserve the history of the change, will not update the name elsewhere, and will not notify people about the name change.

Rank

Taxonomic rank, e.g. species, genus, family, etc.

Parent ID

ID of the parent taxon. This is how you place a taxon in our taxonomic classification. You can use the Parent Name species chooser to select the parent like you would with any other species chooser on the site, but it's the ID that gets saved, so if you want to just paste in an ID you can do that.

And of course there are caveats. For one thing, curators can't edit taxa above the order level. Changes toward the root of the tree create a ton of backend work that impacts site performance, so we stopped allowing it in July 2016. Also, these parts of the tree are pretty stable, so there's not much need to alter them. If you think these kinds of changes are needed, contact [email protected].

Editing Taxon Geoprivacy Settings

Taxon geoprivacy is an automatic setting applied to species that may be threatened by collection/harvesting or otherwise disturbed due to the public's knowledge of its location. If a species is only threatened by development or climate change, not automatically obscuring them may be advised. Out of an abundance of caution, iNaturalist initially obscured the locations of all species with an IUCN equivalent status of "Near Threatened" or worse. Over time, many of these taxon geoprivacy statuses have been updated from "obscured" to "open" when advisable. In situations where a species is thought to be in little danger from the public's knowledge of its location, curators are encouraged to open a flag for discussion regarding the taxon geoprivacy, and setting (or changing) the geoprivacy status to "open" may be recommended.

Examples might be coast redwood (Sequoia sempervirens) which is listed as Vulnerable by IUCN because it is endangered by climate change but in very little danger of being collected or otherwise exploited by the public knowing the exact location of redwood observations. Likewise, green ash trees (Fraxinus pennsylvanica) are critically endangered in North America from the invasive Emerald Ash Borer, but not from harvest or disturbance, so obscuring the locations offers no protection from its greatest threat and may limit the ability to find and protect any resistant individuals.

Obviously, this is a gray area so if you feel compelled to un-obscure a threatened species be prepared to support why you are doing this and leave a record of the reasoning and conversation in a taxon flag. Why is the species not likely to be exploited by the public?, why is it of value to have the exact location accessible to the public?, etc.

In Canada

In Canada, where iNaturalist has a member of the iNaturalist Network that oversees iNaturalist.ca, there is a Steering Committee which defines the “taxon geoprivacy” for all species in Canada. This is based on conservation status ranks maintained by subnational Conservation Data Centres as well as status reports from the Committee on the Status of Endangered Wildlife in Canada (COSEWIC), expert review and community feedback.

For more information, please visit the Geoprivacy page at iNaturalist Canada

Curators are asked to not make any changes to taxon geoprivacy within Canada. If any user (including curators) would like to request changes to the taxon geoprivacy for any national, provincial, or territorial unit of Canada, first check the detailed Obscured Species List then fill out the Obscuration Request Form. Discussions between the iNaturalist.ca Steering Committee, experts and the requester should lead to an agreement that is favorable to all parties and biodiversity conservation. Curators must ultimately follow the recommendation from the iNaturalist.ca Steering Committee. Other aspects of conservation statuses aside from taxon geoprivacy may be freely added or updated by curators, such as the NatureServe status, URLs, or descriptions.

In summary, the process should be:

1. Check the Obscured Species LIst.
2. Flag the taxon for curation.
3. Fill out the Obscuration Request Form.
4. iNaturalist.ca corresponds with requester on the taxon flag whenever possible so there is a public record of deliberation. Exceptions to the public discussion should be made when the discussion itself requires mentioning sensitive locations.
5. The iNaturalist Steering Committee makes changes to taxon geoprivacy and resolves flag, or resolves flag without changing taxon geoprivacy if no change is supported.
6. The iNaturalist.ca Steering Committee updates the Obscured Species List.

Changes made by curators to taxon geoprivacy without submitting the request using the Google Request Form or in disagreement with the decision of the iNaturalist Canada Steering Committee will be overridden by the Obscured Species List during periodic reviews.

Adding / Editing Names

Each taxon has one name (the scientific name), as well as multiple Taxon Name records. Taxon Name records are used to store all the names associated with a taxon, including current and outdated scientific names and vernacular names in multiple languages. Each name must be unique for a given taxon and lexicon.

On the taxon page, Taxonomy tab, you'll see a list of all names at the bottom of the page. Any iNat user can add common names using the "Add a name" link in the bottom right corner, but only curators can edit scientific names or delete names added by other people.

Default Name

The language and Place preferences in your account settings will change how common names are displayed on the site. We support one default common name globally, which can be changed by at the "Manage Names" page (taxon page, taxonomy tab) by dragging a name to the top of the list. You can also specify default names for specific places by editing the name and assigning it to a place, but only do this when different places have conflicting names. Be judicious when changing the default common name. Recognize that you may be displacing the name used by many other users.

Capitalization

Common names for animals should be entered in title case with each word starting with a capital letter (e.g. Atlantic Bluefin Tuna) but not the second part of adjectival hyphenated words (e.g. Sulphur-crested Cockatoo).

Common names for plants, fungi, and other non-animal taxa should be entered in lowercase (e.g. spotted gum) except for proper nouns, which should start with a capital letter wherever they appear (e.g. Tasmanian blue gum).

NOTE: For reasons of style, iNaturalist often automatically displays common names in title case. However, common names should never be entered in sentence case (e.g. it would be entered as "mountain grey gum" not "Mountain grey gum").

Just the Name, Please

Don't add information to a name in addition to the name itself, e.g. "grumblefoots (this genus is monotypic, just ID to species!)." We use names in a lot of places for a lot of different reasons and adding extraneous information just makes them more confusing to users and more cumbersome to incorporate into designs (e.g. they might make it impossible to show a common name and a scientific name at the same time). If there is a real problem with misuse of a name, we would prefer to handle it in code and not in the name itself.

Good and Bad Common Names

Names, in general, should be as specific as possible, and common names are no exception. Most of us would agree that "mammal" would not be a good common name for the species Homo sapiens, so do not add names like "snail" for some obscure gastropod with no real common name just because you think it will make it easier for novices to find. If anything, it will make it harder to find, since there are thousands and thousands of "snails." Instead, try to add names at the taxonomic level where they describe all members of that taxon and only members of that taxon.

If a species has no common name in usage, do not make one up. For example, do not create a new common name based on its scientific name or based on a translation of a common name from another language.

Do not add common names for infraspecies that are identical to the common name of the parent species, e.g. if the species is Cola coke and it has the subspecies Cola coke ssp. classic and Cola coke ssp. zero, don't add the common name "Coke" for the subspecies. That will just confuse people who are trying to add an ID for the species Cola coke and make it harder for people who actually want to choose the subspecies. Instead, try to choose unique common names like "Coke Classic" and "Coke Zero."

This also applies to regionalized common names (i.e. common names associated with places). If the only kind of cola available in Ireland is Coke Zero, don't add the common name "Coke" to Cola coke ssp. zero and associate it with Ireland. That name is still visible to everyone viewing English names, so someone in South Africa searching for "coke" and hoping to find the species Cola coke will see Cola coke ssp. zero even though that's not what they want. The people of Ireland will still be choosing the right species when they search for "coke." The people in Ireland who want to take it to subspecies can just learn to use the subspecific name (or better yet the scientific name).

Note that there are a few uncommon situations where duplicate common names are ok, e.g. in situations where a species or subspecies really has a synonymous common name somewhere else.

For higher level taxa it can be hard to find a common name that describes all descendants. In these cases, for the global default name, we go with something like "Herons and Allies" or "heath family."

If you find names that don't meet these criteria, e.g. 10 taxa named "snail," delete them without mercy.

Changing iNat's Taxonomy (Taxon Changes)

What Taxon Changes Are

Taxon Changes represent changes to our taxonomic classification where existing "input" taxa get replaced by new "output" taxa. They come in a few flavors:

Taxon Swap (One-to-One)

Replace one taxon with another. Use this for simple name changes where the new name describes exactly the same group of organisms as the old name, e.g. assignment to a new genus, fixing a spelling problem, etc. You can also use this for resolving heterotypic synonyms. Set the junior synonym as the input taxon and the senior synonym as the output taxon.

Taxon Merge (Many-to-One)

Merges several "input" taxa into a single "output" taxon, e.g. when multiple names are lumped under a single name. Suitable for combining a lot of synonyms at once. You could use swaps for this too, but merges just helps consolidate the description and sourcing.

Taxon Split (One-to-Many)

Splits a single "input" taxon into several "output" taxa, e.g. when a species has been revised and determined to contain several distinct, named species.

Taxon Drop

Deactivates a taxon. You could also just edit the taxon and mark it as not active, but making a Taxon Drop allows you to explain and cite your sources. That said, just deactivating a taxon, whether with a drop or through direct editing, is almost never appropriate. You can almost always map a name to some other name. Drops are not a way to just get rid of names you don't like for some reason.

Taxon Stage

Stages a new, inactive taxon for activation. Sometimes we (the iNat team) make sweeping semi-automated changes based on a taxonomic authority, and stages allow us to release a bunch of new names at once. Again, like drops, they are almost never really necessary.

Creating Taxon Changes

You should create a Taxon Change any time you want to change the existing taxonomy, e.g. renaming a taxon or marking it as an outdated synonym of another taxon (Taxon Swaps). You can do this by clicking the "New taxon change" button on the upper right of https://www.inaturalist.org/taxon_changes, or just going directly to https://www.inaturalist.org/taxon_changes/new.

The single / multiple taxon boxes are a bit confusing. Every change has input and output taxa, so if you were replacing Hyla regilla with Pseudacris regilla, Hyla regilla would be the input and Pseudacris regilla would be the output. For Taxon Splits, there is one input and multiple output taxa, so the input goes in the "Single taxon" box on the left and the outputs go in "Multiple taxa" on the right. For Taxon Merges it's the other way around: multiple inputs, one output, so the output goes on the left and the inputs on the right.

iNaturalist taxa represent taxonomic concepts, meaning taxa can represent different things even if they have the same name. So they should have distinct taxon IDs and distinct taxon pages. For example, this taxonomic change split Rhipidura fuliginosa into Rhipidura albiscapa and Rhipidura fuliginosa, but the older, broader concept of Rhipidura fuliginosa has a different taxon id (8161) than the newer, narrower concept with the same name (244276). So when making a taxonomic split or merge, make sure you first make a new taxon if necessary. If the new taxon bears the same name as an existing taxon, you will need to mark the existing one as "inactive" before the system will let you create the new one.

When you save the Taxon Change it is in an "uncommitted" or "draft" state. You can review what observations will be affected by your change on the taxon change page (e.g. https://www.inaturalist.org/taxon_changes/31) and update your own content at the "commit for user page" (e.g. https://www.inaturalist.org/taxon_changes/31/commit_for_user). If you're unsure about your change, you can solicit feedback through comments on the taxon change or on a flag.

Note that Taxon Changes represent changes within iNaturalist's taxonomy. While this should approximately mirror the direction of changes implied by the authorities we follow, they don't have to. For example, if Authority A says Vulpes vulpes is accepted, but there's a new paper that says we should call the species Supervulpes vulpes and somehow Supervulpes vulpes got added to our taxonomy, it would be ok to make a swap from Supervulpes vulpes to Vulpes vulpes, because Authority A says that's the current name. If a taxon change is likely to be controversial, starting a discussion before rather than after the change is prudent.

Committing Taxon Changes

When you commit a taxon change, a bunch of things are going to happen:

1. All of the input taxa will be deactivated

2. All of the output taxa will be activated

3. All observers and identifiers who have used the input taxa will be receive a dashboard notification about this change

4. Associated records get updated (maybe)

   This is where things get tricky. In theory, when a change only has one output, as with a swap or a merge, updating records is easy: replace uses of the input taxa with the output taxon. Except... some people want full control over their records and have opted out of these automatic changes. Plus we don't want to just change identifications in place because then we lose the history of what people really meant when they added an ID using an older taxon concept. And worst of all, splits have multiple output taxa, so we can't always choose what new taxon to assign to any given record.

   So here's what happens:

   • Swaps: Identifications of the input taxon get marked as not current and new identifications of the output taxon are added, unless the identifier has opted out. Observations get updated because of these identification changes. Listed Taxa get changed in place to use the output taxon. Copies of the photos, conservation statuses, ranges, atlases, and names associated with the input get moved to the output. Children of the input get moved to the output, unless the input and output have the same rank and that rank is genus or lower. The latter case means the children need new names (e.g. if genus Foo gets replaced with genus Zoo, species Foo bar needs to become Zoo bar). In this case, instead of moving the children, new swaps are automatically created for the new names.

   • Merges: Just like swaps except conservation statuses, ranges, and atlases don't get moved to the output, since it's not always clear if those are still relevant to the new concept.

   • Splits: Most content just gets left with the input taxon. For identifications and listed taxa, records by people who have opted out get ignored, and for everything else:

     • When all of the output taxa have atlases we can automatically choose the right output taxon for a record with a location, e.g. if Observation 1 is in Belgium and Output Taxon A occurs in Belgium but Output Taxon B does not, we can just add new identifications of Output Taxon A to Observation 1. However...

     • Where output atlases overlap, or if there's ambiguity due to output taxa without atlases, we fall back to adding identifications of the closest taxon that contains all of the output taxa, so if the input is Woofer and the outputs are Canis and Vulpes, all IDs of Woofer will be replaced with IDs of Canidae, b/c it contains all of the outputs and should be implied by all of the previous IDs. This is a little weird, we know, but it makes it easier for people to add new identifications to shift the community ID correctly.

     If it's not already obvious, splits are the most disruptive kind of change. In the worst case scenario where some or all of the outputs are not atlased, observations of the input are going to get associated with some higher-level taxon and will need more IDs to become associated with one of the new outputs. This is probably going to be quite common, so if you split a taxon, take responsibility for your change, review affected observations, and add new identifications where you can (there should be a banner on the taxon change page after you commit linking to a tool that will make this a bit easier).

Many of the consequences of taxon changes can be undone by site staff if you make a mistake (like the new identifications), but not all (like the listed taxa). That's why it's really important to be careful when committing a taxon change, particularly for taxa that a lot of people have been using.

Best Practices for Taxon Changes

Check and Follow the Authorities

See the Policies below. We try to follow external authorities for certain groups in certain places. Do not make changes that conflict with these authorities without discussion about a potential deviation from the authority.

Explain the Change

Name changes are really frustrating, so if you can, explain why this name was changed. For splits, help people out by explaining how to differentiate between the output taxa so people know how to update their content if it couldn't be updated automatically. These practices are good for record-keeping, but they can also reduce the frustration and help everyone learn.

Cite Your Sources

We would like every change to be traced back to some publication or taxonomic authority. In the case of using primary literature as a source (for taxa where iNaturalist does not follow an external taxonomic authority), the ideal citation would be to the paper that introduced the change, along with a URL to that paper, but since that's often difficult or impossible to find without extensive library research, sourcing the change to a website or database is okay too. Since it's a pain to add a new Source record for every single page, it's often easier to set the Source as the website and include a specific URL to the page on that website that describes the change on the description. The goal is to ensure that anyone who wants to figure out why a particular change was made can trace it back. Keep in mind that the Encyclopedia of Life, Catalogue of Life and Wikipedia (as well as its sister sites such as Wikidata and Wikispecies etc) are not among of our taxonomic authorities! If you must cite them, perhaps because one of our authorities doesn't include an older synonym, link directly to the relevant content, e.g. https://eol.org/pages/330496/names/synonyms.

Collaborate

Try to @ mention others to review your changes for potential errors and to discuss whether or not they're appropriate. This is especially important if you're changing a taxon based on a regional authority and it has observations outside that region. Curators have a lot of power to act unilaterally because sometimes it's just hard or impossible to get others to vet your work, but we (the site staff) would prefer a more collaborative process whenever possible.

Policies

Most of our classifications come from our external name providers, but for some groups we try to adhere to different taxonomic authorities. Note that this means when we are tracking a secondary taxonomic authority like this, we explicitly do not track the taxonomy from the primary literature. We have a couple reasons for this:

1. Taxonomy is subjective and not every scientist agrees with every paper

   While it may seem like the naming and classification of organisms is a formal process and all scientists agree on what names organisms should have, the truth is much messier. While there are standards for when and how an organism should be named, they do not apply to all taxa, and there are basically no universal standards for when two groups of organisms should be considered separate species. Biologists have never been able to agree on standards in these areas, so the result is much more akin to correct use of language than correct use of the periodic table: everyone has their own opinion, but most people tend to follow authorities (either individuals or groups) who they trust to make reasonable decisions about what names should be used. Thus, using names and classifications just because someone published a paper declaring that they should be used (even a peer-reviewed paper) is not a great idea, because it doesn't prove that the scientific community supports that paper's assertions.

2. iNaturalist is not a place to argue about taxonomy

   Or at least we don't want it to be. Since taxonomy is subjective, people argue about it all the time, and since there is no absolute truth one can apply to settle such disputes, they can become rancorous, often to the point of absurdity. Following taxonomic authorities helps us avoid having these arguments on iNat. We can argue about which authorities to follow, but following authorities allows us to skip arguments about each and every paper.

3. Primary sources are often hidden, while secondary sources are usually open

   iNat is largely a community of amateurs, and despite the advances made by open-access journals, the bulk of taxonomic literature is still prohibitively expensive for most amateurs to access. Avoiding the primary literature in favor of secondary taxonomic authorities, most of which are freely available on the Web, allows all our users to inspect the sources of taxonomic changes, not just the users with privileged access to the scientific literature.

4. Following established authorities makes it easier for us to share your data with researchers

   "What taxonomy do you use?" is often one of the first questions we get from researchers interested in using our data, if we're even fortunate enough to have that discussion. More often people find our data through aggregators like GBIF, so if we're using synonymous names that researchers or GBIF doesn't know about, researchers searching GBIF won't find our data. Following authorities moderates the pace of taxonomic change in our data and increases the probability that people searching through it by name will find what they're looking for.

All that being said, there are also many situations in which we do not (or cannot) follow authorities. Sadly, many taxonomic authorities are incomplete and/or out of date, often because they are underfunded, understaffed, or suffer bizarre decisions borne out of financial or political issues that have nothing to do with taxonomy. Indeed, our own policy of following authorities has proven to be somewhat controversial, particularly for people who curate groups where there are either no authorities or the existing authorities suffer from some of these problems.

So, as a curator, what's to be done? Basically, we try to match parts of our taxonomy to global taxonomic authorities. When that's not possible, we try stitching together regional taxonomic authorities (not recommended because of inevitable regional taxonomic conflicts like this). And for everything else we cite the primary literature or use the names and classifications we import from name providers like the Catalogue of Life and uBio. Here are the authorities we try to follow:

External Taxonomic Authority List

Mammals (Mammalia)

Mammal taxonomy is currently frameworked to the 2019 ASM Mammal Diversity Database, which is no longer available online. Explicit deviations are outlined here. This authority applies to all mammal taxa between class and species. (Mammal subspecies are not covered by a framework.)

Birds (Aves)

The Clements Checklist of Birds of the World as a global reference with explicit deviations outlined here. This authority applies to all bird taxa between class and subspecies.

Reptiles (Reptilia)

The Reptile Database as a global reference with explicit deviations outlined here. This authority applies to all reptile taxa between class and subspecies.

Amphibians (Amphibia)

AMNH Amphibian Species of the World (ASW) as a global reference with explicit deviations outlined here. This authority applies to all amphibian taxa between class and subspecies.

Fishes (Actinopterygii / Petromyzonti / Elasmobranchii / Holocephali / Myxini / Sarcopterygii)

Eschmeyer's Catalog of Fishes as a global reference with explicit deviations for each class viewed on their respective taxon pages. This authority applies to all "fish" taxa between class and species.

Assorted Marine Invertebrates

The World Register of Marine Species (WoRMS) serves as an umbrella reference for all animal ranks above class and is applicable to many phyla that mostly consist of marine species. A more elaborate description of WoRMS’s relationship to iNat’s taxonomy is available here. WoRMS technically counts as a "regional" authority since it only includes marine species. It also includes species covered elsewhere (e.g. cetaceans and sea turtles which are covered by the respective mammal and reptile authorities described above). However, for clades that are strictly marine it serves as a global reference. Additionally, WoRMS does include some terrestrial species for some non-strictly marine clades. This is made clearer in the "Global Species Database" section of the subregisters page. For example, see the section Mollusks below. Outside of mollusks, the only frameworked group that is completely inline with WoRMS is Ocypodidae (ghost and fiddler crabs).

Mollusks (Mollusca)

MolluscaBase as a global reference with explicit deviations described here. This authority applies to all mollusk taxonomic ranks beneath phylum, but the framework based on MolluscaBase currently applies to all taxa between class and family for most mollusk classes. @bobby23 and @jonathan142 are taxon curators for this group.

The only exception is Cephalopoda (cephalopods), which is completely curated all the way down to subspecies and has explicit discrepancies described here.

Spiders (Araneae)

The World Spider Catalog (WSC) as a global reference with explicit discrepancies outlined here. This authority applies to all spider taxa between class and subspecies.

Harvestmen (Opiliones)

World Catalog of Opiliones (WCO) as a global reference. This authority applies to all harvestmen taxa between order and subspecies.

Myriapods (Myriapoda)

ChiloBase and MilliBase as global references.

Insects (Insecta)

Unfortunately there are hardly any world authorities on any insect order, let alone all insects. When global authorities are missing, we refer to regional authorities such as BugGuide for North American insects or A Catalogue of the Butterflies of the United States and Canada or Illustrated Lists of American Butterflies (North and South America). The handful of authorities we follow are listed below. If you know of any others please feel free to bring them up on the forum. (See this forum post for taxonomic resources for additional insect groups.)

Ants (Formicidae): AntWeb

Dragonflies and Damselflies (Odonata): The World Odonata List (WOL) as a global reference with explicit deviations described here. This authority applies to all Odonate taxa between class and subspecies level.

Grasshoppers, Crickets, and Katydids (Orthoptera): Orthoptera Species File Online

Mantises (Mantodea): Mantodea Species File Online. @mantodea is a taxon curator for this group.

Stick Insects (Phasmida): Phasmida Species File Online. @loarie is a taxon curator for this group.

Plants (Plantae)

The taxon framework that covers the accepted plant phyla is based on the Catalogue of Life 2018 Annual Checklist but Catalogue of Life's status as an authority does not extend past those phyla. We do follow authorities for the phyla listed below:

Vascular plants (Tracheophyta): Kew’s Plants of the World Online (POWO) with deviations described here.

Mosses (Bryophyta): Flora of North America for North American taxa.

Fungi and lichens (Fungi)

Sadly, this is another group where there really is no global consensus, and names are changing rapidly, so for fungi we should try to follow the peer-reviewed primary literature. Index Fungorum is a decent source of names, and Species Fungorum has some information on what names should be current, but neither are up-to-date enough to satisfy most mycologists. Please be wary of Index Fungorum ePublications, though, which do not require any form of peer review or supporting evidence for name publication. Same goes for Mushroom Observer, which is a fantastic site but supports a number of unpublished and provisional names.

For North American lichens, we follow Esslinger's North American Lichen Checklist. Esslinger's list seems to have the respect of North American lichenologists, and it gets updated yearly.

Algae

Algae refers to a polyphyletic grouping of primarily photosynthetic single and multicellular organisms, encompassing certain members of Plantae, Protozoa, Chromista, and Bacteria. AlgaeBase is the authority for these taxa.

Viruses (Viruses)

Currently the best source for Virus taxonomy is ICTV.

Complete Taxa

For clades where all the members in a global external reference have been already added, often times most of the curation work to be done is cleaning up errors (e.g. synonyms automatically grafted from external name providers or from curators not aware of the taxonomic references being used). In these cases, iNaturalist may lock these clades down as "complete" which means it can only be edited by associated "taxon curators" for that clade.

Current complete clades are listed here. If you'd like to propose a new complete clade, it needs the following:

1. All extant species in the clade to be added to iNaturalist
2. A global external reference and any deviations from that reference explicitly mapped (e.g. as done here).
3. One or more taxon curators willing/able to take on all ongoing taxon curation tasks such as keeping iNat in sync with the external reference, resolving flags and disputes, and if necessary making explicit deviations for controversial or disruptive changes.

Hybrids

Given their vague morphological delineation and taxonomic uncertainty, use of hybrid taxon concepts should be avoided whenever possible. Adding IDs of higher-level taxa is usually sufficient. In those rare cases when some external authority actually supports a named hybrid, we will tolerate it, but abide by the following guidelines.

Hybrids between species should have scientific names (the name associated with the taxon) following the pattern GENUS SPECIES1 × SPECIES2, e.g. Dryobates nuttallii × scalaris for a hybrid between Dryobates nuttallii and Dryobates scalaris. The rank for such hybrids should be set to "hybrid." Note that the cross character is "×" and not the Roman letter "x."

Hybrids between species in different genera usually receive a generic name that is a portmanteau of the two constituent genera and a novel specific epithet, so the name of a hybrid genus should follow the pattern "× NEW_GENUS," e.g. × Chitalpa, and should receive the rank "genushybrid." The hybrid species should follow the rules above, e.g. × Chitalpa tashkentensis, and its parent would be the genus hybrid, e.g. × Chitalpa.

Hybrids should only be made between taxa of the same rank. Hybrids like Canis lupus × canis lupus ssp. familiaris don't make sense. That's like saying you made a new kind of vehicle by combining the traits of a Honda Civic and a car.

Extinct Taxa

iNaturalist is about observing living things so maintaining extinct clades in the taxonomy is not a curation priority. However, Extinct clades are tolerated provided:

1. They fit into the taxonomic backbone - e.g. the Passenger Pigeon belongs to the extinct genus Ectopistes which nests neatly within the extant family Columbidae. But accommodating the extinct "mammal-like reptiles" would require changing the backbone by inserting new nodes between the existing Subphylum Vertebrate and Class Mammal nodes or breaking up traditional (but non-monophyletic) basal groups used by Catalog of Life and GBIF such as reptiles. We prioritize taxonomic backbones that match external references over ones that can accommodate extinct groups.

2. The extinct nodes and all of its descendants are marked as Extinct by adding Extinct conservation statuses. Since this is a lot of work, curators may prefer to rather ungraft or inactivate extinct clades rather than do the work involved in marking the entire clade as extinct. If you care strongly about including an extinct clade, be prepared to do this work yourself.

Additional Taxonomic Nodes

There has been some confusion on iNaturalist about when it's appropriate to add additional taxonomic nodes beyond the familiar Linnean nodes (Kingdom, Phylum, Class, Order, Family, Genus, Species) such as subfamilies or tribes.

While our general tendency is toward fewer nodes for the sake of simplicity, the heuristic we use is utility: if you feel some users on the site (including yourself) will benefit from having a subtribe in the system, perhaps because that's the lowest taxonomic level at which a particular insect can be identified based on a photograph, then go ahead and add it (provided you properly curate the node as described shortly). If you're adding a subtribe just because someone somewhere decided they like taxonomic units with less than 20 species in them, don't add it, because that doesn't really help anyone on iNat.

Properly curated nodes on iNaturalist should have all of their children grafted beneath them. Lets use the plant family Proteaceae and its descendant genera as an example. The family node Proteaceae is green because all taxa within this clade are grafted as descendants rather than as siblings.

For the familiar Linnean nodes fully curating them (ie making them green) is generally feasible (ignoring the occasional incertae sedis node that can be confidently placed). But with many additional taxonomic nodes, it can be difficult or impossible to properly determine which nodes are descendants and which are siblings. For example, suppose a curator wanted to add a subfamily and tribe to the family Proteaceae and did the following:

In the above, the nodes for the subfamily and tribe are now red because only some, but not all of the iNaturalist taxa within that group have been grafted as descendants. The genera in yellow should be included in the tribe and/or subfamily but were not curated.

This partial-curation situation is common on iNaturalist and causes problems with the integrity of the tree. For example, if user A identified an observation as "Tribe Persoonieae" and user B subsequently identified it as "Genus Garnieria", user B's intention was likely to agree with user A while offering a more refined ID. But if the tree were structured as above, user B's identification would be treated as a disagreement with user A. If you want to add additional nodes to a tree make sure you are willing and able to spend the time ensuring that all nodes globally that should be included in that node are grafted as descendants. For example, to turn the red nodes above green, the tree should be curated as follows:

Often it may be impossible to determine whether all iNaturalist taxa globally are descendants or sibling to an additional node. This is more and more likely to be the case the more "obscure" these nodes become (e.g. section, subsection, subtribe etc.).

As a rule of thumb, not including additional nodes in iNaturalist is preferable to including but only partially curating additional nodes as in the middle tree above. Please consider before introducing additional nodes: (1) are there global references that will enable curators to properly determine whether other taxa are siblings or descendants of the node? (2) are you willing to take the time to fully curate these other taxa? If during your curation you encounter partially curated nodes, it may be preferable to remove them rather than to fully curate around them if it is not possible or practical to fully curate them.

Species Complexes

As of January 2019, "complex", a taxonomic rank between genus and species, may be used (more specifically, between subsection and species). Species sometimes intergrade and there are places on the tree of life where adding hard range map boundaries is arbitrary and/or identification to species level is often not possible. Species complex should be used sparingly (only when necessary and helpful) and with the following criteria:

• Species complex is monophyletic (i.e. sibling groups of species)
• Complex is recognized in the literature
• A named subgenus, section, or series does not already exist for the group
• If a "principal species name" is not established in the literature, use the earliest published species name for the name of the complex. Enter just the name ("Hyla versicolor") and not additional words ("Hyla versicolor species complex" or "Hyla versicolor group"), for consistency and because iNaturalist is an international database; these words do not translate into other languages.
• Don't use compound names, such as Pantherophis alleghaniensis-spiloides, as there may be numerous species in the group

Examples include:

• Complex Hyla versicolor: Gray Tree Frog Complex, for Hyla versicolor and Hyla chrysoscelis
• Complex Pantherophis alleghaniensis: Eastern/Gray Ratsnake Complex, for Pantherophis alleghaniensis and Pantherophis spiloides
• Complex Laphria canis: for Laphria canis, L. franciscana, L. sicula, L. winnemana
• Complex Spiranthes cernua: nodding ladies tresses species complex, for numerous species.

Curating Taxon Ranges and Atlases

Here's a tutorial on how to curate iNaturalist Taxon Ranges.

The creation and use of iNaturalist Taxon Atlases are described here.

Keeping Track of Taxonomic Concepts (Taxon Frameworks)

Some databases are explicit about the taxonomic concept that their names refer to, and in many cases these are different. For example, in IUCN Pseudacris regilla currently means something different (a frog whose range extends from the Pacific Northwest to Baja) than Pseudacris regilla means in Natureserve (a frog just in the Pacific Northwest). Within iNat, we use Taxon Frameworks to keep track of which iNaturalist taxon is the one different taxonomic authorities are referring to. Any taxon that is covered by a sourced Taxon Framework should have a Taxon Framework Relationship. Only curators can create, edit, or destroy Taxon Framework Relationships. If the Taxon Framework has taxon curators (e.g. birds, reptiles, amphibians, mammals), only these taxon curators can create, edit, or destroy them. As of January 2019, this system is still in the process of being finalized.

Read more about Taxon Frameworks here.

Places

Places on iNaturalist represent physical places on Earth (no support for extraterrestrial places yet). When we started the site we pre-populated our places based on shapefiles from the US Census Bureau, the ESRI world political boundaries, and the California Protected Areas Database. We've run a few scripts since then to populate the database with some more places, but most of the rest come from user searches against the Yahoo GeoPlanet API. The remaining places were all manually created by users, and should show a "Place added" notice at the lower right of the place page showing who added it.

Anyone can add a place on iNat, but the only people who can edit it are the person who made it manually and the site curators. Here are some things to keep in mind when curating places:

• Don't merge or delete places just because they look like duplicates. Try to figure out who added and is using a place before deciding it should go. Sometimes someone may have created a place that is similar to another but has a slightly different boundary because their project has different requirements.
• New places don't have checklists by default, because keeping checklists up to date is actually one of the most computationally intensive things we do, so we want to minimize the number of checklists. If you only want to add a place so you can search for observations within it, please don't enable the checklist.
• Places imported from Yahoo have no boundary defined, so even if they have a checklist, it won't be automatically updated by research grade observations. You can add a boundary by editing the place and using the map tools, or by uploading a KML file. However, if you upload KML, don't upload really, really complicated polygons. If your places has several thousand nodes, consider simplifying the geometry before uploading.
• Our map editing interface is fairly primitive. Using ArcGIS or QGIS will be a lot easier. Note that all our place boundary data are stored in unprojected lat/lon coordinates using the WGS84 datum.

Flags

Any iNat user can flag observations, comments, photos, identifications, and other sections of the website. They can also flag taxa that they think need curation. As a curator, you can see the most recent flags in the "Curation" box on your Dashboard or by visiting https://www.inaturalist.org/flags. You can browse taxa curation flags at https://www.inaturalist.org/taxa/curation. Try to deal with these issues if you can, and when you do, mark the flag as resolved so that it no longer shows up in the queue.

We typically leave the following types of flags left unresolved: true spam flags, photos flagged for copyright infringement, and duplicate observations.

Curators should not attempt to resolve or intervene in flags placed resulting from disputes over the political administration/ownership of territory. Any such flags should be immediately forwarded to staff to deal with.

Here's more detailed information about finding and dealing with fabricated observations.

Boilerplate Text for Resolving Flags

Users under age 13

Anyone under the age of 13 with an iNaturalist account must have permission from their parent or guardian. Preferably, this happens at the time their account is created using this form. However, sometimes children create accounts without this step.

If you see someone identify themselves as under 13 in their profile, comments, on the forum, or any other way, reach out to [email protected] with their username so that staff can check whether or not they have adult approval on record. If not, iNat staff will reach out to them with instructions about the steps to take. If staff does not hear from the appropriate adult in 7 days, the account will be suspended.

Spam and Other Inappropriate Content

We've defined inappropriate content in our FAQ (to the extent that such a definition is possible), and it will inevitably pop up from time to time.

Provided they don’t violate the iNaturalist Community Guidelines or Terms of Use, personal political and religious views, as well as links to endeavors unrelated to iNaturalist such as one’s business, can be added to account profiles. However, they should not be posted as comments, identification remarks, or notes/descriptions on observations.

As of August 29th, 2023, curators can now hide the following content:

• Images and Sounds
• Comments
• Identifications

Below are the policies curators should follow when deciding to hide content. If in doubt, consult other curators. Note that hiding content should be used when other methods, such as flagging as spam or copyright infringement, do not apply. When you hide content you will be prompted to enter a reason for hiding it, which will be visible to all users, this reason should not be a generic comment like "inappropriate" or "inflammatory", rather, it should clearly indicate what policy the hidden content violated.

Hiding Photos

Photos should be hidden if they violate any of the suspendable offenses listed in the Community Guidelines, such as hate speech, insults, threats, and sexually explicit content involving humans. 

The lists of examples below are not exhaustive. 

Examples of photos that should be hidden:

• Human nudity and/or sexual activity
• Images or words meeting the iNaturalist definition of hate speech
• Threats or depictions of violence against humans
• Images being used to bully or harass someone, such as a photo in combination with an insulting comment or ID
• Sensitive information accidentally posted by the observer, such as personal information or the location of threatened species (eg if a map or sign is included)
• Human remains

Examples of photos that are OK:

• Humans holding animals or plants, such as a fish, where the non-human is the subject
• ID cards or badges intentionally placed in the frame
• Images of dead or dismembered animals
• Images of someone holding a non-human organism

August 29, 2023: Because observations of humans are tolerated on iNaturalist but are not important to the site, flagged photos depicting humans should be hidden. We will re-evaluate this policy moving forward, if it results in abuse of the flagging/hiding system or becomes overwhelming for curators. 

If the photo appears to depict violence, pornography, or child abuse, hide it and email [email protected] right away. 

If the photo infringes on someone's copyright, just flag it as copyright infringement. Don't use the "hide" option.

Hiding Identifications

Identifications deemed to be intentionally inaccurate, for any reason, should be hidden. When hiding the identification, write a note stating your interpretation of why the intentionally inaccurate identification was made.

Common motivations for intentionally inaccurate IDs:

• Retribution for perceived or real slights or misidentifications
• Insults or hate speech, such as identifying a photo of a human as something insulting, racist, or sexist
• Joke identifications, such as wildly inaccurate or silly identifications

Hiding an identification will remove it from public view and inactivate it - it won’t count toward the observation’s Community Taxon. Wrong identifications that are made in good faith should not be hidden.

Hiding Comments

Comments should be hidden if they violate one of the suspendable offenses in the iNaturalist Community Guidelines. This includes insults, hate speech, threats, and personal attacks. Comments that further inflame contentious interpersonal arguments - needing to have the last word - may also be hidden at a Curator’s discretion.  

The following are not exhaustive lists.

Examples of comments that should be hidden:

• Hate speech
• Insults, including belittling someone about their knowledge or experience level
• Curse words used as an insult (eg “You little shit.”)
• Continue to have the last word of an argument 
• False information
• Libel

Examples of comments that are OK:

• Curt comments
• A curse word not used in an insulting or obscene manner (eg “Holy shit, that’s cool!”)

Hiding Sounds

Joke sounds, such as fake animal noises, as well as sounds that violate any of the suspendable offenses listed in the iNaturalist Community Guidelines, should be hidden. This includes insults, threats, hate speech, depictions of violence, or human sexual content. Sounds that constitute copyright infringement should also be hidden.

Curators don't have the ability to hide other kinds of records. We need a better system for dealing with this, but for now please send contact [email protected] if you find inappropriate content in observation descriptions, projects, journal posts, etc.

Keep in mind that pictures of pets, humans, obvious test observations, and drawings that depict the organism observed are appropriate, unless someone repeatedly posts such content. These kinds of observations are educational opportunities, so inform the person that iNat is primarily for sharing observations of wild organisms from nature by leaving a polite comment or private message. If 25% or more of a user's observations are of pets, humans, abiotic phenomena, or other off-topic subjects, or if they persist in this kind of behavior despite being warned, that constitutes abuse and you should contact the site staff at [email protected], who will give the user 24 hours to remove the off- topic content, after which they will simply remove it for them. All that being said, a few off-topic observations here and there are ok.

An additional note regarding drawings: drawings are ok because, like photos, they can show visual evidence of the individual organism observed. If you don't think the drawing was of the observed organism (e.g. it's just a drawing of the species, not of an individual), talk to the observer and ask them to clarify what their drawing depicts. If they admit the drawing is not of an individual organism they observed, you can contact [email protected] and the staff will ask the user to remove the photo if you don't feel comfortable doing so yourself. The image can be hidden if they do not comply. If you cannot identify the organism from the drawing, treat it like a blurry photo and vote that the community cannot improve the ID.

Trolls

A troll is someone who hides behind the anonymity of the internet to purposely provoke a negative emotional response from other users, often by resorting to insults, jokes, spurious arguments, and other forms of norm-breaking behavior. On iNaturalist one example of the latter would be adding a number of intentionally incorrect identifications.

As Webroot says, "While you can’t control whether you will become a troll’s target, you can decide if you will make yourself a troll’s victim." With that in mind, here are guidelines for responding to trolls on iNaturalist:

Don’t bite — "troll" comes from the verb "trolling," a fishing activity where one drags a baited lure from a moving boat, hoping to get a bite. No matter how provocative, don’t respond in an emotional way - if you choose to respond at all. An emotional retort is exactly what the troll wants and you will only encourage their behavior. While some recommend responding with humor, this can be tricky unless it’s done just about perfectly, so we would advise against it.

Encourage others to do the same — if someone has already responded in an emotional way, send them a private message asking them not post any more replies, and explain your reasoning.

Engage the community — if the troll is making joke IDs on multiple observations, message a few other experienced users to, without comment, add correct IDs.

Think twice about suspending the troll — Suspension can often backfire because it’s easy for a determined troll to keep making new accounts, and they will use the suspension(s) as motivation.

Report trolling to [email protected] — iNaturalist staff can look into the situation and engage the troll, as well as possibly delete obscene/inappropriate content.

Note that one-off jokes from students should not be considered "trolling" unless the behavior is widespread and antagonistic to other iNat users. In most cases these students are playing pranks on their friends and happen to be doing so on a public platform. Not appropriate behavior for iNaturalist, but it's not trolling.

Frequently Used Comments on Observations

These are comments often posted on observations by site curators and other users as we try to help people learn how to use iNaturalist: https://www.inaturalist.org/pages/responses. Copy and paste responses from that page to save effort writing the same thing again and again.

Network Site Admins

iNaturalist has formal agreements in many parts of the world for local institutions to support localized but fully connected network sites. If there are issues related to a geographic area covered by the network, or users from there, please loop in the respective site admin(s):

• Argentina: @roget
• Australia: @peggydnew @p_brenton
• Canada: @jpage_cwf
• Chile: @lartundo
• Colombia: @carolinasoto
• Costa Rica: @mich_croc
• Ecuador: @sofianogales @panchoprieto @inclandj
• Finland: @mikkohei13 @laihoel @karilahti
• Greece: @dkats
• Guatemala: @melojeda
• Israel: @ariel-shamir
• Luxembourg: @paul_luap @taniaw
• Mexico: @carlos2 @elizatorres @roberto_arreola
• New Zealand: @jon_sullivan @meurkc
• Panama: @guillermofadul @brosisrodriguezb
• Portugal: @luis2 @patriciatiago
• Sweden: @cynips
• United Kingdom: @giselle_s
• Uruguay:@flo_grattarola

Language Fluent Curators

Most of the time, flags or general help can be handled effectively in English. However, at times, language may be a barrier. If needed, below is a list of curators (or other active users) fluent in languages other than English, whom you can enlist for support:

• Arabic:
• Bulgarian:
• Catalan: @josepgesti
• Czech:
• Chinese: @cosmophasis, @wsyxbcl
• Danish: @cmcheatle, @jlisby
• Dutch: @belgianbirding
• Estonian:
• Farsi:
• Finnish: @mikkohei13
• French: @cmcheatle, @kitty12, @alecc, @t_e_d
• German: @arborsphere, @vmoser, @severinus
• Hebrew: @centaur, @astra_the_dragon, @ariel-shamir
• Hindi: @naturalist_aditya
• Indonesian: @naufalurfi, @zebs
• Italian: @philodendronjoe, @mazzeip
• Japanese:@invertebratist, @utchee
• Korean:
• Latvian:
• Lithuanian:
• Polish: @e150a
• Portuguese: @magazhu
• Romanian:
• Russian: @convallaria1128, @kastani, @w4v
• Spanish: @vechocho, @magazhu, @joaco5, @nicolasr
• Swedish: @severinus
• Thai: @plains-wanderer
• Ukrainian: @igor117
• Vietnamese:

Editing This Wiki

Curators can edit wiki pages like this one and the other help pages by clicking the "Edit" link at the bottom right of the page. You can create new pages by visiting the URL you want (e.g. https://www.inaturalist.org/pages/somepage) or by clicking to it from an existing page using the internal link syntax (e.g. somepage) and clicking the link.

Wiki pages support full HTML as well as Markdown formatting. The Formatting box on the edit form will show you what's available.