...
\uD83D\uDC65 Participants
📹 Meeting Recording
Recording URL: Product Committee Meetings-20230308_150419-Meeting Recording
\uD83D\uDDE3 Discussion topics
Item | Presenter | Time | Notes |
---|
Review Action Items | | 5 min | Ramkumar: live master directory link is ready. Ayush will update the link once the remaining documents still on google drive have been moved to Confluence. Valeria: Almost done with the general revision for each of the BB specs - the information mediator, registration etc.
|
---|
Online Building Permit Use Case | Sainabou Jallow | 15 min | Draft Use Case: https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/product-use-case/urb-1-online-building-plan-approval-system Overview Interactive feedback session facilitated via Miro board: https://miro.com/app/board/uXjVMfs6qOg=/?share_link_id=451717494735 Feedback Step 2: Registration Margus: More clarification needed if this step is mimicking the process of registration building block steps - a generic process that is applicable in any kind of registration process? Margus: In the whole of government approach, to register a user should not happen because in an ideal case, everybody should have a singular digital identity - either from the certificate authority or the population registry. There should be in place a single system.
Step 4: Data Verification and Validation Ramkumar: The description assumes permission has already been granted to access and share applicants data (legal person/legally registered person/entities). This can cause privacy issues especially for businesses. This step should clarify and ensure permission has been granted from applicants. If it's a legal entity, there'll be an authorized person who has to officially give permission to share the relevant records of the organization. This step seems out of order - makes more sense to follow the unconditional cash transfer steps order. Could be moved to step 3.
Margus: Information mediator should be added as an additional BB - responsible for data exchange needs and verification processes.
Step 5: Review Step 7: Ongoing Case Management Sarah: There should be a different treatment for complaints which requires a different process that is outlined here. Addressing complaints should have a separate step as it also differs to monitoring and evaluation. Margus: from the registration perspective, change requests and disputes can be addressed in the same process via a task management system to address disputes or amendment requests.
Additional steps to incorporate Meelis: This use case seems to provide only a half service. If the aim is safety and sustainability at state and municipality level, then it should include a process (similar to application) - which validates the quality and accuracy of the building plan post construction. If the aim is to pilot a small part of a full digital service then it is OK, but is should be implicated at least. Sarah: Based on how the product use case is currently defined (single generic process), the current steps are enough. But if we're thinking about it from a service angle/end to end service delivery, then we could add this step. Need to officially decide how we are defining use cases as Govstack and then keeping that consistency throughout.
Ramkumar: A separate step should be added on method of issuing the permit. Maybe requires generating a new ID, communicating with different parties - informing relevant individuals/stakeholders of the issuance. Sarah: Add a cancelation step outlining process of when an applicant who started the application process wishes to cancel the permit request.
General use case format feedback Sarah: Likes the visualization depicted on the Miroboard. We should consider displaying visuals in the use cases on Gitbook. Ramkumar: We should figure out how to incorporate capabilities. If we can standardize a generic registration process/template. Offer registration as a generic capability. Then for the next use case, before working on the detailed outline from scratch, we can first check how its different from the standardized use case steps, and what additional requirements are needed. If the process is similar and generic then instead of creating a whole new use case document, these subject domain matters can be included as example implementations for i.e. registration, payment etc. Creating a standard template for these capabilities and adding example implementations per subject matter.
|
---|
Sync of Products' Value Proposition and Roadmaps | Nico Lueck | 15 min | Short PPT Input and Proposal View file |
---|
name | 230306 GovStack Ecosystem Roadmap 2023.pptx |
---|
|
Overview Focus is addressing the private sector side - how can we build this ecosystem and engage/incentivize system integrators and vendors to use the GovStack products once they are available. Feedback from PC members requested on how to plan activities/ implement the following approaches to get private sector actors on board for GovStack: The team can map/ outline for each product, its the value proposition - with vendors and SIs in mind. Organize a roadshow in different countries i.e. Djibouti explaining GovStack and asking local system integrators to take up GovStack.
Feedback Ramkumar: The Comms team went around collecting data from everyone - how to position GovStack and its value proposition. Might be worthwhile to review it. Need to be careful with the usage of the terminology ‘product’. 1. specifications, 2. test cases and harnesses, 3. sandbox and its example implementations/prototypes, and 4. content and tools - capacity building and resource training. We could each GovStack product to specific capabilities For this capability (i.e registration), these four GovStack complying products can be used for registration.
Sainabou: Organize GovStack relevant hackathons to engage the private sector.
|
---|
Accelerated Use Case Process | | 5 min | Status Update Review EPR Use Case ( Jira Legacy |
---|
server | System JIRA |
---|
serverId | f5c6bdaf-d23e-347d-a1e8-579e20a81dda |
---|
key | PRD-112 |
---|
| )Setup Online Construction Permit Tasks ( Jira Legacy |
---|
server | System JIRA |
---|
serverId | f5c6bdaf-d23e-347d-a1e8-579e20a81dda |
---|
key | PRD-115 |
---|
| )Compile Online Construction Permit Documents (Epic Required) Identify/Invite Country Representatives ( Jira Legacy |
---|
server | System JIRA |
---|
serverId | f5c6bdaf-d23e-347d-a1e8-579e20a81dda |
---|
key | PRD-117 |
---|
| )
| Sync of Products' Value Proposition and Roadmaps | Nico Lueck | 15 min | Short PPT Input and Proposal |
---|
✅ Action items
- Shukla, Ayush to create a live master directory document (on Confluence) with links to all relevant GovStack folders/files across the technical and non-technical workstreams. PSRAMKUMAR to then circulate this master directory link to all team members.
Jira Legacy |
---|
server | System JIRA |
---|
serverId | f5c6bdaf-d23e-347d-a1e8-579e20a81dda |
---|
key | PRD-120 |
---|
|
Ramkumar requested this item be checked as complete. - Martinez, Yolanda (Deactivated) to create proposal for where to host country content so that it can be linked in the Use Case on gitbook (Will present next week)
- Martinez, Yolanda (Deactivated) find out if/how to make Use Case source documents publicly available (readonly is fine)
- Jaume DUBOIS to translate GovStack slides into French - requested this item deadline be moved to March/April
- Rachel Lawson (Unlicensed) Train tech teams on where to document things once Google Drive goes away
Jira Legacy |
---|
server | System JIRA |
---|
serverId | f5c6bdaf-d23e-347d-a1e8-579e20a81dda |
---|
key | PRD-51 |
---|
|
- Steve Conrad Valeria Tafoya finalize BB specs format by March 3rd. Almost done
⤴ Decisions
- Agreement and alignment on sandbox purpose - Sandbox is intended for Reference Systems that are a staging-level prototype of a service, not anything approaching a production-level system
- For accelerated work, UC do not have to have Example Implementation to proceed (though these will be worked on as a higher priority)
...