Austin.gov

The City of Austin's Office of Design and Delivery is in the process of rebuilding the City’s website to improve delivery of our services to Austin residents. The new site, Austin.gov, is an evolving platform that will grow, adapt, and improve with user needs.

This repo is used for centralized project management of the project for the following teams:

• Content
• Design + Research
• Dev
• Product

This includes work related to:

• Janis - Austin.gov's resident-facing interface for service delivery
• Joplin - Austin.gov's staff-facing interface for content creation and maintenance
• Animal Services Foster Form Prototype
• Forms Service API - API to connect the US Forms System to external applications and services
• Forms Service Deploy -  Tool to deploy forms using shared components
• Form Large File Upload - Large file uploader for the Form Service API
• USFS Components - Custom components for the US Forms System
• USFS Schema blocks - Sets of commonly used questions for the US Forms System
• Office of Police Oversight: Complaint Form, Praise Form, Form Chapters

  ZenHub

  Our team is using Zenhub for agile project management. In order to view our Kanban board (aka Trello-style), you need to download the Zenhub extension for your browser. See our guide to how we use Zenhub here.

Roadmap

We use roadmunk as a project roadmap: https://app.roadmunk.com

Adding an issue

There are several issue templates available to start with:

• Bug report
• Feature request
• Meeting

If none of these suit your needs, create a regular issue and we'll sort it out.

Grooming

In preparation for every Sprint Planning, the backlog of issues needs to be groomed. Issues that are likely to be pulled into one of the next few sprints should have

• One Team label - there should be separate issues assigned to each team that speak specifically to the work they will do, e.g. "Design Service Page contact component" for design and "Implement Service Page contact component" for dev, rather than "Service Page contact component" assigned to both disciplines. The exception to this rule is a meeting where both teams will contribute the same amount of time/effort. In this case, assign all teams and the Meeting label.
• At least one Feature or Content Type label - unless it is Site Content (content to be transitioned onto Austin.gov) or Project Communication (Medium posts, conference presentations, etc.)
• One Size label - relative estimation of effort
• An estimate - in order to calculate velocity; estimates translate directly from t-shirt size: XS=1, S=2, M=3, L=5, XL=8

If completion of an issue is blocked by another issue, add a dependency:

If the blocking issue isn't in Github yet, create it and make sure to add the appropriate Team label and then add the dependency.

Logging notable changes

We're going to adopt changelogs for projects that have passed major releases, in order to help track notable changes for clients and other interested parties. Roughly following this format: https://keepachangelog.com/en/0.3.0/ Checkout the changelogs folder for more!

How do I make a good changelog?

Guiding Principles:

• Changelogs are for humans, not machines.
• There should be an entry for every single version.
• The same types of changes should be grouped.
• Versions and sections should be linkable.
• The latest version comes first.
• The release date of each version is displayed.
• Mention whether you follow Semantic Versioning.

Types of changes:

• Added for new features.
• Changed for changes in existing functionality.
• Deprecated for soon-to-be removed features.
• Removed for now removed features.
• Fixed for any bug fixes.
• Security in case of vulnerabilities.