New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
Community work can look informal from outside while relying on a dense web of recurring tasks. Someone prepares an agenda, checks a venue, answers a newcomer, updates an event record and remembers which announcement still needs review. CryptoCrowd’s recovered community-manager vacancy described several such responsibilities in 2017. It is a historical document, not a current job offer. This new guide uses the underlying coordination problem to examine handover design. The goal is not to prescribe a modern staffing structure for the original organisation. It is to show how any small technical community can document a limited role so that another person can understand the work, its authority and its unfinished decisions.
Describe outcomes before listing tools
A handover that begins with a dozen application names can leave the incoming volunteer unsure what they are supposed to accomplish. Begin with the role’s outcomes: keep public event information accurate, route technical questions to the right place, preserve meeting notes or prepare an announcement for review. Then connect each outcome to its recurring tasks and supporting tools. This makes the document useful even when a platform changes. The person can see which function needs replacement instead of assuming that access to the old application is the purpose of the role.
Keep the scope realistic. Organise the community is not a bounded responsibility. Maintain the draft agenda and flag unresolved speaker confirmations is much easier to understand. Record what the role does not decide, especially where another person controls publication, spending or membership changes. A clear boundary does not make the role less valuable. It prevents ordinary coordination from becoming an accidental grant of authority over everything that happens to pass through the volunteer’s inbox. The incoming person should not have to infer their powers from which buttons a platform happens to expose.
Separate routine work from exceptional decisions
Write the normal sequence for a recurring task, then add the exceptions that require a different decision. Updating a confirmed event time is different from announcing an unconfirmed venue. Correcting a broken link is different from changing the substance of a technical claim. A useful handover identifies the decision point, the information needed and the person or process responsible for resolving it. This gives the incoming volunteer a practical map of when to proceed and when a task is not yet ready for the next step.
Avoid replacing judgment with an enormous checklist of imagined edge cases. Start with the exceptions that have actually mattered or that directly follow from the role’s authority boundaries. For each one, explain the reason for the rule. A short rationale helps the next person apply it when circumstances differ slightly. Without that context, a handover can become a ritual: people follow steps that no longer serve the intended outcome while missing a new situation that presents the same underlying coordination problem.
Keep public instructions and private access apart
A community can publish participation guidelines, contribution routes and issue templates without publishing administrative credentials. The handover should separate those categories explicitly. GitHub’s community-health documentation illustrates how a project can make shared guidance available through recognised files. That is one platform-specific mechanism, not a requirement to move every community onto GitHub. The general principle is that ordinary contributors should be able to discover how to participate without needing access to the private administrative record used to operate the project.
For the role itself, record which systems are needed, what level of access is appropriate and who controls the established access process. Do not place secrets in the handover document. Do not treat forwarding an old account or leaving a shared session open as a complete transfer of responsibility. The document should describe the intended arrangement and the checks that confirm the incoming person can perform the limited tasks. A role is not successfully handed over merely because someone can see the same dashboard the previous volunteer used.
Record the decisions still in flight
The most important part of a handover may be the unfinished work. List each open decision with its current status, known constraints, next step and source of truth. Awaiting venue confirmation is more informative than Event pending. A promise made in a private conversation should not become a public fact until it reaches the agreed confirmation process. The incoming volunteer needs enough context to avoid either repeating work or treating a tentative suggestion as a settled commitment that the community must now fulfil.
Distinguish tasks from assumptions. A task has an action to perform; an assumption is something currently believed about the situation. If a plan depends on an assumption, show that dependency. For example, a draft announcement may assume that a recording will be available, while the actual recording arrangement remains unresolved. Keeping these categories separate makes the work easier to update. When an assumption changes, the volunteer can identify the affected draft rather than discovering the contradiction after publication. This is a small documentation habit with a substantial effect on continuity.
Run the role once with the document
A handover document should be tested through one real or carefully bounded rehearsal. Ask the incoming volunteer to complete a representative task using the document and the access they are supposed to have. Observe where they need an explanation that exists only in the outgoing person’s memory. Add that missing context. The test is not a performance assessment of the volunteer. It is a test of whether the documented role is understandable and whether its tools and authority are aligned with the work it requires.
Include an exception in the rehearsal. A straightforward update may conceal the absence of a review route or the ambiguity of a status label. Ask what happens if a speaker cancels, a claim is disputed or the public page contradicts a planning document. The answer should identify a process and a record, not simply say that the experienced organiser will know what to do. A role that only works while its previous holder remains constantly available has not yet been transferred in a durable way.
Make maintenance part of the role
The handover is not a final monument to how the community once worked. Give it a review date and a simple way to record changes. Remove obsolete steps deliberately, while retaining context where an old decision may still matter. The current instructions should be easy to find, and historical versions should not be mistaken for active policy. This is the same date discipline used for archived event invitations and old vacancies: preservation and current operation are different purposes, and readers should not have to guess which one a document serves.
A durable role therefore has a clear outcome, a bounded authority, a routine sequence, an exception route and a visible list of unfinished decisions. The tools support that structure; they do not replace it. CryptoCrowd’s historical vacancy is useful because it reveals how much connective work sits behind a community portal. This new guide treats that work as something worth documenting well. When the next volunteer arrives, they should inherit an understandable practice rather than a collection of accounts and the expectation that they will somehow reconstruct everything else.
Technical references
From the recovered archive
- Community Manager @ CryptoCrowd · captured 20 December 2018
- Jobs Archives · captured 23 August 2019