...
Agenda | Presenter | Duration | Discussion | ||||||||||||||||||||||||
Review pending action items | 10 minutes https://www.youtube.com/watch?v=4ASKMcdCc3g
|
| |||||||||||||||||||||||||
Status Update | Leads | https://govstack-global.atlassian.net/jira/plans/reports/6EFAz Issues to be addressed for release are tracked here: https://govstack-global.atlassian.net/jira/software/c/projects/UX/issues/TECH-825 Consent BB Finishing v2 of the spec Collaborating with the testing and Sandbox team | Kenya roadshow debrief | If there are similar takeaways from Kenya roadshow, we should create a Confluence document to track themThe company working on the tender has started delivering and are in contact with the Sandbox and Testing teams. The product delivery for testing purposes should start arriving by the end of October. This has given the team important inputs to update in the next Consent spec release . Payment BB In the process of updating the P2G workflows and APIs. Messaging BB Started with one of the candidate product for the BBs - rapidPro, to approach each other The team is building an adaptor to match the APIs from both sides. How do we onboard interested people into the BB WG? ID BB Team is working on multi step enrolment and it will be ready by the end of September. The team is getting one more system ready for demo and they’ve made 90% progress, and will have the specification ready afterwards. Sanbox team Continuing work on integrating BBs toward Unconditional Social Cash Transfer and user testing. | |||||||||||||||||||||||
GitHub process changes | 15 minutes | Slides
Rachel - There are lots of GitHub repos and members of our organisation on GitHub. We have quite a lot of the old members of the organisation set as owners. That can be problematic because they can do literally anything without warning, including accidentally deleting the organisation or all of the repos or remove another users. These members are all able to make commits to any of the repairs with impunity, go ahead and get stuck in. We want to welcome volunteer contributions, but we want to do it in a deliberate manner and make sure they can only do the things that we want them to do. We also want to be able to reliably store the right information so that we can give due recognition to all these people. We want to ensure people are following good practise; create a JIRA issue., describe what they want do, describe why they want to do it, and then reference that JIRA issue in the change request in GitBook or the pull request in GitHub. We should not be in a position where same person is able to both write something and approve it. If we will be making changes, they should be happening because two people have seen it.
Taylor - thinks we were well served by the current structure, though he wish we had moved faster. It sounds like we are ready to stop moving fast and start moving democratically. Assuming that is yes, that's where we are in our evolution... then yes to 1-6. Add two more steps to the proposed steps: 7. Branch protection rules for 8. Include a recommendation to How do we most efficiently engage external contributors? |
