Project Resources

This page is primarily a resource for project leads, though in the spirit of open source it is open to the whole community.

Functionality of the Project

Organization is fundamental. Without it, good intentions and talented contributors get lost. This section includes the basics every project should have in place and other tools you can explore as your project grows.

Basics

You should have an active Read.Me on Slack. Some things to include on it are a project description, the current status of the project, links to relevant resources (GitHub, docs, design files), and how someone can get involved today.
You should have a sense of roles and responsibilities so people can more easily pick them up. When people know what’s available and what’s expected, they’re more likely to commit. This can live on a project board in Slack where it’s visible and easy to update as the project evolves.
You should have some cadence of meetings. This can just be the regular Project Nights or it can be occasional virtual meetings. The key is that contributors know when and where the project comes alive so they can plan around it.
You should keep a running meeting notes list to stay effective and know what is going on. Even brief bullet points after each session — decisions made, blockers raised, next steps assigned — prevent work from being repeated and help new contributors get up to speed quickly.

External Resources for Project Management

Plane — Open-source project management that combines issues, cycles, modules, and docs in one place. A self-hostable alternative to Linear or Jira.

Baserow — Open-source no-code database platform for building internal tools and managing structured data. A self-hostable alternative to Airtable, built with compliance and data sovereignty in mind.

NocoDB — Turns any database into a collaborative spreadsheet interface. Connect your existing Postgres, MySQL, or SQLite database and work with it without writing a query.

Taiga — Open-source agile project management for cross-functional teams. Supports Scrum and Kanban out of the box with a clean, low-friction interface.

Hosting at Project Night

Project Night is your most reliable recurring opportunity to move the work forward and bring new people in. Here are some tips for making the most of it.

Project Pitch

This is the best time to share about your project. There is a room full of people who care about civic tech and are actively looking for something to contribute to.

Please keep it to 30 seconds or a minute. The longer you take, the less time you have for the actual project work. A tight pitch also signals that you respect everyone’s time, which earns goodwill. Practice saying it out loud before the event so it feels natural.

Update the master slides frequently so the information is current. Here is the link.

Establishing a Rhythm

It is up to you how you structure your project nights. Some project leads jump right into the tasks, and when new members join after new member orientation, they move into introductions then. Others use the first few minutes for a quick standup — what got done since last time, what’s happening tonight, where help is needed.

Some project nights do not do any new member orientation due to time constraints. In those cases, it is recommended to have a one-pager that new members can look at to get onboarded on their own. However, there should be some acknowledgment of new members that involves the entire team — even a brief “welcome, glad you’re here” from the group goes a long way — or a follow-up directly afterwards.

Don’t dominate the conversation during project nights. It’s good to let other people lead and talk about what they are working on. Contributors feel more invested when they have space to share progress, raise questions, and own parts of the conversation. Your job as project lead is to facilitate, not to fill every silence.

Next Steps

New member enthusiasm wanes quickly after a meeting, so make sure to check in with them and write a welcome message in Slack within 24 hours of the event. Reference something specific from the conversation — what they said they were interested in, what issue they were going to look at — so it feels personal rather than automated. This small step significantly improves the chances they come back.

How to Build Community

Civic Tech DC projects thrive because of volunteer contributors — developers, designers, researchers, policy analysts, and engaged residents. Building a healthy community means making it easy for people to show up, find meaningful work, and feel like their contribution matters.

Supporting new contributors

Start by lowering the barrier to entry. Have a one-pager available that explains the project’s purpose and how to get set up locally. This should be something someone can read in five minutes and walk away from knowing what the project is, why it matters, and what they can do today.
Mark beginner-friendly topics as good first issue. These should be real, self-contained tasks — not busywork — that give a new contributor a genuine win and a feel for how the project operates.
Make sure to have an onboarding process, whether that’s a walkthrough during Project Nights, a one-pager checklist of tasks, or a personal onboarding session for contributors who want to go deeper. A clear path in prevents the drop-off that happens when someone is interested but doesn’t know where to start.
As a project lead, it is also expected that you can’t give all of your time to new contributors. If they request extra time that you can’t commit to, be gentle with them. Point them to documentation, connect them with another team member who can help, and let them know you appreciate their enthusiasm. Honesty about your capacity is better than overpromising.
Respond to first pull requests and issues within 48 hours. A quick acknowledgment goes a long way toward turning a one-time visitor into a regular contributor. Even “I’ll review this by end of week” is better than silence.

Recognizing strengths

Civic tech projects attract a wide range of people. Ask what someone wants to do, not just what their resume says. A policy analyst might want to try their hand at data wrangling; a developer might want to write documentation.

Create roles that match people’s goals, not just their credentials. Have them visible on a Slack board so anyone can see what’s available and self-select into work that fits them. Named roles — even informal ones like “data lead” or “community liaison” — give people something to grow into.
Public recognition signals that people’s time is valued and encourages others to step up:
- Have a contributor give the project pitch at Project Nights. It is a good way for them to practice their public speaking skills and succinctly deliver a quick pitch — and it visibly signals that leadership isn’t concentrated in one person.
- Give a thank-you in the project’s Slack channel when someone ships something, joins a call, or helps onboard a new member. Specific recognition (“thanks to Maya for cleaning up that data pipeline”) lands better than generic praise.
- Allow people to take “ownership” of part of the project. When someone feels responsible for a feature, a dataset, or a relationship with a partner, they show up differently. Ownership builds accountability without hierarchy.

Grow Awareness of Your Project

A great project that nobody knows about won’t get used or contributed to. Visibility isn’t self-promotion — it’s part of the work. The people your project is meant to serve need to know it exists, and potential contributors need to be able to find it.

What is your Mission Statement?

Write a clear, jargon-free one-paragraph description of what your project does and who it helps. This becomes your pitch at Project Nights, your README opener, and your Slack intro. Make sure it answers: what problem does this solve, for whom, and what stage is it at?

A strong mission statement also helps you stay focused. When scope creep or competing priorities arise, it’s the thing you return to. If a new feature or partnership doesn’t serve the mission, that’s useful information.

Host your own Activities

You are welcomed to host whatever type of events will help your project grow. This usually involves partnering with another organization for a demo or lightning talk — a low-lift way to get your project in front of an audience that’s already assembled and relevant.

Civic Tech DC can also help you organize a dedicated working session, a public demo, or a user research workshop around your project. Please fill out this Google Form for the organizers with a brief description of what you’re trying to accomplish and roughly how many people you’d expect. Good formats that have worked for DC projects include:

Demo nights — show what you’ve built to get feedback and attract new contributors
Working sessions — focused Project Night spin-offs where a small group tackles a specific problem
User research meetups — invite the people your project serves to test it and share their experience
Co-working with a government partner — if your project supports a DC agency or civic organization, coordinate a joint session with their staff

Visual Communications

You are welcomed to use Civic Tech DC’s LinkedIn to help spread the word. LinkedIn is where much of DC’s civic, government, and tech professional community is active — a well-timed post about a milestone, a new partnership, or an open contributor role can reach people who wouldn’t otherwise find you through Slack or GitHub.

Please create a post in Canva, write a short description, and fill out this form. The organizers will review and schedule it.

Create a Logo

A logo gives your project a recognizable identity and makes it easier to share across platforms consistently. Canva has free templates that are a good starting point — aim for something simple that works at small sizes (like a Slack avatar) and large ones (like a slide header).

Create a Website

A project website gives you a home that you own and control, somewhere to send partners and potential contributors that feels more permanent than a Slack channel or GitHub repo. AI tools can help you get a first version up quickly, though adding some personality beyond the generated defaults goes a long way.

Astro is a good option for civic tech projects — it’s free, open source, and well-suited to content-focused sites without requiring a lot of frontend experience.

Have a Pitch Deck

A pitch deck gives you something polished to share when presenting at events, reaching out to partners, or onboarding new contributors who want the full picture. Use Google Slides so it’s easy for teammates to collaborate and update. Some slides worth including:

What the project is and the problem it solves
Who it’s for and who’s affected
Where the project stands today
How someone can get involved
Who’s currently on the team

Encourage Others to Talk About It

Your team members are your best advocates. Make it easy for them by giving them a short, consistent way to describe the project, a sentence or two they can use at networking events, on LinkedIn, or when someone asks what they’ve been working on. Share it in Slack and encourage the team to make it their own.

Maintenance of the Project

Projects outlast their founders. Planning for longevity from the start saves future maintainers enormous pain and prevents good work from going dark. A project that ends because no one documented how it works is a project that didn’t fully deliver on its potential.

Handoff Plan

Sometimes you have other responsibilities — a new job, a move, a shift in priorities. A good handoff plan documents:

Who owns the project after incubation ends — name a person or team, not just an org. Include their contact info and confirm they’ve agreed to the responsibility. An owner who doesn’t know they’re the owner is no owner at all.
How to deploy, update, and roll back the application — step-by-step, written for someone who wasn’t in the original build. Assume no context. If it takes a specific version of a tool, a particular environment variable, or a manual step that isn’t obvious, write it down.
Where credentials and access controls live — use a shared password manager (e.g. 1Password, Bitwarden) or document the process for transferring access. Never leave credentials in a private inbox. When a project lead moves on, access shouldn’t move with them.
Maintenance tasks and frequency — dependency updates, data refreshes, certificate renewals, uptime monitoring. Note what’s automated and what’s manual. Future maintainers shouldn’t have to reverse-engineer a cron job to understand what the project needs to stay alive.
Who to contact if something breaks — include the hosting provider, any government data partners, and anyone with institutional knowledge of edge cases. A phone tree for your project is not overkill.

A handoff document doesn’t need to be long — a well-maintained README plus a short runbook covers most projects. The goal is that a new volunteer can pick this up six months from now without needing to track you down.