diff --git a/.gitignore b/.gitignore index 03d592bb3..22bc4790d 100644 --- a/.gitignore +++ b/.gitignore @@ -1,3 +1,136 @@ # Files ignored because they're binary/unnecessary .DS_STORE -.idea \ No newline at end of file +.idea + +# Files generated by local Mermaid development +documentation/milestones/milestone_dependency_diagram.pdf + +# Byte-compiled / optimized / DLL files +__pycache__/ +*.py[cod] +*$py.class + +# C extensions +*.so + +# Distribution / packaging +.Python +build/ +develop-eggs/ +dist/ +downloads/ +eggs/ +.eggs/ +lib/ +lib64/ +parts/ +sdist/ +var/ +wheels/ +pip-wheel-metadata/ +share/python-wheels/ +*.egg-info/ +.installed.cfg +*.egg +MANIFEST + +# PyInstaller +# Usually these files are written by a python script from a template +# before PyInstaller builds the exe, so as to inject date/other infos into it. +*.manifest +*.spec + +# Installer logs +pip-log.txt +pip-delete-this-directory.txt + +# Unit test / coverage reports +htmlcov/ +.tox/ +.nox/ +.coverage +.coverage.* +.cache +nosetests.xml +coverage.xml +*.cover +*.py,cover +.hypothesis/ +.pytest_cache/ + +# Translations +*.mo +*.pot + +# Django stuff: +*.log +local_settings.py +db.sqlite3 +db.sqlite3-journal + +# Flask stuff: +instance/ +.webassets-cache + +# Scrapy stuff: +.scrapy + +# Sphinx documentation +docs/_build/ + +# PyBuilder +target/ + +# Jupyter Notebook +.ipynb_checkpoints + +# IPython +profile_default/ +ipython_config.py + +# pyenv +.python-version + +# pipenv +# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control. +# However, in case of collaboration, if having platform-specific dependencies or dependencies +# having no cross-platform support, pipenv may install dependencies that don't work, or not +# install all needed dependencies. +#Pipfile.lock + +# PEP 582; used by e.g. github.com/David-OConnor/pyflow +__pypackages__/ + +# Celery stuff +celerybeat-schedule +celerybeat.pid + +# SageMath parsed files +*.sage.py + +# Environments +.env +.venv +env/ +venv/ +ENV/ +env.bak/ +venv.bak/ + +# Spyder project settings +.spyderproject +.spyproject + +# Rope project settings +.ropeproject + +# mkdocs documentation +/site + +# mypy +.mypy_cache/ +.dmypy.json +dmypy.json + +# Pyre type checker +.pyre/ diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml new file mode 100644 index 000000000..0c8e71e48 --- /dev/null +++ b/.pre-commit-config.yaml @@ -0,0 +1,7 @@ +exclude: ^client|\.csv +repos: +- repo: https://github.com/pre-commit/pre-commit-hooks + rev: v4.3.0 + hooks: + - id: end-of-file-fixer + - id: trailing-whitespace diff --git a/README.md b/README.md index 8471a1a6c..081e9d6de 100644 --- a/README.md +++ b/README.md @@ -58,6 +58,23 @@ A modernization effort for Grants.gov. 1. Visit [localhost:9001](https://localhost:9001) to view the server --> +### Setting up development tools + +#### Configuring pre-commit hooks + +To promote consistent code style and quality, we use git pre-commit hooks to +automatically lint and reformat our code before every commit we make to the codebase. +Pre-commit hooks are defined in the file [`.pre-commit-config.yaml`](../.pre-commit-config.yaml). + +1. First, install [`pre-commit`](https://pre-commit.com/) globally: + + $ brew install pre-commit + +2. While in the root `grants-api` directory, run `pre-commit install` to install + the specific git hooks used in this repository. + +Now, any time you commit code to the repository, the hooks will run on all modified files automatically. If you wish, you can force a re-run on all files with `pre-commit run --all-files`. + ### Testing ## Contributing diff --git a/documentation/milestones/README.md b/documentation/milestones/README.md new file mode 100644 index 000000000..c5ff6d2ee --- /dev/null +++ b/documentation/milestones/README.md @@ -0,0 +1,22 @@ +# Introduction to this directory + +This directory contains information about our milestones for the modernization project. + +[The milestone short descriptions file](./milestone_short_descriptions.md) contains brief descriptions of upcoming milestones. They are grouped into sections. Within sections, they are roughly presented in approximate priority order, but not in firm priority order. + +The milestones are also graphed in the [dependency diagram](./external_milestone_dependency_diagram.mmd). This diagram is rendered using [Mermaid.js](https://mermaid.js.org/). + +Some milestones below have full definitions that are defined on standalone pages in the [individual_milestones](./individual_milesstones/) directory. These will have links underneath their name that take you to their full description on another page. + +Other milestones in the short descriptions page are not yet groomed and prepared enough to have milestone descriptions. These have short summaries underneath them. Eventually, when they are getting closer to starting execution, these short descriptions will be replaced by defining them according to the [Milestone Template](./external_milestone_template.md) and creating separate pages for their definitions. + +Please note that these are *not* fixed or final milestones. We fully expect they will evolve rapidly based on feedback from others and what we learn as we research, build, and test. All feedback on how these should be changed or adapted is very welcome! + +The HHS Grants.gov team is not committing to delivering on any, and certainly not all, of these milestones. These are provided as planning brainstorms rather than a fixed roadmap or promise of delivery of services. + +In a separate document, we will track ongoing priorities, clearly defining which milestones are currently being worked on and, for those that are currently being planned or worked, what their priority order is relative to each other. These ongoing priorities will be used to drive a development roadmap and project plan. + +If this is your first time engaging with these milestones, we suggest you: + +1. Start by reading the milestone short descriptions in [the milestone short descriptions file](./milestone_short_descriptions.md) +2. Then review the [dependency diagram](./external_milestone_dependency_diagram.mmd). diff --git a/documentation/milestones/individual_milestones/communication_platforms.md b/documentation/milestones/individual_milestones/communication_platforms.md new file mode 100644 index 000000000..a7b07b612 --- /dev/null +++ b/documentation/milestones/individual_milestones/communication_platforms.md @@ -0,0 +1,89 @@ +# Communication platforms + +## Short description + +Implement chat, wiki, and ticket tracking in a way accessible for all team members and the public. + +## Goals + +### Business description & value + +We must have easy-to-use and effective tools for communicating as a team. These communication technologies will be perhaps the most important pieces of technology implemented by and used by the team. + +These need to be accessible to internal (HHS or employed by HHS) partners as well as external partners (members of the general public). + +### Technical description + +Explore options for group chat, such as: + +* Slack +* HipChat +* Discord +* Microsoft Teams +* Open source alternatives like Mattermost, etc +* Others? + +Explore options for wiki-style storage and editing of documents, such as: + +* Confluence +* Github wiki +* Open source wiki platforms +* Others? + +Explore options for tracking of tickets with ability to track epics and burndown charts, such as: + +* GitHub with Zenhub + +These should be selected, implemented, and deployed. + +For the wiki-style tool, we need integrated page analytics so we can view stats such as the number of total visits to a page (or collection of pages) as well as unique visitors, time on page, etc. + +The wiki-style tool should have internationalization capabilities or we should document + +Ideally, the tool would have the ability to designate some users as direct editors of pages (do not need permission before merging changes) and some users as suggesters (can submit suggested changes that need to be approved by one or more editors before they get merged). + +Any code used to deploy or integrate these services should be made open source. + +### Definition of done + +- [ ] Onboarding instructions for new users are clearly and accessibly documented in a public place. +- [ ] Instructions for the internal team that assists with onboarding new users are clearly and accessibly documented in a public place. +- [ ] Without logging in, members of the public can see tickets and wiki documents. +- [ ] New users can be onboarded to chat for no cost to the user in a process that takes less than 2 days. +- [ ] New users can be onboarded to wiki for no cost to the user in a process that takes less than 2 days. +- [ ] Services are accessible to all people on the HHS network, White House network, public internet, and preferably most or all agency networks. +- [ ] In chat, users can send private messages to each other as well as view private and public channels. Users can use emojis to react to messages. +- [ ] In wiki, users can see history of changes to all documents. +- [ ] In tickets, users can create epics (or a similar concept) and track burndown. +- [ ] At least 5 members of HHS full-time staff are onboarded to all tools. +- [ ] At least 5 members of contractor teams (employed by HHS) are onboarded to all tools. +- [ ] At least 3 members of the general public are onboarded to all tools. +- [ ] Integrate Google Analytics or similar tool into wiki-style tool. +- [ ] Code for managing and deploying these services is deployed to `main` & PROD (if necessary) + +### Proposed metrics for measuring goals/value/definition of done + +1. Number of monthly active users in Chat, total +2. Number of monthly active users in wiki, total +3. Number of monthly active users in Chat, external +4. Number of monthly active users in wiki, external +5. Weekly volume of Chat messages +6. Weekly volume of wiki edits/contributions + +### Destination for live updating metrics + +Not yet known. + +## Planning + +### Assumptions & dependencies + +What capabilities / milestones do we expect to be in place at the beginning of work +on this milestone? + +- [x] None + +Are there any notable capabilities / milestones do NOT we expect to be in place at the +beginning of work on this milestone? + +- [x] None diff --git a/documentation/milestones/individual_milestones/milestone_template_published.md b/documentation/milestones/individual_milestones/milestone_template_published.md new file mode 100644 index 000000000..a61e2c327 --- /dev/null +++ b/documentation/milestones/individual_milestones/milestone_template_published.md @@ -0,0 +1,57 @@ +# Milestone template published + +## Goals + +### Business description & value + +By sharing our drafts of a milestone template, as well as drafts of initial milestones, we enable the team to stay coordinated around goals, priority order of goals, progress on delivering against those goals, awareness of dependencies. + +By sharing these publicly, they're accessible to all project team members as well as the ecosystem of open source contributors and other interested parties. + +### Technical description + +Publish the first draft of a milestone template with fields and descriptions of what those fields mean in an openly-accessible place (such as Github or a public wiki). + +Also publish initial list of milestones. + +Explore different options for this, such as: + +* Github +* Public wiki (Confluence or other wiki software) +* Others? + +Key criteria are that the tool must be very easy to use for both engineering/IT-familiar users as well as users less experienced with technology. + +### Definition of done + +- [ ] A self-described non-technical user can learn to edit the milestone document in less than 30 minutes. +- [ ] All template and drafts are accessible publicly. +- [ ] Everyone working on the project knows where the milestone template and drafts are. +- [ ] Integrate Google Analytics or similar tool into milestone pages. + +### Proposed metrics for measuring goals/value/definition of done + +1. Percent of milestones that are accessible publicly (note: this should remain constant at 100%) +2. Number of unique contributors to milestone documents, total + * How to measure this and deploy the measure live? +3. Number of unique contributors to milestone documents, external members (not HHS or employed by HHS) only + * How to measure this and deploy the measure live? +4. Number of total page visits to milestone documents + +### Destination for live updating metrics + +Not yet sure. + +## Planning + +### Assumptions & dependencies + +What capabilities / milestones do we expect to be in place at the beginning of work +on this milestone? + +- [ ] Communications platforms + +Are there any notable capabilities / milestones do NOT we expect to be in place at the +beginning of work on this milestone? + +- [x] None diff --git a/documentation/milestones/milestone_dependency_diagram.mmd b/documentation/milestones/milestone_dependency_diagram.mmd new file mode 100644 index 000000000..55ba1c642 --- /dev/null +++ b/documentation/milestones/milestone_dependency_diagram.mmd @@ -0,0 +1,177 @@ +%% A note on syntax: +%% 1. Since node IDs cannot have spaces, prefer to give each milestone a short name with any spaces replaced by `-`. For instance, "Development Tools Implemented" becomes "Dev-Tools". + +%% For unclear reasons, PyCharm's mermaid editor does not support title attributes. Comment on or off the title as needed. + +%% --- +%% title: Grants.gov modernization milestones +%% --- + +%% Diagram is oriented left-to-right ("LR") rather than top-to-bottom + +flowchart LR + + subgraph NOFO + NOFO-Milestone-Planning:::executing + NOFO-Prototypes:::planning + Start-PRA-Comment:::planning + NOFO-Prototypes-Metrics + NOFO-Prototypes-Metrics & NOFO-Prototypes --> NOFO-Prototypes-Learnings + NOFOs-Readability-Scoring + NOFOs-Writing-Assistance-Plan:::planning --> NOFOs-Writing-Assistance + end + + subgraph Personalization + Save-NOFOs + NOFOs-Worked + Profile-Builder + Save-NOFOs & NOFOs-Worked & Profile-Builder --> NOFO-Recommendations-API + NOFO-Recommendations-API --> NOFO-Recommendations-UI:::northStar + end + + subgraph User-Research + Research-Synthesis + Generative-User-Research:::finished --> Research-Synthesis:::executing + Research-Synthesis --> ev1[Research Synthesis informs *everything*\n related to UI/UX.\nLines not shown here for simplicity.] + Generative-User-Research --> User-Research-TBD + Document-GrantSolutions + User-Research-Compensation + User-Research-Database + end + + subgraph Sam.gov integration + Document-Sam + Document-Sam --> Sam-APIs:::northStar + Document-Sam --> Sam-Help-Desk + end + + subgraph Search + Search-API + NOFOs-Text + Search-API --> Search-UI + Search-API --> NOFOs-Text-Search + Search-API --> Geographic-Search + Search-User-Research + Search-API & Search-User-Research --> Additional-Search + NOFOs-Text --> NOFOs-Text-Search + NOFOs-Text --> NOFOs-Readability-Scoring + NOFOs-Text-Search --> Search-API-2.0:::northStar + end + + subgraph AuthN and AuthZ + Document-AuthN-AuthZ + Document-AuthN-AuthZ --> AuthN-API + Document-AuthN-AuthZ --> AuthZ-API + AuthN-API --> AuthZ-API + AuthN-API --> OAuth + AuthN-API --> Entity-API:::northStar + Entity-API --> Sam-APIs + Entity-API --> Save-NOFOs + Entity-API --> NOFOs-Worked + Entity-API --> Profile-Builder + end + + subgraph User interface + FE-Plan + FE-CI-CD + FE-Plan --> FE-CI-CD + FE-Plan --> CMS + FE-Plan --> Web-Analytics + FE-Plan & CMS --> i18n + CMS --> CMS-Open-Source + CMS-Open-Source & i18n --> Translation-Process:::northStar + FE-CI-CD --> Foundational-UI:::northStar + Foundational-UI --> Search-UI + Foundational-UI --> NOFO-Recommendations-UI + end + + subgraph Expanded-UI + NOFO-Listing-UI + Foundational-UI --> NOFO-Listing-UI + Foundational-UI --> Sam-Assistance-UI + Document-Sam --> Sam-Assistance-UI + Foundational-UI --> Grants-Assistance-UI + Foundational-UI --> Help-UI + Foundational-UI --> AuthN-UI + Foundational-UI --> AuthZ-UI + AuthN-API --> AuthN-UI + AuthZ-API --> AuthZ-UI + end + + subgraph Define goals + Define-Goals:::northStar + Define-Goals --> Measurement-Strategy + Measurement-Strategy --> Measurement-Dashboard + end + + subgraph Analytics + Analytics-API + Define-Goals --> Analytics-API + Analytics-API --> Data-Quality-API + Analytics-API & Data-Quality-API --> Analytics-Visualization:::northStar + Measurement-Dashboard --> Analytics-Visualization + Analytics-API --> Place-Of-Performance-API + Place-Of-Performance-API --> Place-Of-Performance-Visualization:::northStar + end + + subgraph Initial API deployment + Onboard-Dev-Team:::planning + Onboard-Dev-Team --> Dev-Tools + Onboard-Dev-Team --> DB-API-Plan + Onboard-Dev-Team --> Feature-Flags + DB-API-Plan --> API-Docs-Plan + Onboard-Dev-Team --> DB-Replica + Beta-Domain + DB-Replica --> DB-Test-Data + DB-API-Plan & DB-Test-Data & DB-Replica & Dev-Tools & Beta-Domain --> GET-Opportunities:::northStar + DB-API-Plan & GET-Opportunities --> Webhooks-Opportunities + GET-Opportunities --> API-Docs + GET-Opportunities --> AuthN-API + GET-Opportunities --> Analytics-API + API-Docs-Plan & Beta-Domain --> API-Docs + DB-API-Plan --> API-Versioning + ATO + ATO --> CI-CD + DB-API-Plan --> CI-CD + CI-CD --> CI-CD-Metrics + DB-API-Plan --> Dependency-Fundraising-Tracking + GET-Opportunities --> Search-API + GET-Opportunities --> NOFOs-Text + end + + subgraph Hackathon + Hacakthon-Page + Hackathon-Data + Hackathon-Listing:::northStar + Recruit-Hackathon-Workgroups + Recruit-Hackathon-Participants + Hacakthon-Page & NOFO-Prototypes --> Hackathon-Listing + Recruit-Hackathon-Workgroups & Recruit-Hackathon-Participants --> Hackathon-Listing + Hackathon-Listing --> Hackathon-Apply + Hackathon-Listing --> Hackathon-Listing-Internal-Entry + Hackathon-Apply --> Hackathon-Data + Hackathon-Apply --> Hackathon-Apply-Internal-Entry + Analytics-API --> Hackathon-Data + Hackathon-Data --> Hackathon-Data-Internal-Entry + end + + subgraph Communications Tooling + Comms-Platforms:::planning --> Milestone-Template:::planning + Comms-Platforms --> Open-Source-Tools + Open-Source-Tools & Comms-Platforms --> Open-Source-Group:::northStar + Open-Source-Group --> Hackathon-Listing + end + + subgraph Legend + direction LR + a1[This milestone is finished]:::finished --> a2[This milestone is being executed]:::executing + a3[This milestone is being planned]:::planning --> a4[This milestone is not yet planned] + a5[This milestone is a 'north star' milestone]:::northStar + end + + + %% Define some styles + classDef planning fill:#9999FF + classDef executing fill:#FF6633 + classDef finished fill:#99FF33 + classDef northStar fill:#cc99ff diff --git a/documentation/milestones/milestone_short_descriptions.md b/documentation/milestones/milestone_short_descriptions.md new file mode 100644 index 000000000..4df98ec06 --- /dev/null +++ b/documentation/milestones/milestone_short_descriptions.md @@ -0,0 +1,878 @@ +# Project goals + +## Define and publish core project goals +Diagram short name: `Define-Goals` + +Dependencies: `None` + +Define and publish core project goals, with proposed key metrics for all goals. + +Define both short and long-term goals. + +## Measurement strategy +Diagram short name: `Measurement-Strategy` + +Dependencies: `Define-Goals` + +Define and publish core project measurement strategy. + +## Public measurement dashboards +Diagram short name: `Measurement-Dashboard` + +Dependencies: `Measurement-Strategy` + +Launch initial public measurement dashboard. + +# Initial API deployment milestones + +## Onboard development team +Diagram short name: `Onboard-Dev-Team` + +Dependencies: `None` + +Have the software development team for this effort start their work and get systems access. + +## Developer tools + +Diagram short name: `Dev-Tools` + +Dependencies: `None` + +Install developer tools for backend, including: + +- Automated test framework +- Linters, code quality checkers, and code autoformatters +- Automated test coverage analysis +- API description linter (Spectral or alternative) - this can also be saved until API milestone +- Security scan of packages (Snyk or alternative) +- etc + +## DB replica + +Diagram short name: `DB-Replica` + +Dependencies: `None` + +Create a replica of AWS PROD database for legacy grants.gov in a beta.grants.gov environment. Replica should (1) journal all changes from legacy DB to new system DB and (2) support uptime even while legacy DB is undergoing planned or unplanned downtime, maintenance, and upgrades. + +The creation of this replica should be scripted using infrastructure as code. + +## Test data and schema + +Diagram short name: `DB-Test-Data` + +Dependencies: `DB-Replica` + +Create a script or other automated tool that: + +1. Generates a database matching the schema of the beta.grants.gov core replica DB. +2. Generates consistent fake example data that can be used for testing. (e.g., using the same random seed to generate consistent data, or saving test data values somewhere accessible) + +This will dramatically speed up development because it will allow any developer to generate a local copy of the database that acts the same as the PROD beta.grants.gov database in their environment. + +By having consistent test data, we can create integration tests that look for expected and unexpected behaviors. + +## DB & API planning +Diagram short name: `DB-API-Plan` + +Dependencies: `None` + +Make an analysis of needs and alternatives and choose: + +* Database(s) type(s) (e.g., relational, document store, or alternative) +* Database(s) language(s) (e.g., MongoDB, Postgres or alternative) +* Database(s) deployment(s) (e.g., RDS or alternative) +* Database ORM (e.g., SQLAlchemy or alternative) +* API types (e.g., RESTful JSON, webhooks, GraphQL, or alternatives) +* API language (e.g., Python, Node) +* API deployment (e.g., EC2, serverless, or alternative) + +## Serialization and API documentation planning +Diagram short name: `API-Docs-Plan` + +Dependencies: `DB-API-Plan` + +Make an analysis of needs and alternatives and choose: + +* Serialization framework (e.g., Marshmallow or alternative) +* API autogenerator +* API documentation (e.g., OpenAPI) autogenerator + +Ideally, fields would be defined only once in the codebase, and these definitions would be used to generate (with as little manual configuration as possible) both RESTful API endpoints and the documentation for those endpoints. + +Otherwise, every time there is a change in schema, it requires a lot of developer attention to update field definitions, API definitions, and API documentation. + +## GET opportunities +Diagram short name: `GET-Opportunities` + +Dependencies: `DB-API-Plan`, `DB-Test-Data`, `DB-Replica`, `Dev-Tools`, `Beta-Domain` + +Deploy a public endpoint to PROD that allows users to see at least one (but not necessarily more than one!) field of data per listed opportunity in grants.gov. This will probably be a RESTful JSON /GET API endpoint. + +This API should be accessible even when legacy grants.gov is experiencing planned or unplanned outages. + +Metrics: +* Number of unique users accessing API +* Number of total API calls made +* Error rate of API calls +* Uptime of service +* etc. + +## beta.grants.gov domain +Diagram short name: `Beta-Domain` + +Dependencies: `None` + +Gain access to the subdomain, `beta.grants.gov`. Prove access by deploying static test content (e.g., ipsum lorem) to that subdomain. + +## Feature flag framework +Diagram short name: `Feature-Flags` + +Dependencies: `Onboard-Dev-Team` + +Choose and implement framework for having feature flags in production. + +## API versioning framework +Diagram short name: `API-Versioning` + +Dependencies: `DB-API-Plan` + +Based on the plan defined in `DB-API-Plan`, choose and implement a framework for versioning the API using semantic versioning and being able to easily issue minor and major changes to the API. + +Document versioning in API docs. + +Also develop and execute release management plan with plan for release cycles, release notes, etc. + +## ATO + +Diagram short name: `ATO` + +Dependencies: `DB-API-Plan` + +Review planned public deployment of services with Jacob, our security officer, to confirm that they all fall under our existing ATO for grants.gov + +## CI-CD +Diagram short name: `CI-CD` + +Dependencies: `DB-API-Plan`, `ATO` + +Based on the plan defined in `DB-API-Plan`, choose and implement a framework for continuous integration and continuous deployment. + +When commits are made to any branch, these should automatically: +* Run lint suite +* Run test suite +* Deploy branch to backend and/or frontend test environments + +When commits are made to `staging` branch, these should automatically: +* Deploy branch to STAGING environments +* Run smoke tests and integration tests in STAGING + +When merges are made to `main`, these should automatically: +* Deploy branch to PROD environments +* Run smoke tests and integration tests in PROD + +Metrics: +* Frequency of deploys to production +* Duration of time it takes per deploy +* Duration of time it takes per rollback + +For discussion: is a STAGING environment and `staging` branch necessary at this stage, or should we continuously deploy to PROD as feature branches are merged into `main`? + +## CI-CD-Metrics +Diagram short name: `CI-CD-Metrics` + +Dependencies: `CI-CD` + +Design and implement public metrics on CI-CD, such as the average speed of running a full test suite and deployment. + +Try to keep these speeds down as much as possible: developer speed determines the speed of our feedback loops, and fast feedback loops are how we stay responsive to user needs and keep site performance high. + +## API documentation +Diagram short name: `API-Docs` + +Dependencies: `API-Docs-Plan`, `Get-Opportunities`, `Beta-Domain` + +Based on the plan defined in `API-Docs-Plan`, launch a publicly accessible page for developer tooling and API documentation, such as https://beta.grants.gov/developers. For reference, see examples such as the one at https://qpp.cms.gov/developers. + +This could be a microsite hosted on its own, or deployed within and as part of the beta.grants.gov integrated front-end experience. + +This should include full OpenAPI documentation of the `GET Opportunities` API, as well as a tutorial for users who are interacting with the `beta.grants.gov` APIs for the first time. + +The documentation should also describe what is likely to be stable in the API as it is developed versus what is unstable and will likely change without warning. + +The update and deployment of documentation should be fully open source and managed through infrastructure as code. + +Configure web analytics in documentation to track visitors. + +Metrics: + +* Number of unique monthly average users of API documentation +* Number of repeat users of API documentation +* Feedback survey results on usability of API documentation? + +## Webhooks for opportunities +Diagram short name: `Webhooks-Opportunities` + +Dependencies: `DB-API-Plan`, `GET-Opportunities` + +Deploy a public webhook to PROD that allows users to subscribe to receive system-to-system updates when data is updated in the beta.grants.gov database. + +The definition of this milestone could change based on planning done in `DB-API-Plan`. + +Metrics: +* Number of unique users receiving webhooks calls +* Number of total webhooks calls received + +## Back-end dependency fundraising tracking + +Diagram short name: `Dependency-Fundraising-Tracking` + +Dependencies: `DB-API-Plan` + +For the front-end, there is a great tool (https://backyourstack.com/) that shows fundraising being conducted by the packages that are used as dependencies in your project. This tool currently only supports fundraising done through OpenCollective, which provides a systematic API that can be used to collect this data. + +This milestone is to add to that tool support for backend packages such as Python that are raising funds through OpenCollective. + +Based on initial research, the level of effort should be assessed to determine whether the time it would take to implement this milestone is worth the result. If it's longer than 2 weeks time of one developer, it may not be worth it. + +# Communications Tooling + +## Communication platforms +Diagram short name: `Comms-Platforms` + +[Link](./milestones/communication_platforms.md) + +## Milestone template published +Diagram short name: `Milestone-Template` + +[Link](./milestones/milestone_template_published.md) + +## Open source tools + +Diagram short name: `Open-Source-Tools` + +Dependencies: `Comms-Platforms` + +Configure the following things in the open source repository: + +1. License +2. Responsible disclosure policy +3. Wiki (or link to wiki) +4. Contributions guide + +## Open source group kickoff +Diagram short name: `Open-Source-Group` + +Dependencies: `Open-Source-Tools`, `Comms-Platforms` + +Configure the following things for the open source group: + +1. Chat channel for communication +2. Unconference tools for voting on agenda topics (EasyRetro or alternative) +3. Mailing list (Google Group, GSA List, or alternative) + +Then schedule and execute a kickoff meeting with interested attendees. + +# NOFO milestones + +## NOFO milestone planning +Diagram short name: `NOFO-Milestone-Planning` + +Dependencies: `None` + +Document ongoing milestones related to NOFO simplification. + +## NOFO prototypes +Diagram short name: `NOFO-prototypes` + +Dependencies: `None` + +Deliver 4 NOFOs where the text and the PDF layout of the NOFO are fully redesigned. + +## Define usability test metrics for NOFO prototypes +Diagram short name: `NOFO-Prototypes-Metrics` + +Dependencies: `None` + +Define usability testing metrics that will be used to evaluate the success of the 4 NOFO prototypes. + +## Report on learnings from NOFO prototypes +Diagram short name: `NOFO-Prototypes-Learnings` + +Dependencies: `NOFO-Prototypes-Metrics`, `NOFO-Prototypes` + +Create report defining what we've learned from NOFO prototypes usability testing, such as a clear set of best practices and things to avoid. + +## Readability scoring for NOFOs +Diagram short name: `NOFOs-Readability-Scoring` + +Dependencies: `NOFOs-Text` + +Automatically run readability scoring on all NOFOs posted to Grants.gov. + +## Writing assistance tools for NOFOs: planning stage +Diagram short name: `NOFOs-Writing-Assistance-Plan` + +Dependencies: `None` + +Plan for how to provide grantors with tools that integrate into their daily workflow that will help them write simpler, clearer NOFOs. + +## Writing assistance tools for NOFOs: implementation stage +Diagram short name: `NOFOs-Writing-Assistance` + +Dependencies: `NOFOs-Writing-Assistance-Plan` + +Implement writing assistance tools. + +## PRA submitted & public comment started +Diagram short name: `Start-PRA-Comment` + +Dependencies: `None` + +Submit generic clearance documents to secure generic PRA approval. The approval does not need to be completed to complete the milestone, but the documents do need to be submitted and the public comment period needs to be started by posting them publicly. + +# Analytics milestones + +## Operational analytics endpoint +Diagram short name: `Analytics-API` + +Dependencies: `GET-Opportunities` + +Produce one statistic about the operational effectiveness of grants.gov that is served with live data over a public API endpoint. This can be any statistic. Preferably it should be something useful that is interesting to members of the HHS team and members of the public, such as the total number of applications received for a given opportunity. + +## Data quality analytics endpoint +Diagram short name: `Data-Quality-API` + +Dependencies: `Analytics-API` + +Produce one statistic about the data quality of one or more fields in grants.gov that is served with live data over a public API endpoint. This can be any statistic. Preferably it should be something useful that is interesting to members of the HHS team and members of the public, such as the percent of null values in a given field, reported by Agency/OpDiv. + +## Data analytics visualization +Diagram short name: `Analytics-Visualization` + +Dependencies: `Analytics-API`, `Data-Quality-API` + +Produce visualizations of the data served over the two endpoints. These visualizations should be publicly accessible and scripted so that they are updated frequently and/or at the time of a visitor landing on the page. They should not be produced using one-off techniques but should be part of a sustainable, deployed analytics solution. + +This could look like Javascript code being used to write and deploy D3 visualizations, or Python notebooks that are hosted in such a fashion that the data powering the visualizations is updated live. + +## Publish place of performance data +Diagram short name: `Place-Of-Performance-API` + +Dependencies: `Analytics-API` + +Produce an API endpoint that for at least two grantmaking programs provides data on the place of performance of their grants. This will be using spatial data. + +## Place of performance analytics visualization +Diagram short name: `Place-Of-Performance-Visualization` + +Dependencies: `Place-Of-Performance-API` + +Produce visualizations of the place of performance data. This could look like a map using MapBox or MapLibre (preferable because it's open source). + +# Auth milestones + +## Document authentication (authN) and authorization (authZ) frameworks +Diagram short name: `Document-AuthN-AuthZ` + +Dependencies: `None` + +Document the authentication (authN) and authorization (authZ) frameworks currently used by grants.gov with as much specificity and accuracy as possible. What workflows do users go through to access new authZ roles? What permissions do they get per role? + +Furthermore, we should also document with as much specificity and accuracy as possible the authN and authZ roles of sam.gov, since completing tasks in sam.gov is necessary for completing most tasks within grants.gov. + +## Authenticate via API using Login.gov +Diagram short name: `AuthN-API` + +Dependencies: `GET-Opportunities`, `Document-AuthN-AuthZ` + +Users should be able to login to an authenticated experience of the APIs using their login.gov credentials. This will at the moment not provide any additional functionality to users (login will be the basis of future functionality). + +## Authorize via API +Diagram short name: `AuthZ-API` + +Dependencies: `AuthN-API`, `Document-AuthN-AuthZ` + +Users should be able to manage authorizations (authZ) for their grants.gov work over APIs. + +## OAuth +Diagram short name: `OAuth` + +Dependencies: `AuthN-API` + +Users should be able to delegate API access by logging in using their login.gov credentials to another system, which authenticates with beta.grants.gov APIs on their behalf using OAuth. + +OAuth is already implemented as part of login.gov: https://developers.login.gov/oidc/. + +## User and entity information endpoint +Diagram short name: `Entity-API` + +Dependencies: `AuthN-API` + +Authenticated users should be able to see at least one field about their profile (for instance, whether their affiliated entity has a UEI number already affiliated). + +# Sam.gov integration milestones + +## Document sam.gov tasks +Diagram short name: `Document-Sam` + +Dependencies: `None` + +Document all tasks that need to be completed on sam.gov to enable functionality on grants.gov. + +Document which of these tasks can be completed using APIs versus which must go through the sam.gov user interface. + +## Integrate sam.gov APIs +Diagram short name: `Sam-APIs` + +Dependencies: `Document-Sam` + +Integrate with the [Sam.gov APIs](https://open.gsa.gov/api/entity-api/) to complete as many Sam.gov-related tasks as possible through grants.gov. + +Much more definition of this milestone is needed. + +## Integrate sam.gov and grants.gov help desk +Diagram short name: `Sam-Help-Desk` + +Dependencies: `Document-Sam` + +Investigate potentailly providing a "warm hand-off" option to integrate sam.gov and grants.gov help desks to reduce user frustration at being told to hang up and call a different help desk. + +This may not be feasible. + +# Hackathon milestones + +## Hackathon informational page +Diagram short name: `Hackathon-Page` + +Dependencies: `None` + +Deploy a webpage somewhere that gives a full description of the hackathon plan, invitation, signup, etc. + +As part of this milestone, choose a better and more inclusive name than "hackathon". + +## Recruit hackathon participants +Diagram short name: `Recruit-Hackathon-Participants` + +Dependencies: `None` + +Recruit at least 3 organizations that have said they are interested in participating in the first hackathon phase on NOFO listings. + +## Recruit hackathon workgroups +Diagram short name: `Recruit-Hackathon-Workgroups` + +Dependencies: `None` + +For the hackathon, we may choose to form workgroups that function as a sort of caucus that makes recommendations about various entries. This paradigm can be continued as part of the ongoing open source work on grants.gov. + +Workgroups review demos and make recommendations and endorsements representing their affinity group. + +For instance, there could be different workgroups for: + +* Staff from city governments +* Environmental justice / Justice40 organizations +* Grantmaking networks (such as Grant Professionals Association) +* Visually impaired individuals and/or individuals with other accessibility needs +* System-to-system users + +Grants.gov team staff would provide support through tools to assist these groups in decisionmaking and submitting recommendations. As with all members of the public, they'd be invited to attend sprint demos and other planning sessions. + +For this milestone, we would recruit at least three participants for each of three workgroups to help get the concept started. + +Recruit at least 3 organizations that have said they are interested in participating in the first hackathon phase on NOFO listings. + +## Hackathon Phase 1: NOFO listing +Diagram short name: `Hackathon-Listing` + +Dependencies: `Open-Source-Group`, `Hackathon-Page`, `RFI`, `NOFO-Prototypes`, `Recruit-Hackathon-Workgroups`, `Recruit-Hackathon-Participants` + +Phase 1 of the hackathon: the listing itself. + +Key parts of this milestone: + +* Large invite list +* Kickoff event (hybrid in-person and remote) + * Speakers and introductions organized for kickoff event + * Demo 4 simplified NOFOs and talk about overall approach. + * Discuss vision, goals, and process for hackathon. + * Press invited to event +* Regular meetings scheduled for duration of hackathon (e.g., once every two weeks for demos and questions) +* Closing ceremonies scheduled for 2-3 months later + +## Hackathon NOFO listing: Internal entry +Diagram short name: `Hacakthon-Listing-Internal-Entry` + +Dependencies: `Hacakthon-Listing`, `Research-Synthesis` + +A submission, by the software development modernization team for grants.gov, for the hackathon phase 1: listing page. + +## Hackathon Phase 2: Apply +Diagram short name: `Hacakthon-Apply` + +Dependencies: `Hacakthon-Listing` + +Phase 2 of the hackathon: the application. + +## Hackathon NOFO Apply: Internal entry +Diagram short name: `Hacakthon-Apply-Internal-Entry` + +Dependencies: `Hacakthon-Apply`, `Research-Synthesis` + +A submission, by the software development modernization team for grants.gov, for the hackathon phase 2: application page. + +## Hackathon Phase 3: Data +Diagram short name: `Hacakthon-Data` + +Dependencies: `Hacakthon-Apply`, `Analytics-API` + +Phase 3 of the hackathon: the data. + +## Hackathon data: Internal entry +Diagram short name: `Hacakthon-Data-Internal-Entry` + +Dependencies: `Hacakthon-Data` + +A submission, by the software development modernization team for grants.gov, for the hackathon phase 2: data. + +# User interface milestones + +## Front-end planning + +Diagram short name: `FE-Plan` + +Dependencies: `None` + +Choose language (e.g., TypeScript), framework (e.g., React) and testing framework (e.g., Jest) for front-end. + +## Front-end CI-CD + +Diagram short name: `FE-CI-CD` + +Dependencies: `FE-Plan` + +Install developer tools for front-end, including: + +- Automated test framework +- Linters, code quality checkers, and code autoformatters +- Automated test coverage analysis +- Security scan of packages (Snyk or alternative) +- Automated accessibility testing +- Mobile responsiveness testing +- Funding needs of packages (https://backyourstack.com/ or alternative) +- etc + +These should all run on CI-CD like the definition of the milestone `CI-CD`. + +## CMS + +Diagram short name: `CMS` + +Dependencies: `FE-Plan` + +Choose and implement a CMS, such as the headless CMS Storyblok being implemented by grants.gov. + +## Open source CMS content + +Diagram short name: `CMS-Open-Source` + +Dependencies: `CMS` + +Implement CMS in such a way so that the content is tracked and version controlled in an open source fashion, if this is at all possible. + +## Web analytics + +Diagram short name: `Web-Analytics` + +Dependencies: `FE-Plan` + +Choose and implement a web analytics framework, such as analytics.gov or Google Analytics, where all data can be made publicly available. + +## Internationalization framework + +Diagram short name: `i18n` + +Dependencies: `FE-Plan`, `CMS` + +Implement an internationalization framework (to support multiple languages) we believe can scale as the site scales. + +Invest early in this. It is much easier to build internationalization in from the beginning than it is to add support for it to an existing codebase. + +## Translation process & contracts + +Diagram short name: `Translation-Process` + +Dependencies: `i18n`, `CMS-Open-Source` + +Implement a process (preferably an automated one) that makes translations quickly and accurately available for content. + +This could include using the State Department for translation like many USDS websites do, or setting up external bounties for translation such as those used by Open Collective Foundation: https://docs.opencollective.com/help/contributing/translation#bounties. + +Preference for integrating the external team that does translations directly into the codebase so they can make their own pull requests to content. + +Define languages planned on support for website. The most common languages are published by the Census: https://www.census.gov/library/stories/2022/12/languages-we-speak-in-united-states.html. A reasonable option for a starting point for supported languages would be Spanish and either Mandarin or Cantonese (the Census marks both of these as 'Chinese' so it is not clear which is the 3rd most commonly spoken language in the US). + +For language data, there is more detailed microdata found in the Microdata Access Tool (MDAT). Here's a table using the 2021 1-year ACS Public Use Microdata Sample (PUMS) file: https://data.census.gov/mdat/#/search?ds=ACSPUMS1Y2021&rv=HHLANP&wt=WGTP. + +Ideally, every release of new content should be followed shortly thereafter by translations in key supported languages. Milestones will not be complete until their related content is released in all supported languages. + +## Foundational UI +Diagram short name: `Foundational-UI` + +Dependencies: `FE-CI-CD`, `Research-Synthesis` + +Build and deploy a basic UI framework for the site, using USWDS, informed by research synthesis. + +This includes basic information architecture, navigation, path parameters for navigating to different pages, the capability to complete query parameters, etc. + +Responsive design should be included from the beginning and integrated into testing. + +# Search milestones + +## Search API +Diagram short name: `Search-API` + +Dependencies: `GET-Opportunities` + +1.0 version of an API to provide better searching on opportunities. + +## Search UI +Diagram short name: `Search-UI` + +Dependencies: `Search-API`, `Foundational-UI` + +Front-end for search API. + +## Full text of NOFOs stored as text +Diagram short name: `NOFOs-Text` + +Dependencies: `GET-Opportunities` + +Convert all PDFs of NOFO listings (using their XML-based representation) into free text that can be stored in the database(s) and searched. + +## Full text search of NOFOs +Diagram short name: `NOFOs-Text-Search` + +Dependencies: `NOFOs-Text`, `Search-API` + +Search free text of NOFOs. + +## Tuned search API (Search 2.0) +Diagram short name: `Search-API-2.0` + +Dependencies: `NOFOs-Text-Search` + +Tune the search API endpoint to give better results based on what users are looking for. + +## Geographic search +Diagram short name: `Geographic-Search` + +Dependencies: `Search-API` + +Organizations are located in and/or serving very specific geographies. Currently, there's no way to add geographic search filters to results. For instance, searching "environmental justice" returns a lot of results for international aid or for specific countries (e.g., Mexico) that will be irrelevant to applicants from Alabama. + +Build a search API feature that, for at least some NOFOs, restricts search results to the geographies that are affiliated with the applicant that is searching for NOFOs. + +The challenge with this milestone will be that few NOFOs have easily accessible, clearly tagged geographic data. Perhaps we can setup a system of adding this data per NOFO, or crowdsourcing the data with verification. + +## User research for search +Diagram short name: `Search-User-Research` + +Dependencies: `Search-API` + +Conduct additional user research on search needs. + +## Additional search +Diagram short name: `Additional-Search` + +Dependencies: `Search-User-Research` + +Add additional search (e.g., by community type, by capital availability, etc) features driven by user research's identification of search needs. + +# Personalization milestones + +## Save NOFOs to profile + +Diagram short name: `Save-NOFOs` + +Dependencies: `Entity-API` + +Possibly allow users the ability to mark a NOFO to be "saved" to their profile, for instance as an opportunity they're interested in working on. + +## Show NOFOs the user has worked on + +Diagram short name: `NOFOs-Worked` + +Dependencies: `Entity-API` + +Possibly allow users the ability to see which NOFOs they have submitted in the past or are currently working on. + +## NOFO Recommendations API + +Diagram short name: `NOFO-Recommendations-API` + +Dependencies: `Save-NOFOs`, `NOFOs-Worked`, `Profile-Builder` + +Possibly implement API that generates recommendations for users to look at certain opportunities based on their profile, their "saved" NOFOs and the NOFOs they have previously submitted or worked on. + +## NOFO Recommendations UI + +Diagram short name: `NOFO-Recommendations-UI ` + +Dependencies: `NOFO-Recommendations-API`, `Search-UI` + +UI for recommendations. + +## Profile builder + +Diagram short name: `Profile-Builder` + +Dependencies: `Entity-API` + +Possibly implement API that allows users to interact with their profile, and update characteristics such as their entity type (e.g., small local government, Tribal, CBO, etc), their capacity for matching funds (e.g., <=$20m), etc. + +Particular attention should be paid to profile fields that are relevant for finding related federal opportunities. + +# User research milestones + +## Generative user research +Diagram short name: `Generative-User-Research` + +Dependencies: `None` + +Since January 25, 2023, Huge has conducted in-depth one-on-one interviews with applicants and grantors to understand the end user experience of Grants.gov. With the aim of creating a more equitable Grants.gov, Huge explored key barriers for underserved and first-time applicants, and identified areas for improvement along the grantor and applicant user journeys. Focusing specifically on Find and Apply functions, Huge examined the role of Grants.gov in the broader grant opportunity ecosystem and examined specific pain points that hinder the grant seeking process for end users. + +The results of these findings will be incorporated in the Phase II Vision presentation, which will feature user archetypes and a strategic vision for a more equitable Grants.gov. The purpose of this document is to serve as a topline preview of grantor and applicant insights as the Huge team continues to synthesize research findings and inform the overall vision. + +Research Objectives + +1. Exploration of the role of Grants.gov in the broader ecosystem: Examine existing user behaviors in the grant seeker’s and grantor’s journey, identifying where Grants.gov fits in their overall approach and what role it provides in relation to other systems. +2. Evaluation of semi-structured Grants.gov experience: Investigate participants’ experience, including their organic user journeys based on their role, features of Grants.gov that standout, and any challenges they have with the interaction along the way. +3. Evaluation of specific task completion: Observe participants’ pain points and delights while they attempt to complete specific journeys related to their roles in posting, finding, and applying to grants, and their ability to complete related tasks. +4. Exploration of opportunities for an equitable experience: Identify key barriers to and areas of opportunity where grants.gov can help increase applications for underserved communities. + +Methodology + +* Method: Moderated in-depth interviews +* LOI: 60-75 minutes +* Platform: Google Meet + * Audience: +○ n=12 Grantors +○ n=38 Applicants (26% First Time Applicants, 39% Casual/Occasional Applicants, 34% Serial/Frequent Applicants) +* Field Dates - 1/25/2023 - 3/3/2023 + +## Research synthesis and vision +Diagram short name: `Research-synthesis` + +Dependencies: `Generative-User-Research` + +Note: Research synthesis must inform all UI designs. This relationship is not always marked on the diagram due to the complexity of the arrows, but it is a necessary dependency for all UI designs. + +Deliverables from Huge: + +* Research synthesis - Huge will compile findings from the user research sessions to identify key insights. In doing this, we will highlight user pain points and challenges as well as features and functionalities that are liked by users today. +* Archetype definition - Based on research findings, Huge will define user archetypes structured by needs and behavioral attributes. These archetypes create a common, shared understanding of users’ behaviors, attitudes, goals, and pain points that will need to be met by the future state of Grants.gov. +* UX explorations - The Huge UX lead will design initial wireframes that will explore identified areas of opportunity as a way to highlight future state solutions for Grants.gov. Wireframes will be illustrative but will provide a solid foundation for planning and development of high fidelity design. +* Visual design explorations - The Huge team will ideate on how to improve the current Grants.gov design system visually. Explorations will be illustrative but could be iterated on in future phases of work. +* Vision creation - The vision for Grants.gov will summarize our recommended ‘North Star’ for the product ecosystem. This north star will provide the guardrails for planning the subsequent design and release phases. +* Roadmap planning - Based on the shared vision, Huge will define a sequenced roadmap for how to bring to life Grants.gov that takes into account regular, iterative releases of key functionality. + +## Document GrantSolutions integration points +Diagram short name: `Document-GrantSolutions` + +Dependencies: `None` + +Document all tasks that need to be completed on GrantSolutions to enable functionality on grants.gov. For instance, to post a NOFO to grants.gov, you may (or may not) need to go through the announcement module of GrantSolutions. + +Document which of these tasks can be completed using APIs vs which must go through the GrantSolutions.gov user interface. + +## User research compensation +Diagram short name: `User-Research-Compensation` + +Dependencies: `None` + +Investigate potentially setting up a system for compensation user research participants, modeled after the compensation system developed by USDS at the White House. + +This will promote fairness, as well as increasing the quality and diversity of our pool of user research participants, by compensating participants for sharing their lived experience and expertise. + +## User research participants database +Diagram short name: `User-Research-Database` + +Dependencies: `None` + +Create a database that is easy to maintain and update of potential participants for ongoing user research to contact about future user research opportunities. + +Ideally, this database would also have some (appropriate) characteristics of the people stored so that when we're looking to talk to individuals representing certain characteristics, we can narrow our search to those people. + +## Additional user research TBD +Diagram short name: `User-Research-TBD` + +Dependencies: `Generative-User-Research` + +Additional user research milestones to be defined later on topics such as search, apply, etc. These need to be fleshed out in detail. + +# Expanded UI milestones + +## NOFO Listing page +Diagram short name: `NOFO-Listing-UI` + +Dependencies: `Foundational-UI`, `Research-synthesis` + +A page for individual NOFO listings. + +Should likely be built using configurable page template. For instance, using query parameters (or path parameters?) users should be able to view the NOFO listing in an alternative template format. This will make it easier to try new, modified designs for improved user experiences in the future and allow customization for users. (For instance, a third party could contribute a template via open source code that can be easily configured by users who want to use that third-party template.) + +## Sam.gov assistance page +Diagram short name: `Sam-Assistance-UI` + +Dependencies: `Foundational-UI`, `Document-Sam`, `Research-synthesis` + +A page for helping people understand and navigate their necessary tasks on Sam.gov. + +## Grants.gov assistance page +Diagram short name: `Grants-Assistance-UI` + +Dependencies: `Foundational-UI`, `Research-synthesis` + +A page for helping people understand and navigate their necessary tasks on Grants.gov. + +## Help page +Diagram short name: `Help-UI` + +Dependencies: `Foundational-UI`, `Research-synthesis` + +A page for helping people contact the help desk and other avenues for seeking customer support. + +## Authentication (authN) page +Diagram short name: `AuthN-UI` + +Dependencies: `Foundational-UI`, `AuthN-API`, `Research-synthesis` + +A workflow for helping people create accounts (via Login.gov) for use on Grants.gov. + +## Authorization (authZ) page +Diagram short name: `AuthZ-UI` + +Dependencies: `Foundational-UI`, `AuthZ-API`, `Research-synthesis` + +A workflow for helping people manage roles for use on Grants.gov. + +# Appendix + +Here is a template to use for these descriptions. + +The first option below is for milestones that have not been defined according to the [Milestone Template](./milestone_template.md). It provides fields for a short description of the milestone. + +The second option below is for milestones that have already been defined according to the [Milestone Template](./milestone_template.md). It provides a link to the template-based definition. + +## Milestone name +Diagram short name: `-` + +Dependencies: `-` or `None` + +Short description. + +OR + +Diagram short name: `-` + +[Link]() diff --git a/documentation/milestones/milestone_template.md b/documentation/milestones/milestone_template.md new file mode 100644 index 000000000..2b318c938 --- /dev/null +++ b/documentation/milestones/milestone_template.md @@ -0,0 +1,94 @@ +# Milestone name + +## Goals + +### Business description & value + +### Technical description + +### Definition of done + +- [ ] [to be added] +- [ ] Code is deployed to `main` & PROD +- [ ] Services are live in PROD (may be behind feature flag) +- [ ] Metrics are published in PROD. +- [ ] Translations are live in PROD (if necessary) + +### Proposed metrics for measuring goals/value/definition of done + +### Destination for live updating metrics + +## Planning + +### Assumptions & dependencies + +What capabilities / milestones do we expect to be in place at the beginning of work +on this milestone? + +- [ ] [to be added] + +Are there any notable capabilities / milestones do NOT we expect to be in place at the +beginning of work on this milestone? + +- [ ] [to be added] + +### Open questions + +- [ ] [to be added] + +### Not doing + +The following work will *not* be completed as part of this milestone: + +1. [to be added] + +## Integrations + +### Translations + +Does this milestone involve delivering any content that needs translation? + +If so, when will English-language content be locked? Then when will translation be +started and completed? + +### Services going into PROD for the first time + +This can include services going into PROD behind a feature flag that is not turned on. + +1. [to be added] + +### Services being integrated in PROD for the first time + +Are there multiple services that are being connected for the first time in PROD? + +1. [to be added] + +### Data being shared publicly for the first time + +Are there any fields being shared publicly that have never been shared in PROD before? + +1. [to be added] + +### Security considerations + +## Delivery + +### Target release + +### Product owner + +### Milestone document owner + +### Document status + +Choose one of: [Draft/Final Draft/Milestone Completed] + +### Lead designer + +### Lead developer + +## Documentation + +Epic name for this milestone in Zenhub: + +Dashboard for this epic: [link to Zenhub]