Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload draft of specification process for review #643

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
180 changes: 180 additions & 0 deletions process/OpenHW-Specification-Process.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,180 @@
# OpenHW Group Process Document: Specification Process, States and Format

## Revision History of This Document

This document describes OpenHW Group's specification process and format.

The overall approach was adopted by consensus in the TWG meeting of July 2023 based on power point presentations and other documents.
The V1.0 of this document reflects the agreements made at that meeting and adds additional details.

| Date | Revision | Notes |
| :---------- | :------ | :-------------------------------------------------------- |
| 24 Jan 2024 | 1.0.0 | Reflecting July 2023 TWG meeting materials and subsequent review on Github|

## Specification Process

### Overview

OpenHW uses a lightweight specification development process to produce specification documents (which are similar to standards documents). Such "specifications" convey, for instance:
- Protocol/functionality of an interface to ensure interoperability across the interface
- Naming convention such as mnemonic for an instruction class

This type of specification is developed and frozen in a Task Group designated by the Technical Working Group (TWG) to this task, then ratified and released (published) by TWG.

Note that this process does not refer to a "requirements specification" for an OpenHW Group project such as an open-source Core or Hardware or Software project. In that context, "requirements specification" is a list of the required features of the open-source project.

### Characteristics of the OpenHW Group Specification Process

This section describes the characteristics of the Specification Process. This is background information that explains how the process was designed. Those looking to use the process are free to skip reading this section.

#### Basics

| Number | Issue | Comment |
| :--- | :------ | :-------------------------------------------------------------------------------- |
| 1 | Nature of an OpenHW Group specification | A collective derivative work from the individual member contributions, together with staff contributions |
| 2 | Editors of the specification | OpenHW Group via its members and staff |
| 3 | Contributions by non-members | For further study |
| 4 | Eclipse Specification Process | Not used |

#### Contributions into the Specification

| Number | Issue | Comment |
| :--- | :------ | :-------------------------------------------------------------------------------- |
| 1 | Licenses accepted for contributions to OpenHW Group Specifications | |
| 1.1 | Apache 2.0 | As per OpenHW Group Member Agreement, contributions can be made using this license |
| 1.2 | Solderpad 2.1 | As per OpenHW Group Member Agreement, contributions can be made using this license |
| 1.3 | Creative Commons Attribution Share Alike 4.0 International license | Agreed by OpenHW Group CEO April 2023 |
| 2 | Patent Grant included in contribution license: | |
| 2.1 | Apache 2.0 | Yes, patent grant included in contributions |
| 2.2 | Solderpad 2.1 | Yes, patent grant included in contributions |
| 2.3 | Creative Commons Attribution Share Alike 4.0 International | No patent grant included |
| 3 | Essential patents must be disclosed by contributor | No, Contributors are not required to disclose essential patents |
| 4 | Copyright Grant included in contribution license: | |
| 4.1 | Apache 2.0 | Yes, copyright grant included in contributions |
| 4.2 | Solderpad 2.1 | Yes, copyright grant included in contributions |
| 4.3 | Creative Commons Attribution Share Alike 4.0 International | Yes, copyright grant included in contributions |
| 5 | Contribution Process | Follows Eclipse Development Process (EDP) / Committers merging pull requests / Contributors sign Eclipse Contributor Agreement (ECA) or Member Committer and Contributor Agreement (MCCA) |


#### Publication of the Specification

| Number | Issue | Comment |
| :--- | :------ | :-------------------------------------------------------------------------------- |
| 1 | Specification published by | OpenHW Group on Github and/or ReadtheDocs and/or website |
| 2 | Copyright holder on specification | OpenHW Group on behalf of contributors (members), who hold the copyright jointly. |
| 3 | License used for publication | Same license as used for contributions |
| 4 | Copyright Grant included in specification publication | As per publication license: |
| 5.1 | Apache 2.0 | Yes, copyright grant included with OpenHW Group publication |
| 5.2 | Solderpad 2.1 | Yes, copyright grant included with OpenHW Group publication |
| 5.3 | Creative Commons Attribution Share Alike 4.0 International license | Yes, copyright grant included with OpenHW Group publication |
| 6 | Patent Grant included in specification publication | As per publication license |
| 6.1 | Apache 2.0 | No patent grant provided by OpenHW but patents rights granted under contribution |
| 6.2 | Solderpad 2.1 | No patent grant provided by OpenHW but patents rights granted under contribution |
| 6.3 | Commons Attribution Share Alike 4.0 International license | No patent grant included with OpenHW publication |
| 7 | Essential patents disclosed by OpenHW | No |
| 8 | License text included within the specification text | No - referral only |
| 9 | "No-warranty" or disclaimer | Required |


### Specification Revision Numbers

OpenHW Group Specifications shall use semantic versioning https://semver.org/ with the Revision in the form X.Y.Z.
The Revision number is combined with the Specification State (below), for example "1.0.0 - Released" to indicate both the Revision number and State.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not always possible. Better to have postfixes (see semver.org) like -rc.1, -dev etc.




### Specification States

The ratification or completion State is meant to be written together with the Title and Revision in each OpenHW Group specification so that a reader will be aware of the state of completion of the Specification.
These are the OpenHW Group Specification States:

- “OpenHW Group Specification - In Development"
- "OpenHW Group Specification - In Review" (optional)
- "OpenHW Group Specification - Release Candidate"
- "OpenHW Group Specification - Released"
DBees marked this conversation as resolved.
Show resolved Hide resolved

#### "OpenHW Group Specification - In Development"

When the specification is initiated, all drafts will be entitled "OpenHW Group Specification: Title : VX.Y.Z : In Development"
DBees marked this conversation as resolved.
Show resolved Hide resolved
DBees marked this conversation as resolved.
Show resolved Hide resolved
(During initial development of the spec before first release, the Revision number is of the form X.Y.Z with X=0.)

This state is also used when a released spec is subsequently revised.

During revision of a released specification, the Revision number increments as appropriate depending on whether the revision is a major or minor update.

#### "OpenHW Group Specification - In Review"
DBees marked this conversation as resolved.
Show resolved Hide resolved

This state is optional; see the note below.

When the specification is frozen for technical review by a Task Group, all drafts will be entitled "OpenHW Group Specification: Title : VX.Y.Z : In Review"
When the TG(s) has completed its review, the reviewed and stable Revision will be relabelled as "Release Candidate" - see next section.

NOTE: This state can be bypassed if a Task Group does not require a review stage. That is, the TG can move the spec from "In Development" to "Release Candidate".


#### "OpenHW Group Specification - Release Candidate"

When the specification is proposed as a candidate for release, drafts will be entitled "OpenHW Group Specification: Title : VX.Y.Z : Release Candidate"

The Revision number used at this stage would normally be same as the proposed Revision to be released.

The Release Candidate specification will be notified as open for review to the OpenHW TWG.
Although technical comments are expected to have been resolved by the TG, comments may still be accepted at this stage.
After a suitable review period, the TWG Chair/Co-Chair will determine that the Specification is ready for ballot.


#### "OpenHW Group Specification - Released"

When a Release Candidate specification has completed ratification (through a TWG vote), the released copy will be entitled "OpenHW Group Specification: Title : VX.Y.Z : Released"
Revision numbers should be of the form X.Y.Z, normally starting with X=1 as the initially released version.

The Github commit corresponding to the Released spec will be listed on the Github page of the specification repo together with the "OpenHW Group Specification: Title : VX.Y.Z : Released" string


## Specification Format

The following sections must be included in the OpenHW Group Specification

### Title

The Title should be of the form "OpenHW Group Specification: Title : VX.Y.Z : State"

### Revision History

Prior to release a table of draft revisions should be included, which can include description of content in each draft

Upon release, the Revision History should list only released specification Revisions. That is, intermediate revisions used during development and review don't need to be listed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The revision history is generated from the releases on github. There is no control over which versions should be listed.

The table should include Revision, State, Date, and Description. The Description should include a high level description of the content.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, it is what it is. See any document for what to expect



### License

The Publication License is listed, together with a URL link to the source of the license.


The following is an example of an appropriate license statement:

"
DBees marked this conversation as resolved.
Show resolved Hide resolved
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SPDX identifier should be given, along with the recommended text from spdx.org for the given license


http://www.apache.org/licenses/LICENSE-2.0

### No-warranty
The following no-warranty text is included:

"Unless required by applicable law or agreed to in writing, this Specification and any accompanying software or hardware distributed under the License are distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License."
DBees marked this conversation as resolved.
Show resolved Hide resolved

### Copyright
The following copyright text is included:

"Copyright © YEAR OF PUBLICATION OpenHW Group. You may use, copy, modify, and distribute this work under the terms of the License, subject to the conditions specified in the License."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

copyright doesnt start with the publication, but with the development.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the second sentence here should be part of the license text, not added to a copyright statement


### Footer

In cases where the specification is rendered in PDF format, a footer should be included on each page, including "OpenHW Group Specification: Title : VX.Y.Z : State", and "Copyright © YEAR OF PUBLICATION OpenHW Group"
DBees marked this conversation as resolved.
Show resolved Hide resolved



Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing section: Filename requirementes (especially for pdf publication) - template: OpenHW_Group_Specification_Core-V_eXtension_interface_(CV-X-IF)v1.0.0, i.e. OpenHW_Group_Specification{title_with_underscores}_vX.Y.Z