Gettingstarted

..Getting Started.md

@@ -1,22 +1,43 @@
-# 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.
 
-### Step 1.
+## Adopting the CSL for New Projects
 
-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):
+### Step 1. 
 
-- **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. 
+Choose the approach that makes the most sense for your Project. Common patterns that work with open source communities include: 
 
-- **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.    
+* **For Single repo Projects** Create a Governance directory at the root of the Project repo - this should be the repo that hosts the specification. Following either Option 1 or Option 2 below, include the required files in the Governance directory.
 
-- **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.
+* **For Multi-repo Projects** Create a public repo in your Working Group's GitHub/GitLab org for your non-technical assets. This repo should host Project collateral applicable to all repos under the org, such as meeting minutes, art files, or other resources that help participants engage in the Project. Name the repo "Governance," "Community," or simply the name of your Working Group. Following either Option 1 or Option 2 below, include the required files in the new repo. 
 
-- **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.
+* **For Organizations hosting multiple Projects** Create a Governance directory at the root of the Project repo - this should be the repo that hosts the specification. Following either Option 1 or Option 2 below, include the required files in the Governance directory.
 
 ### Step 2.
 
-Fill in the required information.
+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 key texts are hosted outside the repository. This option might be best for single-repo Projects or "Umbrella" initiatives hosting multiple CSL Projects under a single organization.* 
+
+Include the following files from the Community Specification 1.0 repository [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0):
+
+- **[Community Specification Contributor License Agreement]()**   
+- **[Scope.md]()**     
+- **[Notices.md]()**
+- **[License.md]()**
+
+**Option 2 - Adoption by Cloning the Community Specification Repository**
+
+*The full text of the CSL, along with all required files, is copied into the Project repository(ies). If using this method, take care to ensure required files are not modified in a way that conflicts with the CSL. This option might be best for projects looking to customize Working Group roles or contribution procedures.*
+
+Include all files from [https://github.com/CommunitySpecification/1.0](https://github.com/CommunitySpecification/1.0). `getting-started.md`, `Readme.md`, and `07-spec-template.md` are optional files. 
+
+### Step 3.
+
+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 +47,60 @@ 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).
+
+## 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. 
 
-## Option 2 - Clone the Community Specification Repository
+### Step 0.
+
+Ensure you have the necessary rights to move the existing materials to the CSL. Work with a qualified legal partner to make sure you understand your existing licensing and agreements, and what may be needed to adopt CSL.
 
 ### 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.
+
+Continue developing the specification in the repository, now following the CSL terms and conditions.
 
-Develop your specification in that repository. 
+## Best Practices.
 
-# Best Practices.
+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. **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. **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. **Use for specifications, not code.**  Use the Community Specification License for specification development, not code.
+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. **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. **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.  **Specification format.**  Use the Community Specification Template to draft your specification.
+1. **Develop multiple specifications in separate repositories.** When developing multiple specifications, each individual specification should be in its own repository.
 
-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.  
+## Common Questions
 
-1. **Develop multiple specifications in separate repositories.** When developing multiple specifications, each individual specification should be in its own repository.
+***Should I use a CLA or DCO bot with the CSL?***

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