2022-10-19 - Product Committee

GovStack Working Process

@Jake Watson

15 min

Open

SDG Digital Framework is the basis for what we are doing with the GovStack. The value of GovStack is both the process and the outputs (Building Blocks, Use Cases, the “Ontology”)

The current process has started on the technical side because the product piece was not in place but this was not the intent, the use cases should drive the technical specs which drive the building block work. Without starting from the product, it’s difficult to be able to verify that the technical work is “correct.”

Comments

• Yolanda - What do we mean by “product”? (is it an end-to-end service that uses products?) What do we mean by “use case”? We need to have consensus on these definitions.

• Wes - we have things that we need to do quickly as we work on the definitions concurrently.

• Moritz - use cases should be rooted in country demand.

• Wes - that is the role of the product committee, both identify and work on use cases.

• Jake - Building block working groups are also following a model of a PO/technical lead

• Taylor - There is also a need for smaller committees which can have a quick turnover for some of the work we are trying to do in the near future.

• Yolanda- Shared link to terminology document which has been developed over time. There is a task force from all partners that put the implementation playbook together.

• Wes - this should be on Confluence so that it’s more accessible. Documentation of how we work together should be in confluence.

• Yolanda - let’s discuss, since the technical specifications, etc. live on GitBook

• Jaume - on the ID building block we are considering human component (because of the privacy, consent, and other user-centric components).

• Ramkumar - over a period of time, the dependency on the ID BB will grow (and the focus will have to change from foundational to functional ID BB). The process needs to consider the handoff between different building blocks.

• Wes - there needs to be a way to limit the scope. Use cases play an important role in doing that. Identity is otherwise an unbounded scope of work.

• Ramkumar - As GovStack grows, there will be a need to manage the growth and to reconfigure some of the processes. A small committee can architect a process for handoff points in the process and include it in the Charter. 1) scoping of what each group is doing, 2) how the handoff will work and how the dependencies will be managed. We should test the process with 1 use case and 1 user journey to figure out where are the gaps.

Roles and Responsibilities

@Jake Watson

15 min

Jake
We need to post JDs and have an organigram. Wes is responsible for coordinating with the BB WG leads to plan and schedule the next release (whatever the next release is). Someone should be responsible for QA for the releases.

Comments

• Taylor - product should go to technical and say “this is what I am trying to solve” and prioritizing each task. The technical committee is responsible for finding a solution, sizing and delivery.

• Jake - Wes is the PO, Steve/Ramkumar will be leading the Tech Committee, Rachel is the community mgr. Rachel is responsible for business development/outreach to different communities.

• Yolanda - we need to review process for GovStack implementation playbook. The service owner from the government point of view is also an important role as a check before we release the service.

• Wes - we need to have clean swimlanes for each of the committees with clearly defined leadership roles, to make sure it doesn’t get too complex.

• Ramkumar - the BB groups are expanding because their input will be required as the work progresses. The BB leads may have to lend support to the product/country engagement work.

• Moritz - Based on the Ukraine example, the product committee is where the place where some of the discussions on country engagement should take place (with technical members in the meeting)

What is the Core Product?

@Wes Brown

10 min

@Taylor Downs asking in chat: What products are we building? So far, he’s aware of these. But maybe there are more.

1. Use Cases

   1. …validated, published, nice!

2. Building Block Specifications

   1. spec

   2. api

   3. examples

      1. deployment script

      2. configuration scripts

         1. api-test-case

         2. use-case-x

   4. tests

      1. features in gherking

      2. implementation in Js/Python

   5. ci/cd

      1. runs all tests against all examples every time a change happens

      2. (maybe deploys to somewhere durable on _______ condition?)

3. A web portal (Sandbox?) for accessing and creating pre-configured deployments

   1. …need details

4. A Marketplace @Steve Conrad

   1. …need details

• Yolanda: what do you mean by use case? Digital government services?

• Wes: we are using the definition from the SDG Digital Investment Framework

• Jake: service design is new and we need to figure out how they will fit into the framework. The framework is well designed because it provides a “node” for different users to understand the entire approach (SDGs, Use Cases, Workflows, BBs). What is versionable is the framework itself, and impact stories, use cases, etc.

• Yolanda: this is fine, we just need to make sure we are clear about the definitions.

• Rachel: the marketplace needs to be a part of the discussion

• Steve: The connections between the BBs and use cases is very important.

• Wes: we need to make sure we are designing things which are generally usable and not specifically usable for a specific context.

Proposed Use Case Template

@Wes Brown

10 min

Reference Use Case Template (Example)

Country Engagement

@Wes Brown

10 min