November 30, 2023 Technical Committee Meeting Note

Review pending agenda items

@Esther Ogunjimi

10 minutes

Feedback from other participants. Please document any feedback/action items here: Egypt Deep Dive Takeaways

• Key topics have been moved to architecture team for discussion. Will bring recommendations back to TC.

Steve - Proposed that we put together a kick off meeting for the next release where we actually define the scope of changes that we want to make in each of the building blocks. Each building block will articulate specifically what enhancements they want to make, put it in the roadmap, then we can track against it.

Status update

Leads

20 minutes

• Issues to be addressed for release are tracked here: 23Q3 - W3 Tech Review Issues

• Next release - Waiting on the final read through as couple of people needed some extra time.

• API review issues are tracked here: TECH-942: 23Q3 API Review PROPOSED - The unfinished work under this epic will be scoped and included in the roadmap for the next release next year.

eMarketplace BB

@PSRAMKUMAR

@Aare Laponin

@Ravi Prakash V

20 minutes

For Q423 release, how should we talk about procurement in the eMarketplace BB spec from a government point of view? How should this BB be updated for the next release?

Aare - Britain was referenced in the spec to support procurement by government. In European Union, specifications have been created around tendering, procurement, invoicing and have a well documented procurement taxonomy. There are five phases of procurement in public sector, planning, competition, submission, award and completion; and the whole procurement process should be transparent to avoid corruption risks.

When reviewing the eMarketplace BB spec, the key digital functionalities / data object endpoint section, there was no support for selecting a procedure in the planning phase. The term that was documented was order and this term is not used in Europe.

In the description of requirements, digital capabilities, functional requirements, end points, and data objects section; it did not capture the major things which are needed for a public procurement.

Aare suggested we put for example disclaimer that this is the first version of the spec and that we will continue updating public procurement aspect in the spec. The spec is currently tailored to the private sector procurement but GovStack spec should be fit for the purpose of public sector procurement.

Nico - the spec shows the basic between supplier and demand, and the market linkage is generically described in the later chapters. It is assumed that the procurement in the spec will not only be for B2G but also for B2B or G2B.

Regarding government procuring from business and government procuring goods; it will be difficult to implement these use cases with the European Standard.

Ravi - this specification is for eMarketplace and not a procurement platform specification. Procurement is one of the workflows that can be supported in the eMarketplace specification; it is not about procurement but, also availing government healthcare, service benefits, P2G, G2P and other use cases.

The objective is to provide a generic framework that first unifies various transaction ecosystems across various regions and domains, including EU and procurements on a common framework before standardising them. The working group used unification over standardization.

Before we can start thinking of building functional requirements for procurements, we need to first unifying all the market players, no matter what standard they are on, whether it is proprietary or open source on a common digital infrastructure. Then, we can start standardizing by analyzing all the common aspects across all those ecosystems. This is an evolutionary process, guided by strong design principles and governance as it is agnostic to region or domain.

GovStack could include unification over standardization as a core design principle because it will make the question of whether one standard is better than the other irrelevant.

This current eMarketplace specification is supporting many use cases across many domains today, including mobility, retail logistics, jobs, scholarships, financial aid, etc. And, there is nothing that is retail or domain specific about the data model as the idea was to create a common schema and generic APIs that first unify various procurement ecosystems; then, we will be able to provide a functionality that is agnostic to region or domain.

Steve - Proposed making language changes for this release that the current scope does not support government procurement processes, but that it provides some of the functionality to do so. Steve will sit with the eMarketplace team and whoever is interested to define the scope of where we want to go for the next release.

Ravi - Can we find a middle ground and say that the eMarketplace spec enables procurements, specific workflows inside procurement but, it does not define what happens behind the scenes of any platform when it receives a quotation or a bid. How the bid will be evaluated will largely remain agnostic because it was by design and the team does not have full clarity on how tenders or bids are evaluated across regions.

That it will support generic workflows like discovery of tenders or submitting a bid or awarding contract but, it will not support workflows that are specific to regions or that are platform specific. It will support some workflows and will enables innovation on either end by allowing various different types of workflows to be designed and unified on a common framework.

Wes - Having the disclaimer at the top of the spec with the current situation is what we need to do. This is not meant to invalidate the work that the eMarketplace team did or meant to suggest that there is no place that this is appropriate, it is just highlighting that this is an important gap currently. The specific changes are;

1. Adding a disclaimer probably in the description highlighting that the current building block is not intended for public sector procurement.

2. Removing the word procurement from the areas where it's being used and maybe replacing it with ordering.

3.  

Benjamin - EU Procurement Ontology ePO

Testing platform update

@Damian Borowiecki (Deactivated)

10 minutes

Custom CircleCI Steps for Candidate Application

Damian - Requirements that was needed for MiFos integration was added to the pipeline; it is about custom circle CI steps. This is the possibility for a software providers to include custom circle CI steps that are triggered before or after an actual test execution and application setup.

Trev - From a security point of view, when we are allowing custom steps to be added into the built process as what is our process. What is our review and vetting process for these changes?

Damian - We have everything set up for the building block repositories that are in GitHub.

Upcoming BB spec development opportunity for digital wallet

@PSRAMKUMAR

20 minutes

There are various interests in building a digital world from various countries but there is no specifications to clearly state the scope of work. CDPI is inviting GS for an introductory meeting.

Steve - We should define a template for bringing a suggested new area of work to GS.

Wes - We need a concrete proposal for what we are going to do and the mode of engagement with external groups.

Ramkumar - it is an explorative meeting with CDPI

OpenAPI/Swagger

@Steve Conrad

15 minutes

Documenting API Changes