Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

https://govstack-global.atlassian.net/browse/TECH-654

• Consent BB (3)

• IM BB (1)

• ID BB (2)

• Messaging BB (7)

https://govstack-global.atlassian.net/browse/TECH-670

• Scheduler BB

• Payment BB

• Messaging BB

• ID BB

• Digital Registies BB

https://govstack-global.atlassian.net/browse/TECH-742

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

The 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

@Rachel Lawson (Unlicensed)

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.

Open

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 main on bb spec repos.

8. Include a recommendation to rebase on the PR template. Are the PR templates standardised across all repos?

How do we most efficiently engage external contributors?