> For the complete documentation index, see [llms.txt](https://docs.seegov.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.seegov.org/guidance/meeting-report-guidance.md). # Meeting Report Guidance Our mission is to expand thoughtful and consistent participation in democracy. Meeting reports can help by giving people an accessible, engaging overview of local government in action. SeeGov can also be used for opinionated content or a report focused on one topic. This guidance is for a more complete, balanced meeting report. ## General approach Rather than creating verbatim minutes, aim to: * capture the meeting's main actions; * help residents get to know their elected leaders and how they make decisions; * show public participation and the range of perspectives; and * explain issues that matter to the community. A report will often work best at 5 to 15 minutes. A meeting longer than three hours, an unusually important issue, many distinct speakers, or many important topics may justify more. As a general goal, keep the report under 10% of the original meeting's duration. ## Select useful clips * Choose moments that clearly illustrate major issues, critical decisions, and noteworthy statements. * Clarify elected officials' positions and the factors they considered. * Include public comments that address agenda items or are likely to resonate broadly. * Include announcements and ceremonial items when they have broad relevance or reveal community values. * Speakers often summarize their main point near the beginning or end. Those summaries can make stronger, clearer clips. * Capture disagreements, emotion, and passionate exchanges without making them more sensational than the meeting itself. * When many speakers make the same point, avoid repetitive clips. Use an introduction to describe the volume or pattern of comments. ## Keep the coverage balanced * Include the range of elected officials' voices. Do not let speaking length alone determine who dominates the report. * Include meaningfully different community perspectives when they were part of the meeting. * Use procedural material when it affects an outcome or helps viewers understand how the decision was made. Balance does not require giving every claim equal weight. Verify facts, identify relevant uncertainty, and use your editorial judgment. ## Add context without getting in the way * Give brief background for a new topic, especially when an earlier government action matters. * Explain unfamiliar terms or roles. * Identify a speaker when the selected video does not make the person's role clear. * Connect moments or fill a gap when a skipped section is needed to understand the result. * Do not repeat what the selected clip already says. * Not every moment needs an introduction. * A brief preview can build interest, but avoid revealing every outcome before the viewer sees how the decision unfolds. ## Tone and style Use plain, conversational language. Be friendly and informative without smoothing away real disagreement or complexity. For a meeting report, let the material speak while providing the context a resident needs to follow it. ## Review checklist * Does the report show how decisions were made, how the public participated, and what mattered to the community? * Are the most important topics and statements included? * Are distinct perspectives represented without unnecessary repetition? * Do procedural details earn their place by explaining an outcome or decision? * Does each introduction add context rather than repeat the clip? * Are names, dates, vote outcomes, and factual claims verified? * Is the language clear and balanced? * Does the order help a viewer understand how the meeting unfolded? * Is the final length appropriate—usually 5 to 15 minutes and under 10% of the meeting? This is a living guide. Tell Alex what works in practice and what should change at . --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.seegov.org/guidance/meeting-report-guidance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.