Transparency by default: a project-management lens on community organizing

Before I built Revel Sphere I spent a lot of years running projects. Different industries, different stakes, same lesson over and over: when people can see what is actually happening, things move. When they can’t, things stall — even when everyone is doing the work. The work disappears into private inboxes, group texts, and one-on-one updates that never roll up.

That lesson follows me into community organizing. The cost of opacity in volunteer work is even higher than in product teams, because volunteers don’t have to come back. They’re not on payroll. The thing that earns a second visit is trust — and trust runs on visibility.

The volunteer-hour example

Here’s a small case that is bigger than it looks. A volunteer shows up on Saturday, works for four hours, leaves. The coordinator scribbles their name on a clipboard. Three months later, the hours get typed up into a record somewhere. Six months later, that record is asked for in a grant report. Numbers are reconciled. By the time the volunteer hears anything back about their hours — if they ever do — the connection between the showing-up and the counting is gone.

In Revel Sphere, when a volunteer checks in at an event, the hour logs to their profile in real time. They can see it. The sphere’s impact roll-up shows it. The grant report pulls from the same data. There is no opaque step in between. Nobody wonders if their hours got counted. Nobody is incentivized to skip checking in because "it doesn’t matter anyway."

That sounds like a feature. It’s actually a design value: the count belongs to the person doing the work. Build it that way and the count gets trusted. The trust is what gets the volunteer back next month.

What we chose to make visible by default

• Sphere activity to members. Posts, replies, events, decisions — anyone in the sphere sees the same context. New members don’t need a back-channel briefing.
• Volunteer hours to the volunteer. Every check-in shows up on the volunteer’s profile immediately. Their record, their decision what to share with whom.
• Sphere impact totals to members. "We’ve run 14 events, logged 312 hours, fed 87 families this quarter." Built into the sphere — not a separate report you have to ask the coordinator for.
• Who organized what. Events show their organizer. Posts show their author. Credit goes to the person who did the work — and accountability goes to the person making the decision.
• Meeting notes inside the sphere. Decisions made in a meeting don’t live only in the head of whoever was there.

What we chose to keep private — on purpose

Transparency is a value. It is not a license to overshare. There’s a real harm in publishing things that should stay quiet, and I want to be specific about where we drew that line.

• Personal contact info. Member profiles do not expose phone numbers or emails by default. Organizers can message inside the platform; nobody is harvesting your inbox.
• Whether you joined a sphere. No public notification when you join. No "Jaime joined the Tenants Union" event in your feed. Joining is a private decision; lurking is allowed.
• Mutual aid recipient information. When a sphere is supporting people who need help, the people receiving help are not identified publicly. Ever. That category of data is treated as sensitive by design.
• What you log on your own profile. Your hours and impact history are yours. You decide whether to share them with a scholarship committee, a grant officer, an employer, or no one.
• Private spheres. Some work has to happen behind a closed door — internal nonprofit ops, sensitive advocacy, board discussions. Those spheres exist and are private to their members.

Why this matters more in volunteering than in product

In a salaried product team, opaque coordination is annoying. People still show up Monday because they have to. In volunteer work, opaque coordination is fatal. The volunteer who feels invisible — whose hours never got counted, whose suggestion went into a coordinator’s notebook and never came back, whose name got misspelled in the recap email — that volunteer just doesn’t come back. There’s no exit interview. They just stop.

The whole platform is shaped by trying not to lose that volunteer. Transparency is the first lever — making the work visible, making the credit visible, making the count honest. (The full version of that argument is in Built for volunteers first.)

Transparency is a stance, not a setting

I’m wary of platforms that ship a hundred toggles and call that transparency. The defaults are what people actually live in. So we picked defaults that lean toward shared visibility for the work, and toward privacy for the person — and we live with the harder choice of saying no to features that would erode either side.

That’s the project-management lens applied to community organizing: design the defaults like they’re a value statement, because they are.