Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 4 Next »

This document uses keywords in RFC2119 to denote requirement descriptors for the specifications. Please note that it should also take into account RFC8174 which updates RFC2119 by specifying that only UPPERCASE usage of the keywords have the defined special meanings.

Context

Underlying this process is agreement to the GovStack Model of Interoperability described in https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/introduction.

References

Working Groups

What is a Working Group

A Working Group (WG) is an community through which experts on an area of expertise and with an interest on governmental interoperability, convene around how to implement the GovStack model on such topic.

Scope

A Working Group provides an ongoing space for topic stakeholders to:

  1. Create specifications regarding their area of expertise

  2. Share real-world experiences and feedback regarding the implementation of existing specifications

  3. Advance minor and major changes to existing specifications

  4. Promote publicly the usage of the specifications under the trust of their working group, the promotion of real-life use cases of the specifications, and any outreach activities regarding their work

  5. Identify potential software solutions that could comply with the specifications and assess the compliance of said solutions

Even thought Working Groups are on-going, they operate under the logic of annual charters that must be renewed, so a Working Group is expected to remain active and under the same goals and facilitator teams for the running year.

Composition

A Working Group is composed by the following roles:

  • Facilitators: The team tasked with the responsibility of organizing all of the Working Group activities. Having a group of facilitators allows for the WG leads to not shoulder all of the responsibilities and workload of organizing a working group, and offers an outlet space for members that want to get involved further in their WG operations. A WG Facilitator is expected to remain active within the working group for the period

  • Members: Anyone that joins the Working Group either in a casual or more permanent fashion. Members can contribute with either their expertise, feedback, or presence through attending the Working Group events, or participating in any asynchronous activities or discussions in the Working Groups participation channels.

  • Leads: One or two people per working group who agree to the responsibility of representing the Working Group interests within the wider GovStack governance. Leads will be the main Points of Contact for a Working Group to report advances on the annual goals of a charter. If a Working Group want to submit a proposal for the creation of a new specification or on the creation of a iteration for a new version, major or minor, of an existing specification, as well as a request to obsolete an existing specification, the WG Leads will be the parties through which the Working Group will report its advances.

Minimum tools and responsibilities

The following are responsibilities and tools available to the WG facilitation team:

  • The creation of the Annual Charter: A WG will work together along with its members to propose a document that specifies the goals and scope of the working group for the year. This may include any activities they may consider. A Charter may be updated in the middle of the running year to include new objectives or update or delete existing ones according to their needs, however the document will need to be up-to-date, changes should be documented and communicated and the document should be available publicly.

  • The maintenance and upkeep of the Working Group community calendar: A calendar will be provided where all activities for the Working Group are to be recorded. The calendar will help the Working Group and the GovStack technical facilitation team to communicate the activities of the Group for outreach. It will also become the common place where all members of the community can subscribe so that they can always be informed about the activities of their group.

  • Access, administration and up-keeping of the Working Group’s communal spaces and channels: The working group facilitators will have access to several spaces that serve as the WG’s infrastructure to perform its activities. The minimum set of tools and their maintenance is as follows:

    • Slack Channel

    • Confluence webpage

    • Public Webpage

  • Some other tools are available upon request, but not limited to:

    • An online meeting platform

    • Access to the Sandbox to test the compliance of new or existing solutions

    • Access to GovStack’s swagger to create and document OpenAPI specifications

  • When in the process to write a new specification or advance an existing one to another version:

    • Access to the Gitbook

    • Access to Jira ticketing system

    • Access to GovStack’s GitHub

  • Help and assistance: As part of the GovStack wider community, a Working Group has the right to request different types of assistance to fulfill their goals. Including but not limited to:

    • The assistance of the technical facilitation team to review any work they have, answer any questions or escalate any matter to other GovStack teams through either the TC Facilitation team office hours or directly.

    • Assistance on the promotion of the WG activities and milestones through the use of GovStack’s communication channels and its relation to global and regional DPG and DPI networks.

    • Technical mentors: People outside their area of expertise that may provide support hours to solve a delimited problem. WG facilitators may request this assistance through the Technical Facilitation team.

    • Support from the GovStack institution to apply to any funding or to raise or receive donations to complete specific projects that advance the WG goals.

  • Budgeting (Experimental): The Working Group will have access to budget to complete their activities and to use it as they see fit. To request a budget the following needs to be made:

    • Project scope: All budget request should be related to activities denoted on the Annual Charter

    • Budget allocation: A detail of where the budget wants to be allocated. Examples include: Hours to hire a Lead, money to complete a compliance evaluation, event organizing expenses, etc.

    • A minute signed by members of the WG where a session was held and decisions where made about the budget request.

WG Creation and Dimission

Becoming a member and membership finalization

  • Process for becoming a lead

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 - This is up for discussion

  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

    1. Has a commited time to deliver a RFC

      1. This can be recommited with a TC

    2. Has maximum time before archived

    3. Is drafted by a WG. If a draft was submitted upon

Tools and what are they for:

  • GitBook

  • Github

  • Jira

  • Confluence

  • Slack

  • Swagger

  • 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

Glossary

Charter

The GovStack model

Specifications

  • No labels