CiviForm Docs
HomeAboutContactNewsFAQ
  • CiviForm Docs
  • Overview
    • What is CiviForm?
    • How does CiviForm work?
    • Glossary
  • User Manual
    • CiviForm Admin Guide
      • CiviForm Admin training overview
      • How to navigate CiviForm
      • Working with programs
        • Create a program
        • Edit a program
        • Show or hide questions based on inputs
        • Manage program eligibility
        • Manage address & service area validation
        • Manage notifications
        • How to publish programs
        • Set a pre-screener
      • Working with questions
        • Manage questions
        • Question export settings
        • Universal and Primary Applicant Information questions
        • Using enumerator questions & screens in a program
      • Manage translations for programs & questions
      • Manage versions for programs & questions
      • Working with applications
        • Add statuses to a program
        • Download exported data
      • Role management
        • Manage Program Admins
        • Manage Trusted Intermediaries
      • Manage API keys
      • Using Markdown
      • Migrating programs between environments
    • Program Admin Guide
      • How to become a Program Admin
      • Review completed applications
    • Trusted Intermediary Guide
      • Apply to a program
    • Onboarding Guide
      • Organization assessment
      • Program assessment
      • Getting started with service design
      • Journey mapping
      • Discovery, eligibility, and intake
      • Consolidating questions across programs
      • Working with existing tools and processes
      • Working across jurisdictions
      • Data reporting and other integrations
      • Security and privacy considerations
      • Staffing overview
  • IT Manual
    • Technical Deployment Guide
      • Initial Deployment
        • Terraform deploy system
          • AWS Terraform deployment
        • Authentication setup
        • Email configuration
        • GIS Service configuration
      • Upgrading to a New Release
        • CiviForm server environment variables
          • v1.20.0
          • v1.20.1
          • v1.21.0
          • v1.22.0
          • v1.23.0
          • v1.23.1
          • v1.24.0
          • v1.24.1
          • v1.24.2
          • v1.25.0
          • v1.26.0
          • v1.27.0
          • v1.28.0
          • v1.29.0
          • v1.30.0
          • v1.30.1
          • v1.31.0
          • v1.33.0
          • v1.34.0
          • v1.34.1
          • v1.34.2
          • v1.35.0
          • v1.36.0
          • v1.37.0
          • v1.38.0
          • v1.38.1
          • v1.38.2
          • v1.39.0
          • v1.40.0
          • v1.41.0
          • v1.42.0
          • v1.43.0
          • v1.44.0
          • v1.45.0
          • v1.46.0
          • v1.47.0
          • v1.48.0
          • v1.49.0
          • v1.50.0
          • v1.51.0
          • v1.52.0
          • v1.53.0
          • v1.54.0
          • v1.55.0
          • v1.56.0
          • v1.56.1
          • v1.57.0
          • v1.58.0
          • v1.59.0
          • v1.60.0
          • v1.61.0
          • v1.62.0
          • v1.63.0
          • v2.0.0
          • v2.0.1
          • v2.0.2
          • v2.1.0
          • v2.10.0
          • v2.11.0
          • v2.12.0
          • v2.13.0
          • v2.14.0
          • v2.15.0
          • v2.16.0
          • v2.17.0
          • v2.18.0
          • v2.19.0
          • v2.2.0
          • v2.20.0
          • v2.21.0
          • v2.22.0
          • v2.23.0
          • v2.24.0
          • v2.25.0
          • v2.26.0
          • v2.27.0
          • v2.28.0
          • v2.29.0
          • v2.3.0
          • v2.30.0
          • v2.31.0
          • v2.32.0
          • v2.33.0
          • v2.34.0
          • v2.35.0
          • v2.36.0
          • v2.37.0
          • v2.38.0
          • v2.39.0
          • v2.4.0
          • v2.4.1
          • v2.4.2
          • v2.4.3
          • v2.5.0
          • v2.6.0
          • v2.7.0
          • v2.8.0
          • v2.9.0
      • Monitoring
      • Troubleshooting Production
      • Disaster Recovery
      • Database Disaster Recovery
      • Production Database Access
    • Infrastructure Requirements
    • Existing deployments
    • API Integration
      • Authentication
      • List applications
    • Testing & QA
      • Testing resources
      • SQL queries to look for missing questions
  • Governance & Management
    • Project Management
      • On Call Guide
    • Governance
      • Roles, Committees, & Responsibilities
      • Governance Processes
      • Development Principles
      • Communication
Powered by GitBook
On this page
  • Product Planning and Prioritization
  • Product Design Decisions
  • Technical Design Decisions
  • Technical Design Process

Was this helpful?

Edit on GitHub
Export as PDF
  1. Governance & Management
  2. Governance

Governance Processes

PreviousRoles, Committees, & ResponsibilitiesNextDevelopment Principles

Last updated 1 year ago

Was this helpful?

The following processes describe how project plans and decisions are made. The Stewarding Organization is responsible for facilitating these processes.

  • Product planning and prioritization

  • Product design decisions

  • Technical design decisions

Product Planning and Prioritization

Project-wide planning and prioritization is managed by the Product Design Committee and is dictated by the needs of Users and Member Organizations. Quarterly decisions are planned and prioritized as follows:

  1. Feature requests are submitted as .

    • Ideas and proposals for new features may initially be shared ad-hoc in meetings or via other communication channels, but a Maintainer from the Product Design Committee is responsible for consolidating them into the .

  2. Initial prioritization and consolidation against the current product roadmap is done weekly by the Product Design committee.

  3. Final prioritization is informed by feedback from key sources:

    • Member Organizations: Product needs and relative importance of features.

    • Governance Committee: Collective prioritization of features.

    • Technical Design Committee: Technical feasibility and level-of-effort of features.

    • Users: Detailed needs and requirements for a given feature.

    • Broader observed trends across the government and technical landscape.

    Mechanisms for feedback include:

    • Direct consultation with Member Organizations.

    • Discussion or polls via .

    • Demos, reviews, and discussions in .

    • Remaining ambiguities should be resolved by .

  4. Approval of product roadmap on a quarterly basis through simple majority vote by Member Organizations in the Governance Committee.

    RACI for Product Planning & Prioritization

    Committee
    Initial Prioritization
    Final Prioritization
    Approval

    Governance

    Informed

    Consulted

    Accountable

    Product Design

    Responsible

    Responsible

    Responsible

    Technical Design

    Informed

    Consulted

    Informed

Product Design Decisions

The design of major product features must be developed publicly and collaboratively across the project. The following process describes how new features should be designed, reviewed, and approved:

  1. Product Requirements Documents (PRDs) are developed and authored by members of the Product Design Committee. Initial authorship is informed by research among Users and Member Organizations.

  2. PRDs are reviewed for a period of up to X weeks by the Governance and Technical Design Committees.

  3. PRDs are approved by simple majority vote from Member Organizations in the Governance Committee.

    RACI for Product Design Decisions

    Committee
    Author PRDs
    Review
    Finalize
    Approve

    Governance

    Informed

    Responsible

    Consulted

    Accountable

    Product Design

    Responsible

    Responsible

    Responsible

    Responsible

    Technical Design

    Informed

    Responsible

    Consulted

    Informed

Technical Design Decisions

Major technical design decisions are reviewed and approved by a majority of the Technical Design Committee. The committee holds ad hoc forums for maintainers to advise contributors on technical decisions and will determine what constitutes a major technical design decision by majority vote if necessary.

Types of technical design decisions that require approval:

  • Authentication & authorization (e.g. User Account identification)

  • Technical aspects of new features (e.g. program discovery or automated eligibility screening system)

  • Major changes to existing features (e.g. Admin UX overhaul)

  • Major changes to technical approach (e.g. introducing a new library, tool, or major software design pattern)

  • How new infrastructure will connect with existing infrastructure (e.g. API design)

    RACI for Technical Design Decisions

    Committee
    Author TDDs
    Review
    Finalize
    Approve

    Governance

    Informed

    Consulted

    Consulted

    Informed

    Product Design

    Consulted

    Consulted

    Consulted

    Consulted

    Technical Design

    Responsible

    Responsible

    Responsible

    Accountable

Technical Design Process

This section outlines the process for features that require a technical design document. The purpose of a design document is to draft and approve major technical design decisions to ensure the quality, reliability, and maintainability of CiviForm for all its users.

Before You Start

The following should be true:

Two approvals are required to move forward with a design. At least one member of the Stewarding Organization should be assigned. From there, please assign available contributors who have domain expertise relevant to the issue.

Stewarding Organization members who are not also approvers and any available and interested contributor may be a reviewer on the document. Approval of reviewers is not required, however the design will benefit from constructive and critical feedback. To that end, aim for a sum total of five reviewers when possible, including approvers.

Working with the Doc

  1. Using the template, create a technical design document. Please remove any sections that aren't relevant and add any that may be missing.

  2. When your draft is ready for review:

    1. Update the status to IN REVIEW

    2. Notifiy the approvers and reviewers that the doc is ready for review.

  3. Approvers and reviewers will add comments and questions to start discussion

  4. Iterate on the design until you have approval

At this point the issue should be prioritized and implementation can begin according to its priority.

PRDs are finalized after incorporating feedback from reviewers. Finalized PRDs are saved in the Public Drive and added as links in the .

There is an open issue in

There is an approved PRD in the

If the issue has a UX label, approved UX Mocks are added to the

A Ready for TDD label is added to the issue and visible in

During the CiviForm engineering weekly meeting on Mondays, we review the issues with the Ready for TDD label and assign an author, approvers and reviewers. If an urgent issue arises that does require a TDD and we cannot wait until the next weekly meeting, assignment may be done during the week, either in a daily status meeting or by discussing in the .

Go to and take one of the "Copy of Design Doc Template" docs or make a copy of "Design Doc Template". Google employees using official Google email addresses aren't able to create or move docs. If you're a Google employee, you can either join the drive with a personal email or ask an Exygy employee to create a doc for you.

After Approval

🚀
product roadmap
new issues via GitHub
GitHub issue tracker
email lists and Slack
Governance Committee meetings
agreed-upon prioritization criteria
public product roadmap
GitHub
public folder
public folder
this list
engineering slack channel
this drive