open-civic-signal-os

Open Civic Signal OS is a civic-technology platform delivered as a monorepo. Its stated purpose is to convert community signals — repeated local problems reported by residents — into a public backlog that people can understand, trust and act on. The product promise is described from two angles. For a citizen, the path is: report a real local problem in plain language, see why it was prioritized, and follow what changed, who responded and what is still pending. For public servants and community leaders, the stated goal is to reduce noise, surface what matters first and keep the evidence behind prioritization visible. Documented user journeys cover three roles: - Community member: report a problem, support an existing issue instead of duplicating it, understand why an issue is high priority, and track updates from the community or an institution. - Community moderator or coordinator: review community conversations, publish progress updates with clear role boundaries, and keep discussion channels usable and auditable. - Public servant: identify the highest-priority problems quickly, publish progress updates, and use transparent evidence to justify the ordering of actions. The README is candid about a current UX gap: the repository and application explain the technical platform well, but expose too many navigation and workflow choices too early for first-time users. Ongoing frontend work is therefore focused on simplifying the first-run experience, clarifying primary actions and reducing cognitive load. The stated product direction includes a simpler first-screen hierarchy, clearer primary calls to action, lower-friction onboarding and verification, accessible keyboard and mobile navigation, and trust surfaces that explain ranking and progress without jargon. Technical stack as documented: - Backend: Java 21 with Spring Boot, in apps/api-java, hosting the API and prioritization services. - Frontend: React, TypeScript and Vite, in apps/web-react, providing the public dashboard and an operator console. - Data: JSON-first for the current MVP, with PostgreSQL listed as planned. - Contracts: OpenAPI definitions and shared schemas under packages/contracts. - Other directories: infra for local environment and deployment assets, and docs for strategy, ideas, architecture and execution plans. Running the project: the canonical integrated development runtime is Docker, started with npm run docker:dev:up, which the README describes as the required hot-reload path for frontend and backend together. Supporting commands include docker:dev:doctor, docker:dev:ps, docker:dev:logs and docker:dev:down, plus a production-like mode (docker:prod:up) and prebuilt GHCR images (docker:ghcr:up / docker:ghcr:down) with a CI image workflow in .github/workflows/docker-images.yml. The README explicitly asks that Docker unavailability be treated as a local environment blocker rather than being worked around, when validating integrated behavior. For the current MVP there are also scripts such as npm install and npm run prioritize. Component-only fallback paths exist for isolated work: running the React app with npm run dev inside apps/web-react, and the Java API with ./mvnw spring-boot:run inside apps/api-java. Additional repository material includes launch resources (demo and architecture GIFs, an architecture SVG, a landing page under docs, an ideas document and an agent playbook), a brand and visual asset kit (logo mark, wordmark, banner, social card and PNG logo), and roadmap tracking via the project's GitHub issues. Overall, the repository is an early-stage, openly documented civic engagement and prioritization platform: it defines the intended citizen and administrator journeys, ships a Docker-based monorepo development flow with Spring Boot and React components, keeps API contracts in-repo, and openly lists its remaining UX simplification work.