Archived community project files are useful only when someone can tell what they contain, where they came from, and whether they can be shared. A simple, consistent labeling system helps volunteers preserve that context without requiring specialist archival software.
1. Decide what belongs in the archive
Before renaming or moving files, agree on the project’s scope. An archive might include meeting minutes, flyers, photographs, budgets, correspondence, workshop materials, and reports. It might exclude duplicates, temporary downloads, personal files, and drafts that do not document decisions or activities.
Ask the project team, including people who took part in the work, what future readers are likely to need. For human-rights literacy projects, for example, context may matter as much as the finished resource: who created a handout, which audience it was for, what language it used, and whether it reflects a particular point in the project.
A short written policy can answer:
- Which project activities and dates are covered?
- Who is responsible for selecting and labeling files?
- Are drafts retained, and if so, how are they distinguished from approved versions?
- Who may access the files, and are any items restricted?
- How will corrections or later additions be recorded?
Do not assume that every file should be kept or shared. Consent, confidentiality, safety, copyright, and the expectations of contributors may affect what belongs in an archive and who may see it. If an item raises a serious privacy or safety concern, pause its wider distribution and consult the people responsible for the project’s records and safeguarding practices.
2. Gather files without losing their context
Collect files into a staging area before sorting them. Preserve the original folder structure where practical, and make a separate working copy if you need to rename or reorganize files. This gives the team a way to compare changes and reduces the chance of overwriting a source file.
Keep related items together when their relationship explains the work. A signed meeting record, its agenda, and the handout discussed may be more useful as a group than as files scattered across unrelated folders. If you cannot keep them together, use a shared project or activity identifier in their labels or records.
Look for useful context in existing sources: folder names, document contents, file properties, email subject lines, or notes from volunteers. Record what is known, and mark uncertainty rather than guessing. For instance, use “date unknown” in a catalog note instead of assigning an unverified date based on a vague recollection.
Make a basic inventory
Before detailed labeling, create a list with one row per file or meaningful group. A spreadsheet is sufficient for a small collection. Include the current filename and location so a volunteer can match each row to its item. If a large collection needs specialized handling, a local archivist or records professional can help assess the scale and appropriate tools.
3. Choose a filename pattern volunteers can follow
A filename should be readable at a glance, unique enough to distinguish related files, and stable over time. Start with the date when it is known, then add the project or activity, the file’s subject or type, and a version or sequence when needed.
One workable pattern is:
YYYY-MM-DD_ProjectOrActivity_Description_Version.ext
Examples:
2025-04-12_RightsWorkshop_Agenda.docx2025-04-12_RightsWorkshop_FacilitatorNotes_v01.docx2025-04-12_RightsWorkshop_FacilitatorNotes_APPROVED.pdf2025-04_RiverCleanUp_ParticipantFlyer_en.pdf
Use a date format consistently. A full date is useful when the exact day is known; a month or year can stand in when that is all the evidence supports. Keep the original file extension, since it identifies the format. Avoid putting names, phone numbers, addresses, sensitive case details, or access passwords into filenames.
| Label element | Example | What it tells a future reader |
|---|---|---|
| Date | 2025-04-12 | When the item was created or used, if known |
| Project or activity | RightsWorkshop | Which work the file relates to |
| Description | ParticipantFlyer | What kind of item it is |
| Version or status | v02, APPROVED | Which copy or stage it represents |
| Language or format note | en, large-print | A useful variant, when relevant |
Use plain words and a small vocabulary.
Decide whether the team will write MeetingMinutes or Minutes, for example, and stick with the choice.
Underscores or hyphens can separate parts; choose one style and check that it works with the team’s operating systems and tools.
Avoid characters that commonly cause problems in filenames, such as slashes, and avoid excessively long labels.
Do not label a file “final” if later versions may exist.
Prefer a version number, a clear status such as APPROVED, or both.
If a file is a draft, say so where that helps prevent accidental use.
Keep version numbers in a consistent order, such as v01, v02, and v03.
4. Organize folders around the work
Use a shallow folder structure that reflects how people look for project records. One option is to arrange by year, then activity or workstream:
2025/Outreach/2025/Workshops/2025/Governance/2026/CommunityResearch/
Another project may work better with activity folders first and dates within them.
Choose the structure that matches how volunteers understand the work.
Avoid making deeply nested folders that require a precise memory of the filing path.
A clear top-level README or index can explain what the folders cover and how labels are formed.
Keep a separate location for records with restricted access, if the project has a suitable secure system and a clear access process.
A folder name such as Private is not itself a security control.
Use the storage platform’s actual permission settings, and limit access to people with a project-related need.
Do not place confidential files in a broadly shared folder and rely on a label to protect them.
When moving files, update the inventory’s location field. If links in other documents point to the old location, check whether the move will break them. For a small collection, a consistent folder structure and inventory may be enough; for a large or frequently updated collection, a managed records system may be more reliable.
5. Add a short description and handling note
Filenames cannot carry all the context a future reader needs. Add a brief catalog entry or spreadsheet fields for each item or group. Describe the content in neutral language, explain how it relates to the project, and include known creator, date, format, and version information where useful.
Useful fields include:
- Title or filename: The current label.
- Date: Exact, approximate, or unknown; note how an estimate was made if relevant.
- Creator or source: A person, project team, partner, or “unknown,” as appropriate.
- Description: A sentence about the item’s content and purpose.
- Activity or workstream: The related workshop, campaign, meeting, or project phase.
- Format and language: Such as PDF, spreadsheet, audio, or a named language.
- Status: Draft, approved, published, or superseded, if known.
- Access note: Public, internal, restricted, or review required, using the project’s agreed categories.
- Related items: Other files that explain or accompany this one.
For example: “Facilitator notes for the April 12 rights literacy workshop; created by the workshop team; English; approved copy; contains no participant names; see the agenda and feedback summary.” Keep descriptions factual. Avoid turning an archive record into an unsupported claim about what participants believed or what an activity achieved.
Keep labels respectful and useful
Human-rights and community records can include sensitive accounts, images, or descriptions of people. Use language that is accurate and respectful, and consider whether a detailed description could expose someone to harm. If a participant’s chosen name differs from a name in an old record, do not silently rewrite the historical item; record the relevant context in a controlled catalog note if appropriate and safe.
Do not include personal information in public-facing metadata simply because it appears in the file. Where there is uncertainty about consent or risk, limit access while the responsible project team reviews the item. Access categories should describe the current handling decision, not promise permanent secrecy or unrestricted release.
6. Preserve originals and make changes traceable
Keep a record of renaming, grouping, or redaction decisions. For a small archive, a “changes” column in the inventory can say that a file was renamed from its original title or that a duplicate was excluded. Retain the original filename in the record when it helps people trace the item back to its source.
Do not edit the only copy of an original document to make it easier to read. Store a working or access copy separately, and indicate which copy is the original. If information must be removed from a copy for safety or privacy, create a redacted derivative using an appropriate tool, label it as a redacted copy, and retain the original only where the project has a justified, secure basis for doing so.
Use storage that the project can maintain. For digital preservation, keep at least one additional copy in a separate location or service, and periodically confirm that files can still be opened. Keep access permissions and recovery details available to authorized stewards, without putting passwords in the archive inventory. If the team cannot maintain a complex system, a simpler documented process is more sustainable.
For physical documents, label folders and boxes with the same project, date range, and identifier used in the inventory. Use materials and handling practices suited to the items. Follow manufacturer instructions for any storage equipment or media, and seek archival guidance for fragile, unusual, or high-risk materials rather than improvising treatments.
7. Review the system and fix common problems
Ask a volunteer who did not organize the files to find a few representative items using only the folder structure, labels, and inventory. If they cannot tell which file is current, what an item relates to, or whether it can be shared, improve the labels or notes. This is a practical review, not a guarantee that the archive is complete or secure.
Common problems and remedies include:
- Several files called “final”: Add version numbers or a documented approval status, and record which copy supersedes another.
- Dates do not sort correctly: Use a consistent year-month-day format where the full date is known. Do not invent missing date parts.
- Acronyms are unclear: Spell them out in the inventory or a short glossary; keep familiar project abbreviations consistent.
- Duplicate files appear: Compare names, contents, and context before removing anything. Identical-looking files can belong to different records or have different permissions.
- A label exposes private details: Rename the file with a neutral description and review the content and access controls separately.
- Files are missing context: Add a note with the known source and uncertainty, and ask people familiar with the work if they can supply context without pressuring them to disclose personal information.
- Different volunteers use different patterns: Keep a one-page naming guide near the inventory and apply it to new additions. Correct older labels gradually, preserving original names in the catalog when useful.
8. A repeatable handoff for future volunteers
Write a short handoff note that states the archive’s date coverage, folder logic, filename pattern, access categories, and the person or role responsible for updates. Include where the inventory lives and how to request access. Do not put credentials or sensitive personal details in the handoff document.
When a new activity ends, set aside time to select records, apply labels, add descriptions, check access, and update the inventory before volunteers disperse. Record who made any significant change and when. This small routine keeps the archive understandable as people and project priorities change, while leaving future stewards room to revise the system when the collection grows.