Sharing project data so the next team can use it

A spreadsheet can contain months of valuable work and still be difficult to reuse. Column names may be unclear, units may be missing and the person who remembers the context may have moved on. Sharing a file is only the first step. Sharing usable knowledge means giving the next team enough information to judge what the file means and whether they may use it.

Start with a specific future reader. A project teammate, a partner researcher and a public visitor may need different versions of the same material. Do not make a private dataset public simply because someone asks for an easy download link. The useful question is how to make the right information accessible to the right people.

Record where the information came from

Write a short readme that identifies the dataset, the purpose of collection, the place or system covered and the relevant dates. Say who or which organization maintains it. Explain whether the data were observed, estimated, reported by another source or calculated from existing records.

Keep a record of transformations. If you removed duplicates, converted units or combined tables, describe the rules. The original source and the cleaned version should be distinguishable. Do not silently replace a missing value with zero or change an estimate into an observation during cleanup.

The FAIR principles call for information to be findable, accessible, interoperable and reusable, including provenance and clear usage conditions. They explicitly allow access procedures that use authentication and authorization. FAIR does not mean every dataset must be open to everyone. Read the principles.

Decide the audience before preparing the release

List who needs the data and for what purpose. A team may need detailed work records, while a public resource may need only a summary. Check the permissions attached to source material and the conditions under which information was collected. Permission to hold a file does not automatically include permission to publish it.

Remove unnecessary personal details from the release copy. Names, phone numbers, private messages and precise locations can create risks when combined with other information. An apparently anonymous row can still reveal someone in a small group. Where the assessment is uncertain, ask the responsible privacy or safeguarding reviewer before sharing.

A restricted audience is not a failure. A public description can explain that a resource exists and how an eligible reader may request access, provided even that description is safe to publish. Keep the access decision separate from the question of whether the data are technically well organized.

Explain the structure in ordinary language

Create a data dictionary. For each field, record its meaning, unit, allowed values and the meaning of a blank entry. Include how dates and time zones are represented. If an identifier points to another table, explain the relationship without exposing a private account identifier unnecessarily.

An illustrative equipment inventory might include an internal asset reference, equipment category, inspection date, observed condition and source record. It should explain who assessed the condition and what each category means. A word such as “good” is not a professional safety certification, and the dictionary should not imply otherwise.

Choose formats the intended readers can open. A simple table may be useful as CSV together with a readme, while a drawing may need both an editable source and a viewable export. Preserve characters and units when exporting, and check the result in another application. A convenient format is only useful if it preserves the meaning.

Make a small quality check repeatable

Check a sample against the source. Look for impossible dates, duplicated identifiers, inconsistent units and unexplained gaps. Record what you checked and the limitations that remain. A quality note helps a reader decide whether the data fit their question; it does not have to claim perfection.

Use a second reader where practical. Ask them to answer one simple question from the package without help from its creator. If they cannot tell which version to use or what a field means, improve the documentation before adding more data.

Do not infer a broad conclusion from a dataset collected for a narrow purpose. A maintenance log may help schedule repairs but may not represent all equipment in a region. The readme should state the coverage and any known sampling limitations.

Give each release a stable identity

Use a clear version and release date, and describe what changed. Keep references to earlier releases when they remain relevant. A filename such as “final-final-new” does not tell a collaborator whether a correction affects their analysis.

Assign an owner for corrections, access requests and retirement. Explain what should happen when permission changes or an error is found. A revoked resource should stop being distributed through the controlled service, but previously downloaded copies may require separate communication and handling. Do not promise technical recall of every copy.

Engineer Africa's knowledge workflow separates submission, review and audience access. Submit the source, permissions and context with the resource so an authorized reviewer can consider the intended audience. Publication approval is not a guarantee that every future use is appropriate.

Leave the next team a usable starting point

A complete handover can be small: the data, a readme, a dictionary, a change log and clear usage conditions. Together they allow someone to understand what they have before acting on it. That is how a project record becomes shared knowledge rather than another unexplained attachment.