1/COSS: New RFC Process #4

jimstir · 2024-02-23T02:31:50Z

Making changes to COSS to reflect new RFC process.

kaiserd

Thank you!
I left some comments inline.

Generally, we need to be more explicit about the new process, especially about the fact that "raw" lives outside of Vac's responsibility.

Mention something like:

project teams write raw specifications for their protocols and components.
The Vac RFC team may be involved in this stage already and can support writing first drafts.
when these specifications reach a certain level of maturity they enter the Vac RFC process and become RFC drafts;
this step corresponds to working group adoption in the IETF [please cite IEFT working group adoption here, linking to an IEFT document explaining this.]
We should explain that the rigorous process described in the COSS starts with a document becoming draft / getting a number.
(you have some explanation on this in the COSS already, you can merge your text with this)
explain the process from draft to stable...
you can also add that this iterative process helps identify and fix design and implementation flaws.

kaiserd · 2024-05-15T08:48:55Z

vac/1/coss.md

 New versions of the same specification will have new numbers.
 The syntax for a specification reference is:

-    <domain>/spec/<number>/<shortname>
+    <domain>/project/<number>/<shortname>


We should mention that setting vac as he project means the RFC is more generally applicable and not specific to one project. Vac is not a project.

kaiserd · 2024-05-15T08:51:00Z

vac/1/coss.md

-
-A specification has six possible states that reflect its maturity and contractual weight:
+For a specification to receive a lifecycle status,
+a new specification SHOULD be presented by the project team.


What is a project team? That term has not been introduced yet.
We should also introduce the concept of an IFT project before.

We should also mention that non-project applications are accepted, too. We should keep the process open to the whole community not limit it to IFT. We could add such applications to vac for now.

kaiserd · 2024-05-15T08:52:06Z

vac/1/coss.md

-A specification has six possible states that reflect its maturity and contractual weight:
+For a specification to receive a lifecycle status,
+a new specification SHOULD be presented by the project team.
+After discussion amongst the contributors has occurred for an unspecific amount of time,


Suggested change

After discussion amongst the contributors has occurred for an unspecific amount of time,

After discussion amongst the contributors has reached rough consensus,

Ideally cite the IETF for the definition of rough consensus.

kaiserd · 2024-06-21T14:27:16Z

vac/1/coss.md


-For example, this specification is **rfc.vac.dev/spec/1/COSS**.
+For example, this specification is **rfc.vac.dev/vac/1/COSS**.


This is the same as line 101

kaiserd · 2024-06-21T14:28:29Z

vac/1/coss.md

+
+For example, this specification is **rfc.vac.dev/vac/COSS**, 
+if the status were **raw**.
+Note that **vac** is not a project, but a service that supports a project that could live under [IFT](https://free.technology/).


Suggested change

Note that **vac** is not a project, but a service that supports a project that could live under [IFT](https://free.technology/).

Note that **vac** is not a project, but an IFT service that supports [IFT](https://free.technology/) projects.

kaiserd · 2024-06-21T14:29:53Z

vac/1/coss.md

+if the status were **raw**.
+Note that **vac** is not a project, but a service that supports a project that could live under [IFT](https://free.technology/).
+In this case, 
+a service MAY be used as the project if generally applicable rather than a specific project.


Suggested change

a service MAY be used as the project if generally applicable rather than a specific project.

RFCs under **vac** are generally applicable rather than associated with a specific project.

kaiserd · 2024-06-21T14:58:07Z

vac/1/coss.md

@@ -82,35 +82,63 @@ Primarily, COSS uses a wiki model for editing and publishing specifications text
 * Each domain is implemented as an Internet domain, hosting a wiki and optionally other communications tools.
 * Each specification is a set of wiki pages, together with comments, attached files, and other resources.
 * Important specifications may also exist as subdomains, i.e. child wikis.
+* A *project* SHOULD consist of team memebers of a working group under a specific domain.
+Non-project application MAY be considered a project if the working group has not established a formal domain.


Suggested change

Non-project application MAY be considered a project if the working group has not established a formal domain.

Non-project applications are considered if they are within the broader topic are of IFT work.

kaiserd

Thank you. Comments in-line.

kaiserd · 2024-07-03T16:17:59Z

vac/1/coss.md

+* The *domain* is the conservancy for a set of specifications.
+* The *domain* is implemented as an Internet domain. 
+* Each specification is a document together with references and attached resources.
+* A *sub-domain* consists of a members within a team under a specific domain.


I'd not mention members here.
Rather explain it abstractly similar to the domain.
The IFT specific section at the bottom will explain the IFT specific use of a sub-domain.

kaiserd · 2024-07-03T16:18:20Z

vac/1/coss.md


-
-Individuals can become members of the domain or project by completing the necessary legal clearance.
+Individuals can become members of the *sub-domain* by completing the necessary legal clearance.


This should move in to the IFT specific section in the bottom.

This was included in the original COSS as domain instead of sub-domain. Change to sub-domain is not correct, I changed back to domain.

kaiserd · 2024-07-03T16:20:39Z

vac/1/coss.md

 When the specification reaches some level of maturity,
 the specification SHOULD enter the VAC RFC process.
 Similar to the the IETF working group adoption described in [RFC6174](https://www.rfc-editor.org/rfc/rfc6174.html), 
-the VAC RFC process SHOULD facilitate all updates to the specification.
+the Vac RFC process SHOULD facilitate all updates to the specification.


As mentioned in he meeting, the IFT/Vac specific parts should move into a separate section.

This part should be general, because the COSS is a doc that can be copied by another org.
We'd only add one section that is an exception to this rule.
(We could theoretically move that in a separate doc, but having it in a section in the same doc makes it easier to process.)

kaiserd · 2024-07-03T16:23:42Z

vac/1/coss.md

@@ -28,6 +28,7 @@ It is equivalent except for some areas:
 - standards track specifications SHOULD follow a specific structure that both streamlines editing,
  and helps implementers to quickly comprehend the specification
 - specifications MUST feature a header providing specific meta information
+- domain relate to [IFT](https://free.technology/) projects and teams


This would be sub-domains?

I'd rather say: - adding a section covering the IFT specific process

Also add raws will not have numbers

kaiserd · 2024-07-03T16:27:26Z

vac/1/coss.md

@@ -139,6 +140,7 @@ Raw specifications have no contractual weight.

 When raw specifications can be demonstrated, they become **draft** specifications.
 Changes to draft specifications should be done in consultation with users.
+A number will be assigned to indicate the specification has entered the [Vac RFC](rfc.vac.dev) process.


This should be in the IFT/Vac section.
Rather say: A number will be assigned once it is promoted to draft. The IFT/Vac section will mention this the start of the Vac RFC process.

kaiserd · 2024-07-03T16:29:39Z

vac/1/coss.md


-### Specification Template
+### Specification RFC Process


Rather call the section IFT/Vac specific RFC Process.

Also add a note:
This section is specific to the IFT/Vac RFC Process. Orgs copying this process MAY adjust this to their needs..
(something like this in better phrasing)

kaiserd · 2024-07-03T16:30:48Z

vac/1/coss.md

+The RFC process will ensure that standards are met before assigning a new specification status.
+All changes, comments, and contributions SHOULD be documented.
+A service under a **domain**, [Vac RFC](rfc.vac.dev), 
+SHOULD faciliate the RFC process to assure standards are followed.



This section needs to fully spec the process.
We can do this in a follow-up PR. There is much more to it.
Should ideally also link the teams repos etc...

kaiserd · 2024-07-19T13:41:38Z

vac/1/coss.md

+This service works to help faciliate the RFC process, assuring standards are followed.
+Contributors within the service SHOULD assistant a *sub-domain* in creating a new specification, 
+editing a specification, promoting the status of a specification along with other tasks.
+When a specification reaches some level of maturity,


[...] reaches some level of maturity (agreed upon by rough consensus) [...]

kaiserd · 2024-07-19T13:44:35Z

vac/1/coss.md

+Similar to the the IETF working group adoption described in [RFC6174](https://www.rfc-editor.org/rfc/rfc6174.html), 
+the Vac RFC process SHOULD facilitate all updates to the specification.
+
+RFC specifcations are introduced by teams, 


In the context of IFT, subdomain = BU / team (for instance Nomos, Codex, Waku)

This should be introduced above

Mentioned 5 projects that currently create specifications

Status

Waku

Codex

Nimbus

Nomos

kaiserd · 2024-07-19T13:52:11Z

vac/1/coss.md

-SHOULD faciliate the RFC process to assure standards are followed.
+
+
+A number will be assigned to indicate the specification has entered the [Vac RFC](rfc.vac.dev) process.


There is more to the number:

A number will be assigned to once the specification has entered the ...

kaiserd · 2024-07-19T13:54:01Z

vac/1/coss.md

@@ -81,25 +82,25 @@ Primarily, COSS uses a wiki model for editing and publishing specifications text

 * The *domain* is the conservancy for a set of specifications.
 * The *domain* is implemented as an Internet domain. 
-* Each specification is a document together with references and attached resources.
+* Each specification is a text document together with references and attached resources.


I'd revert this to the general: document

kaiserd · 2024-07-19T13:55:51Z

vac/1/coss.md

-
+When a specification is promoted to *draft* status, 
+the number that is assigned MAY be incremental in nature 
+or random based on other factors.


random based on other factors

This is too vague.

Let's just say. A number is agreed upon by the sub-domain and the Vac process

kaiserd

LGTM Thank you :).

jimstir added 5 commits February 12, 2024 20:02

Update README.md

a59fc89

Update README.md

73a6a83

Update coss.md

0fb61c6

Update coss.md

096aa2b

Update coss.md

d060c02

jimstir marked this pull request as draft February 23, 2024 02:31

Update coss.md

67cd43d

This was referenced Mar 1, 2024

1/COSS: Proposal Add Github Usernames vacp2p/rfc#644

Closed

1/COSS: Proposal Vac Template Header vacp2p/rfc#641

Closed

1/COSS: Proposal Update Draft Delete vacp2p/rfc#654

Closed

1/COSS: Proposal for Description vacp2p/rfc#645

Closed

jimstir added 6 commits March 14, 2024 19:43

Update coss.md

e776820

Update coss.md

cc52e86

Create stagnant.svg

69b5d35

Update coss.md

eeb574a

Update stagnant.svg

f4fcf02

Update stagnant.svg

e0c840f

jimstir marked this pull request as ready for review March 14, 2024 23:59

jimstir requested a review from kaiserd March 14, 2024 23:59

jimstir added 3 commits May 13, 2024 16:37

Update coss.md

c2e363d

Delete vac/1/images/stagnant.svg

d861ee8

Update coss.md

ff0ecd2

kaiserd reviewed May 15, 2024

View reviewed changes

jimstir added 2 commits May 17, 2024 08:54

Update coss.md

89a7d14

Update coss.md

6055de9

jimstir changed the title ~~Updating COSS~~ 1/COSS: New RFC Process May 21, 2024

kaiserd reviewed Jun 21, 2024

View reviewed changes

Update coss.md

9eaf5a2

Update coss.md

01fe676

kaiserd reviewed Jul 3, 2024

View reviewed changes

jimstir added 2 commits July 4, 2024 16:58

Update coss.md

dd44368

Update coss.md

e00ad9e

kaiserd reviewed Jul 19, 2024

View reviewed changes

jimstir and others added 3 commits July 23, 2024 07:31

Update coss.md

030950b

Update coss.md

88c9fa1

Merge branch 'main' into 1-COSS

1b4a71f

kaiserd approved these changes Aug 9, 2024

View reviewed changes

jimstir merged commit ed2c68f into main Aug 9, 2024
2 checks passed

jimstir deleted the 1-COSS branch August 9, 2024 14:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

1/COSS: New RFC Process #4

1/COSS: New RFC Process #4

jimstir commented Feb 23, 2024

kaiserd left a comment

kaiserd May 15, 2024

kaiserd May 15, 2024

kaiserd May 15, 2024

kaiserd Jun 21, 2024

kaiserd Jun 21, 2024

kaiserd Jun 21, 2024

kaiserd Jun 21, 2024

kaiserd left a comment

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

jimstir Jul 4, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 3, 2024

kaiserd Jul 19, 2024

kaiserd Jul 19, 2024

kaiserd Jul 19, 2024

jimstir Jul 23, 2024

kaiserd Jul 19, 2024

kaiserd Jul 19, 2024

kaiserd Jul 19, 2024 •

edited

Loading

kaiserd left a comment

	After discussion amongst the contributors has occurred for an unspecific amount of time,
	After discussion amongst the contributors has reached rough consensus,


		For example, this specification is rfc.vac.dev/spec/1/COSS.
		For example, this specification is rfc.vac.dev/vac/1/COSS.

	Note that vac is not a project, but a service that supports a project that could live under [IFT](https://free.technology/).
	Note that vac is not a project, but an IFT service that supports [IFT](https://free.technology/) projects.

	a service MAY be used as the project if generally applicable rather than a specific project.
	RFCs under vac are generally applicable rather than associated with a specific project.

	Non-project application MAY be considered a project if the working group has not established a formal domain.
	Non-project applications are considered if they are within the broader topic are of IFT work.



		Individuals can become members of the domain or project by completing the necessary legal clearance.
		Individuals can become members of the sub-domain by completing the necessary legal clearance.

		SHOULD faciliate the RFC process to assure standards are followed.


		A number will be assigned to indicate the specification has entered the [Vac RFC](rfc.vac.dev) process.

1/COSS: New RFC Process #4

1/COSS: New RFC Process #4

Conversation

jimstir commented Feb 23, 2024

kaiserd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaiserd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kaiserd Jul 19, 2024 • edited Loading

Choose a reason for hiding this comment

kaiserd left a comment

Choose a reason for hiding this comment

kaiserd Jul 19, 2024 •

edited

Loading