...
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Objective
This document aims to cover all aspects of GovStack Specification lifecycle, including the operating procedures for the Working Groups that create specifications. It’s objective is to ensure there are clear processes for the different participants and stakeholders using, building and implementing the GovStack framework.
Underlying this process is agreement to the GovStack Model of Interoperability described in https://govstack.gitbook.io/specification/architecture-and-nonfunctional-requirements/introduction.
Updates
This document is meant to update the following documents:
References
Internal
External
Working Groups
What is a Working Group
...
Becoming a member and membership finalization
Info |
---|
Work in progress |
Who is a participant
The Contributor Code
Participating as an Individual
Participating on behalf of an organization
Process for becoming a lead
Election and resignation process
Process for becoming part of the facilitator group
Agree to the Code of Conduct
Individual Participation
Individuals representing a member organization
Special Membership Groups
...
Strategic Governance Committee
Governance Committee
...
Specifications
Info |
---|
Work in progress |
What is a specification
Scope of the GovStack architecture should be denoted referenced here
Types of specifications
...
Foundational BB
Feature BB
Cross-Cutting - Other types of requirements
Roles
Lifecycle of a specification
...
Request:
SHOULD contain a need
SHOULD contain a scope
MAY contain an outline
...
Draft
...
New version
...
Implementation cycles
Has a commited time to deliver a RFC
This can be recommited with a TC
Has maximum time before archived
Is drafted by a WG. If a draft was submitted upon
Tools and what are they for:Specifications are meant to be proposed, drafted, reviewed, released, implemented, and improved or obsoleted. The GovStack community and its governance provides the environment to all of these cycles.
...
Propose a new specification
Proposal Document
Draft
Release candidate
Using existing specifications
Implement
Feedback loops
Improving existing specifications
Request a new version
Change management
Deprecate a section properly
Obsolete a specification
The release process
View file | ||
---|---|---|
|
Submitting a release candidate
The review process
Quality Review
Technical Review
Implementability Review
Veredicting
Receiving Feedback
Publication
Release quality criteria
Sections
Versioning
Change management
Road-mapping
Tools for developing and publishing specifications
GitBook
Github
Jira
Confluence
Slack
Swagger
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
About API documentation:
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
...