Gettingstarted

..Getting Started.md

@@ -1,22 +1,33 @@
-# Using the Community Specification License for your Specification Development Project
+# Getting Started with the Community Specification License (CSL)
 
-## 1. Option 1 - Reference the Official Community Specification Repository
+Follow the steps below to start using the CSL for your specification development project.
+
+## Using the CSL for New Projects
 
 ### Step 1.
 
-Create a new repository and include the following files from the Community Specification 1.0 repository [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0):
+Pick one of the two adoption methods below: 
+
+**Option 1 - Adoption by Reference to the Official Community Specification Repository**
+
+*The CSL is included by reference in the Contributor License Agreement. Using this method reduces the number of non-spec files in the repository. It may also reduce the likelihood of legal or governance conflicts because the License, Governance.md, and Contributing.md texts are hosted outside the repository.* 
 
-- **Community Specification Contributor License Agreement.**  The Community Specification Contributor License Agreement is the agreement that binds participants to the legal and governance terms established for the Working Group, and it binds participants to those terms, governance, and agreements in the official Community Specification repository. This ensures consistency for all projects using these agreements and avoids the risk that the terms have been modified. 
+Create a new repository and include only the following files from the Community Specification 1.0 repository [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0):
 
-- **Scope.md.**  The Scope.md file determines the scope of your Working Group. Items beyond that scope are not subject to licensing obligations established by the Community Specification License.    
+- **[Community Specification Contributor License Agreement]()**   
+- **[Scope.md]()**     
+- **[Notices.md]()**
+- **[License.md]()**
 
-- **Notices.md.**  The Notices.md file includes information and notices about the Working Group, including contacts for code of conduct issues, patent exclusions, parties that have specifically notified the community that they are implementing the specification, and parties that have withdrawn from the Working Group.
+**Option 2 - Clone the Community Specification Repository**
 
-- **License.md.**  The License.md file includes a statement notifying people that the project is under the Community Specification License, and the license for any source code included with the specification.
+*The full text of the CSL, along with all required files, is copied into the Project repository. If using this method, take care to ensure required files such as Governance.md are not modified in a way that conflicts with the CSL.*
+
+Clone the Community Specification 1.0 repository [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0) into your new repository.
 
 ### Step 2.
 
-Fill in the required information.
+Fill in the required information in the following files:
 
 - **Scope.md.**  Complete the Scope.md file, which determines the scope of your Working Group and its patent coverage.
 
@@ -26,38 +37,54 @@ Fill in the required information.
 
 ### Step 3.
 
-Develop your specification in that repository. 
+Start developing your specification in that repository. Tip: use the CSL and/or appropriate [SPDX License Identifiers](https://spdx.dev/learn/handling-license-info/) at the top of your spec file(s).
 
-## Option 2 - Clone the Community Specification Repository
+## Adopting the CSL for Existing Projects
+
+>Note: Please consult a legal partner prior to adopting any licensing changes. Licensing issues can raise complicated IP questions that should be addressed by an experienced legal advisor.
+
+The steps below should be taken after you have reached agreement from the Working Group participants, spoken to key contributors, and consulted with a legal partner about adopting the CSL. Ideally, you will have already issued a proposal for the new license and shared the proposal with _all_ contributors to the repository. 
 
 ### Step 1.
 
-Clone the Community Specification 1.0 repository [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0) into your new repository.
+Choose a release under which the CSL will apply to all contributions. If your project is following Semver, this should be a major release number. 
 
-### Step 2.
+Provide notice - via issue, mailing list, discussion forum, and/or pull request - that Contributions to that release will be licensed under the terms of the CSL.
 
-Fill in the required information.
+### Step 2. 
 
-- **Scope.md.**  Complete the Scope.md file, which determines the scope of your Working Group and its patent coverage.
+Open a pull request to add the CSL to the repository following either Option 1 or Option 2 above. Fill in the required information as described above in Scope.md, Licenses.md, and Notices.md. 
 
-- **Notices.md.** Add the contact(s) for code of conduct issues.
+### Step 3. 
 
-- **License.md.** If any source or sample code will be included in the specification, designate a source code license in the License.md file. The default license is MIT, and you may change that to an open source license of your choosing.
+If the Project has an existing governance.md and/or contributing.md document, review and adapt these materials to follow the requirements of the CSL. 
 
-### Step 3.
+> Note: CSL depends on terms, definitions, and processes found in the Governance and Contributing documents provided in the Official Community Specification Repository. In the case of conflict between the local Governance.md file and the upstream Governance.md file, the upstream file controls.
+
+### Step 4. 
+
+Initiate 45-day specification freeze. The purpose of the spec freeze is to provide all contributors with an opportunity to exclude or withdraw from the Working Group, prior to the specification becoming an Approved Deliverable. 
+
+### Step 5.
+
+When ready, merge the pull request(s) with the required files as well as any pull requests opened to facilitate CSL adoption (e.g. amending an existing governance.md file or adding new SPDX License IDs).
+
+Create a release tag and issue a release note following typical open source best practices.
+
+### Step 6.
 
-Develop your specification in that repository. 
+Continue developing the specification in the repository, now following the CSL terms and conditions.
 
-# Best Practices.
+## Best Practices.
 
-1. **CLA bot.** Enable a CLA bot, such as EasyCLA or cla-bot, to require a **Community Specification Contributor License Agreement** be signed (either by an individual contributor or by a contributor's employer, which CLA covers the employed contributor) and in place prior to making any contribution.
+1. **Enable a CLA bot,** such as [EasyCLA]() or [cla-bot](), to require a **Community Specification Contributor License Agreement** be signed and in place prior to making any contribution. The CLA may be signed either by an individual contributor or by a contributor's employer, which CLA covers the employed contributor. 
 
-1. **Use for specifications, not code.**  Use the Community Specification License for specification development, not code.
+1. **Use for specifications, not code.**  Use the Community Specification License for specification development, not code. Code contributions are subject to the open source license selected in License.md.
 
-1. **Scope.** Draft the scope with care since it sets the outer bounds of the patent commitments participants make to the specification.  If you draft it too narrowly, you may limit the functionality of the specification, especially as the project progresses.  Draft it too broadly and it may provide a barrier to participation since participants may be unwilling to agree to potentially broad patent commitments.  For guidance on drafting an appropriate Scope, you may find [ISO's guidance (see page 5)](https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/how-to-write-standards.pdf "ISO How To Write Standards Guide") helpful.
+1. **Draft the Scope.md with care** since it sets the outer bounds of the patent commitments participants make to the specification. If you draft it too narrowly, you may limit the functionality of the specification, especially as the project progresses. Draft it too broadly and it may provide a barrier to participation since participants may be unwilling to agree to potentially broad patent commitments. For guidance on drafting an appropriate Scope, you may find [ISO's guidance (see page 5)](https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf) helpful.
 
-1.  **Specification format.**  Use the Community Specification Template to draft your specification.
+1.  **Adhere to a Specification format.** Use the Community Specification Template to draft your specification, or follow the template of an upstream SDO. Adopting and following a consistent format improves implementer experience and makes the document(s) more maintainable.
 
-1. **Develop specifications and code in separate repositories.**  Where possible, separate specifications and source code into different repositories, with the specifications under the Community Specification License and the source code under an OSI-approved open source license.  
+1. **Develop specifications and code in separate repositories.** Where possible, separate specifications and source code into different repositories, with the specifications under the Community Specification License and the source code under an OSI-approved open source license.  
 
 1. **Develop multiple specifications in separate repositories.** When developing multiple specifications, each individual specification should be in its own repository.

7._CS_Template.md

@@ -8,12 +8,12 @@ A model manuscript of a draft International Standard (known as “The Rice Model
 
 In addition, we recommend using the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" as described in RFC 2119 - https://tools.ietf.org/html/rfc2119
 
-
+ 
 ## Title
 ### Version _______
 ### Status (Pre-draft, Draft, Approved)
 
-
+ 
 © _________________
 
 This specification is subject to the Community Specification License 1.0, available at [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0).
@@ -42,7 +42,7 @@ Introduction	i
 
 6	Clause title	1
 
-Annex A (informative)
+Annex A (informative)  
 
 Bibliography	1
 
@@ -68,7 +68,7 @@ THESE MATERIALS ARE PROVIDED “AS IS.” The Contributors and Licensees express
 Introduction
 Type text.
 
-
+ 
 ## Title (Introductory element — Main element — Part : Part title)
 
 1	Scope (mandatory)
@@ -135,7 +135,7 @@ term
 
 text of the definition
 
-4	Clause title
+4	Clause title 
 
 Type text.
 
@@ -145,9 +145,9 @@ Type text.
 
 Use subclauses if required e.g. 5.1 or 5.1.1. For example:
 
-5.1	Subclause
+5.1	Subclause 
 
-5.1.1	Subclause
+5.1.1	Subclause 
 
 6	Clause title