diff --git a/process/PC_PL_Template_Markdown.md b/process/PC_PL_Template_Markdown.md
index bdb64af75..19ee86b88 100644
--- a/process/PC_PL_Template_Markdown.md
+++ b/process/PC_PL_Template_Markdown.md
@@ -1,23 +1,25 @@
 # OpenHW Project Concept And Project Launch Markdown Template: Instructions
-*This template is divided into two parts:*
-- *The **Project Concept (PC)** required fields are shown in the first part.*
-- *The additional **Project Launch (PL)** required and optional fields are shown in the second part.*
+<!--- This template is divided into two parts:
+- The **Project Concept (PC)** required fields are shown in the first part.
+- The additional **Project Launch (PL)** required and optional fields are shown in the second part.
 
-*Delete any sections not needed for your proposal*
-
-*The normal proposal flow is:*
-- ***The PC proposal*** *is prepared and presented to TWG. The PC proposal introduces the project and explains the market drivers and the "why"* 
-  - *TWG grants PC gate with feedback, or rejects PC gate with feedback*
-  - *If PC granted, additional work is carried out to prepare the **PL proposal***. 
-- *The **PL proposal** contains updates to the PC fields and adds additional fields. The PL proposal explains the "what" of the project.* 
-  - *For software porting projects, the PL should contain the feature list*
-  - *For IP core or other complex projects, the PL should contain a high level feature list (the user manual with feature specification is developed for the Plan Approved gate).*
+Delete any sections not needed for your proposal
 
+The normal proposal flow is:
+- ***The PC proposal*** *is prepared and presented to TWG. The PC proposal introduces the project and explains the market drivers and the "why" 
+  - TWG grants PC gate with feedback, or rejects PC gate with feedback
+  - If PC granted, additional work is carried out to prepare the **PL proposal**. 
+- The **PL proposal** contains updates to the PC fields and adds additional fields. The PL proposal explains the "what" of the project. 
+  - For software porting projects, the PL should contain the feature list
+  - For IP core or other complex projects, the PL should contain a high level feature list (the user manual with feature specification is developed for the Plan Approved gate).
+--->
 
 <hr/>
 
 ***Part 1, PC fields:***
-*The PC proposal introduces the project and explains the market drivers and the "why"* 
+<!--- 
+The PC proposal introduces the project and explains the market drivers and the "why"
+---> 
 
 # Title of Project - "CORE-V CoresProject XYZ"
 # Project Concept Proposal
@@ -55,7 +57,9 @@
 
 
 ***Part 2, PL fields:***
-*The PL proposal explains the "what". Some of it can be updated directly from the PC proposal* 
+<!--- The PL proposal explains the "what". Some of it can be updated directly from the PC proposal
+---> 
+ 
 
 # Title of Project - "CORE-V CoresProject XYZ"
 # Project Launch Proposal
@@ -67,14 +71,15 @@
 
 ### Components of the Project
 
-*Components are major project components or groups of features.*
-- *A project may have, for example, 1-10 components.*
-- *Components detail the "The what" at high level, not detailed level*
-- *Components don't consider timeline.*
-- *For example* 
-  - *Component 1 "Compiler changes for standard instructions."* 
-  - *Component 2 "Compiler changes for custom instructions"* 
-  - *Component 3 "Updates to compiler tools".*
+<!---Components are major project components or groups of features.
+- A project may have, for example, 1-10 components.
+- Components detail the "The what" at high level, not detailed level
+- Components don't consider timeline.
+- For example* 
+  - Component 1 "Compiler changes for standard instructions." 
+  - Component 2 "Compiler changes for custom instructions" 
+  - Component 3 "Updates to compiler tools".
+--->
 
 #### Component 1 Description
 #### Component 2 Description
@@ -87,10 +92,12 @@
 ## Who would make use of OpenHW output
 
 ## Summary of Timeline
-*High level view of timeline, for example timeframe for each component*
+<!---High level view of timeline, for example timeframe for each component
+--->
 
 ## Explanation of why OpenHW should do this project
-*What is the impact of doing/not doing this project on the OpenHW ecosystem. Why is OpenHW best suited to do this project*
+<!---What is the impact of doing/not doing this project on the OpenHW ecosystem. Why is OpenHW best suited to do this project
+--->
 
 ## Industry landscape: description of competing, alternative, or related efforts in the industry
 
@@ -108,33 +115,40 @@
 
 
 ## List of project technical outputs
-*This is a list of technical artifacts produced by the project*
+<!---This is a list of technical artifacts produced by the project
+--->
 
 ### Feature Requirements
-*Features are more granular than Components.* 
-*For SW porting projects, this list serves as the detailed project reference for features*
-*For IP Cores or more complext projects, a user manual with requirements specification is produced at the PA gate, which may supercede this list of features*
+<!---Features are more granular than Components.
+- For SW porting projects, this list serves as the detailed project reference for features
+- For IP Cores or more complex projects, a user manual with requirements specification is produced at the PA gate, which may supersede this list of features
+--->
 
 #### Feature 1
 #### Feature 2
 
 
 ## External dependencies
-*These are external factors on which the project depends, such as external standards ratification, external technology input, etc.*
+<!---These are external factors on which the project depends, such as external standards ratification, external technology input, etc.
+--->
 
 ## OpenHW TGs Involved
-*Which TG will be involved, such as SW, HW, Verification, etc.*
+<!---Which TG will be involved, such as SW, HW, Verification, etc.
+--->
 
 ## Resource Requirements
-*This is a list of major resources/people required to implement the project and indication of whether the resources are available*
+<!---This is a list of major resources/people required to implement the project and indication of whether the resources are available
+--->
 
 ### Engineering resource supplied by members - requirement and availability
 ### OpenHW engineering staff resource plan: requirement and availability
+
 ### Marketing resource  - requirement and availability
-### Funding for project aspects - requirement and availability 
+
 
 ## Architecture and/or context diagrams 
-*Architecture (internal blocks and interconnections), and context (depiction of the the project content within its operational context), are both encouraged where appropriate to depict functionality to both subject matter experts and to non-experts*
+<!---Architecture (internal blocks and interconnections), and context (depiction of the the project content within its operational context), are both encouraged where appropriate to depict functionality to both subject matter experts and to non-experts
+--->
 
 
 
@@ -147,8 +161,10 @@
 ## Project distribution model
 
 ## Preliminary Project plan
-*A full project plan is not required at PL. A preliminary plan, which can be for instance the schedule for completion of component or feature list, together with responsible resource, should be provided. Full details should be provided at PA gate.*
+<!---A full project plan is not required at PL. A preliminary plan, which can be for instance the schedule for completion of component or feature list, together with responsible resource, should be provided. Full details should be provided at PA gate.
+--->
 
 ## Risk Register
-*A list of known risks, for example external dependencies, and any mitigation strategy*
+<!---A list of known risks, for example external dependencies, and any mitigation strategy
+--->