Project Management

Consistent project management keeps field records understandable, recoverable, and ready for later curation.

Name projects and sites consistently

• Use a short project name that identifies the expedition and target taxon, such as Patah Mammals.
• Use the project date fields for the start and end dates rather than putting dates in several names.
• Give every collection site a unique, stable Site ID. See the Sites guide for the field-level workflow.

Separate field and lab workflows

In the field, record observations as soon as practical, review required fields before moving to the next specimen, and keep a paper log only as a deliberate fallback. In the lab, review records, normalize names and identifiers, attach or inspect media, and resolve errors before publishing or archiving. Keep a written handoff when more than one person curates the same project.

Back up on a field cadence

Export the project at the end of every field day. Back up the database once a week, and always before merging. The two are not the same job, and using the heavier one daily is the most common mistake we see.

A project export is small, quick, and undemanding on a battery you may not be able to recharge for days. It carries the project records and its available media, and Merge project reads it back into NAHPU, so a lost, broken, or stolen device costs you at most one day of work. A JSON.GZ light export drops the media and gets small enough to upload over a weak connection.

A database backup copies the whole installation: every project with its media and associated files, every personnel photo, and the entire user configs directory with its presets, fonts, and maps. Those directories are copied whole rather than file by file from the database, so the archive carries every file in NAHPU app data whether or not a project links to it. That is what you want when the goal is to rebuild a device exactly, or when a merge could go wrong and you need a point to return to.

In fieldwork, treat it as an occasional backup: weekly, immediately before any merge, and at moments when battery use is not a concern, such as a rest day or a night on mains power. Running it nightly is what fills a field device, a limited connection, and a battery you may not be able to recharge. The project export is the faster, project-specific backup that keeps the routine size manageable.

Apply the 3-2-1 rule to whichever file you just made: keep at least three copies, on two different media, with one copy off-site or in the cloud. Use a project name and date in each filename, for example BorneoMammals_20241015.zip.

Do not assume that a file exists merely because it was copied. Periodically merge a project export or restore a database backup on a second device and confirm that the records and media are usable. Keep one copy on a separate physical device in case cloud access is unavailable.

Transfer projects safely

Use the Project Transfer guide to move or combine the same project between NAHPU devices. Use JSON.GZ for a records-only upload over limited internet; it excludes media and is not a full backup. Use ZIP or TAR.GZ when the receiving device needs a complete project copy with media. Review counts and missing-media warnings, use a descriptive archive name, and retain the original backup until the receiving device has been checked.

Name exports clearly

Use the project name, package type, and date, such as BorneoMammals_DwC_20241015.csv or BorneoMammals_transfer_20241015.zip. See the Export guide for the available export, backup, and archiving actions.