GovsStack Meta Specification - Draft

Context

Underlying this process is agreement to the GovStack Model of Interoperability described in https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/introduction however we need to improve on the overall hierarchy of the Building Blocks and non-functional requirements

Working Groups

What is a Working Group

WG Creation and Dimission

Scope

Composition

Minimum tools and responsibilities

• Interviews

• Analysis of available tooling

  • A working group SHOULD have working group sessions

  • A working gorup SHOULD have members

Becoming a member and membership finalization

Specifications

What is a specification

Scope of the GovStack architecture should be denoted here

Check with Kristo:

GovStack is a Framework for interoperability

The framework is composed of components:
https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/3-govstack-architecture

• Applications (whatever a government has, DPGs)

• Building Blocks: Standards for use cases that set the bar on how different feature services must be delivered

• Protocol tools: Building-Blocks, Adaptors, Information Mediator, Workflows. The different pieces that GovStack proposes and governs for which interoperability for existing IT platforms and ecosystems can be achieved.

• Building Block software: Any software that complies with the BB standard

Types of specifications

1. Foundational BB

2. Feature BB

3. Cross-Cutting - Other types of requirements

Lifecycle of a specification

1. Request:

   • SHOULD contain a need

   • SHOULD contain a scope

   • MAY contain an outline

2. Draft

3. New version

4. Implementation cycles

Tools and what are they for:

• GitBook

• Github

• Jira

• Confluence

• Slack

• Swagger

  • Reference: https://govstack-global.atlassian.net/wiki/spaces/~615604c2bfa2c1006b775001/pages/1070235652/Fixing+links+in+marketplace#General-insights-about-the-Specs-procedure

  • About API documentation:

    • We should own a platform (swaggerhub, most likely) to manage and handle changes to guiding API’s

    • We need more control over changes to API procedures. Either we should have a standard procedure to handle exports (resolved vs unresolved) and changes. Or we should point the gitbook swagger blocks to our own GovStack owned swagger instance to avoid duplicity in Gitbook (this would be my preferred way). That would mean the APIs in SwaggerHub would also need to be versioned, mimicking version numbers on GitBook.

• Figma

• General info for each tool:

  • URL’s

  • Roles and access procedures for each

  • Related processes

  • Public documents

Changes:

• Roles:

  • Mantainers

  • Editors

• Submit a change

  • Deprecation notices should be specified whenever a numeral goes obsolete and a deprecation change log attached

Sections:

• Requesting the creation of a specification

  • A specification can be requested by a Working Group or

  • Requirements for a specification

    • A Specification Draft is assigned to a Working Group

• Drafting phase

  • Methodology to produce a draft

  • Organizational requirements to produce a draft

  • Tools and funds to produce a draft

• Assurance phase

  • Feedback loops

  • Implementers

• Publishing phase

• Roadmapping

• Versioning

• Obsoleting

• Specifications

• Guidelines

• Policies? Implementation

• Sector specific specifications

Tools and requirements for specification teams