Curator Guide

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. If you're not a site curator and would like to help curate our taxa, please contact us. We will generally allow anyone to be a curator if we know they have some expertise, or if they've demonstrated expertise by using the site. If you would like to be a curator but we don't know you and you have zero observations or identifications, we will probably ask you to use the site a bit more before approving your request. If you demonstrate by your behavior on the site or through your communication to us (the site admins) that you are unwilling to abide by our curatorial policies, abusive to us or members of our community, or otherwise unreasonable, we 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 admins.

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. The site admins do some of this in broad strokes from time to time, but we don't have the resources to keep everything current all of the time, or to vet everything we get from our data partners, so some hands-on curation is required.

Keep in mind that 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.

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 http://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 valid scientific name for this taxon.

You Probably Don't Want to Change the Name

Please do not change the 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 will not preserve the history of the change and will not notify people about the name change. The only legit reason to edit a taxon name is to fix typos.
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 help@inaturalist.org.

Editing Taxa Geoprivacy Settings

iNaturalist obscures the locations of all taxa with an IUCN equivalent status of Near Threatened or 'worse'. However, if in rare situations these species are thought to be in VERY LITTLE DANGER from exploitation due to the public's knowledge of the location of these species, curators are advised to change the geoprivacy value associated with the conservation status from 'obscured' to 'open' on the taxon edit page.

Examples might be Coast Redwood 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, polar bears are endangered from climate change but perhaps not from poaching.

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. 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.

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 left of the taxon page, you'll see a list of "All names." Any iNat user can add names using the "Add a name" link, but only curators can edit scientific names and delete names added by other people.

Default Name

Currently the default common name for a taxon is the first English name that was added to iNat. In the future curators should be able to declare a default name more explicitly, but for now it's just based on order.

Capitalization

In general common names should be lowercase, except for animals, which should be capitalized. Capitalization is by "title case," meaning every distinct word in the name starts with a capital letter (examples: Eurasian Blackbird, Sulphur-crested Cockatoo). Proper nouns should always be capitalized wherever they appear.

Just the Name, Please

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 please don't 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, please don't make one up.

For higher level taxa it can be hard to use a common name that describes all descendants. In these cases, we usually 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," please 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.
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
De-activates 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 http://www.inaturalist.org/taxon_changes, or just going directly to http://www.inaturalist.org/taxon_changes/new.

Check Before You Change

Before you create a new Taxon Change, check to see if someone has already done so by clicking "Taxonomic Changes" under "Extras" on the lower left of the taxon page.

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. http://www.inaturalist.org/taxon_changes/31) and update your own content at the "commit for user page" (e.g. http://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.

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 valid, 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.

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 de-activated

  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 b/c 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 evertyhing 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, please try and 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 admins if you make a mistake (like the new identifications), 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. Please do not make changes that conflict with these authorities.

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

While not required, we would like every change to be traced back to some publication or 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 / impossible to find without extensive library research, sourcing the change to a website or database is cool 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 and 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 is not one of our taxonomic authorities! If you must cite them, perhaps because one of our authorities doesn't include an older synonym, please link directly to the relevant content, e.g. http://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 admins) would prefer a more collaborative process whenever possible.

Policies

External Authorities

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 match parts of our taxonomy to some taxonomic authorities, but for everything else we either accept the names and classifications we get from name providers like the Catalogue of Life and uBio, or we cite the primary literature. Here are the authorities we try to follow:

Mammals
The IUCN Red List of Threatened Species
Birds
The Clements Checklist
Reptiles
SSAR (within the US)
The Reptile Database (Globally)
Amphibians
For amphibians we are piloting an approach that uses an Internal Reference Taxonomy derived from Amphibian Species of the World as iNaturalist's taxonomic authority for Amphibians. Read more here.
Fish
FishBase
Marine Invertebrates
World Register of Marine Species (WoRMS)
Spiders
The World Spider Catalog
Insects

There are hardly any world authorities on any insect order, let alone all insects, so it's a tricky group. For most North American insects we try to follow BugGuide, but with deference to the following authorities:

Butterflies: A Catalogue of the Butterflies of the United States and Canada

Ground Beetles: Carabidae of the World

Ants: AntWeb

Dragonflies and Damselflies: World Odonata List. And here's a conversation used for discussions about keeping iNat's ode taxonomy in sync with this source, please add any new ode related taxonomy questions/comments to that thread.

Bees (Andrenidae, Apidae, Colletidae, Halictidae, Megachilidae, Melittidae, Stenotritidae): ITIS World Bee Checklist

Terrestrial Isopods

Checklist of the terrestrial isopods of the new world (Crustacea, Isopoda, Oniscidea)

Vascular Plants

Plant taxonomy seems to have few centralized authorities that keep their data up-to-date. IPNI would be the ideal global source, but it seems difficult / impossible to retrieve forward synonymies, so The Plant List serves as a decent surrogate. The Kew World Checklist of Selected Plant Families is generally more up-to-date, but not comprehensive.

Regional floras tend to be more useful and up-to-date, so we try to follow a number of them, and resort to The Plant List to resolve conflicts (e.g. if Calflora thinks a dogwood is in Cornus and GoBotany thinks it's in Swida, we choose the placement favored by The Plant List). Our regional authorities are:

  • Canada: VASCAN

    Regularly updated and good for searching names and synonyms.

  • New Zealand: Ngā Tipu Aotearoa – New Zealand Plants

    Site admins for NatureWatchNZ consider this the main authority for New Zealand plants. It's pretty current and has lots of info on synonymy.

  • United States
    • California: Calflora

      Calflora uses an amalgamation of The Jepson Manual II, USDA PLANTS, and CNPS rare plant lists. We are a bit biased toward California here, but a large number of us are interested in California floristics, and we haven't run into many taxonomic conflicts with other systems, so it works for now.

    • New England: GoBotany

      GoBotany follows Flora Nova Angliae (2011) by Haines, which is recent and has relatively few conflicts with Jepson.

    • South Eastern United States: Flora of the Southern and Mid-Atlantic States

      Flora of the Southern and Mid-Atlantic States is maintained by Alan Weakley at the UNC Herbarium, North Carolina Botanical Garden, University of North Carolina at Chapel Hill.

Bryophytes
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 IF 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.

Splitters vs. Lumpers

While our general tendency is toward lumping 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. 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.

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 please 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. Picoides scalaris × nuttallii for a hybrid between Picoides scalaris and Picoides nuttallii. 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.

Keeping Track of the Taxonomic Concepts (Taxon Schemes)

Several of these External Authorities such as IUCN and NatureServe 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). In iNat, we use Taxon Schemes to keep track of which iNaturalist taxon is the one different taxonomic authorities are referring to.

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, please 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 http://www.inaturalist.org/flags. You can browse taxa curation flags at http://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.

Boilerplate Text for Resolving Flags

Below are some boilerplate text options you may choose to use when resolving flags for issues that occur frequently.

  • A new user's test observation is flagged: New users often post test observations to ensure the app is working prior to getting out and exploring nature. Instead of flagging the observation, we recommend marking the observation as "Evidence of organism? No" in the Data Quality Assessment section and leaving a welcome message, recommending them to delete the observation, and/or leaving a comment about appropriate use of iNaturalist. If the user repeatedly posts inappropriate observations, the curators or admins can decide whether they should be suspended.

  • Non-spam is flagged as spam: iNaturalist's definition of spam is anything that is clearly intended to make money, which could be links to spurious sites or attempts to manipulate search engine indexing through lots of links to weird places (https://www.inaturalist.org/pages/help#spam). Here are some things that are not spam: photos of humans or inanimate objects, photos that violate copyright (there's a separate flag for that), offensive or inappropriate content created by someone who's clearly a legitimate iNat user, or anything that you arbitrarily dislike. If you have any hesitation, please contact a site curator or site admin to discuss the issue, or message help@inaturalist.org.

  • Observation rather than photo is flagged as copyright infringement: Thanks for bringing this to our attention. I have marked the photo itself as copyright infringement. In the future, please flag the photo(s) directly rather than the observation. You can do this by clicking the "i" (white circle) below the photo and clicking "Flag this photo" in the very bottom righthand corner of that page. Then choose "copyright infringement" in the pop-up and save. No need to also flag the observation. Thanks again.

  • Flagger indicates the photo on a taxon page is incorrectly identified: If you're positive this is identified as the incorrect taxon, then please correct this on the taxon page: [taxon page URL]. If you click on "Curation" and then on "Edit photos," you should be able to remove this photo and then add a correctly identified photo of this species.

  • Taxon is missing (but was able to be added automatically): If a species or other taxon is missing in the iNaturalist database, try typing the name into the identification field of an observation and choosing "Search External Name Providers." You can also search for it under "Species" in the main navigation menu on any page, then scroll to the bottom where it says "Not Seeing What You're Looking For?" and click the Search buttons in that section. This will try to import the name automatically from Catalog of Life and some other sources. If that doesn't work, it will need to be added manually by an iNat curator, and in those cases, feel free to flag it as you've done here, or post the request on the Google Group: https://groups.google.com/forum/#!forum/inaturalist . Thank you!

  • Observation of human is flagged: New users often post test observations to ensure the app is working prior to getting out and exploring nature. Instead of flagging the observation, we recommend simply identifying it as human (Homo sapiens) which will make the observation "Casual" grade automatically. You can also leave a comment guiding them toward more appropriate use of iNaturalist. We have prepared several frequently used comments of this type here: https://www.inaturalist.org/pages/responses

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. Curators can delete comments that seem inappropriate, but at present they don't have the ability to delete other kinds of records. We need a better system for dealing with this, but for now please send contact help@inaturalist.org if you find inappropriate content in observation descriptions, projects, journal posts, etc.

Please 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 admins at help@inaturalist.org, 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, please contact help@inaturalist.org and the admins will ask the user to remove the photo, and remove it for them if they don't 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.

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. Cut and paste from this page to save effort writing the same thing again and again.

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. http://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.

Revised on September 29, 2017 01:01 PM by bouteloua bouteloua
Member of the iNaturalist Network   |   Powered by iNaturalist open source software