Update project-incubation-entry-considerations.md

Signed-off-by: yacovm <yacovm@users.noreply.github.com>

guidelines/project-incubation-entry-considerations.md

@@ -2,50 +2,51 @@
 layout: default
 title: Project Incubation Entry Considerations
 parent: Guidelines
-grand_parent: Hyperledger TOC
+grand_parent: LFDT TOC
 nav_order: 3
 ---
 # Project Incubation Entry Considerations
-This document provides information to help people who are considering bringing their projects to Hyperledger for [Incubation](../governing-documents/project-lifecycle.md#incubation). Specifically, it will outline items that the TOC will take into consideration when evaluating the project, as well as, some best practices that have been followed by other projects prior to the project proposal being submitted to the TOC. Our hope is that this document will smooth the entry process for new projects being proposed. The [project proposal process](../governing-documents/project-lifecycle.md#proposal) and the [template for project proposals](https://hyperledger.github.io/hyperledger-hip/) are outlined outside of this document. The goal of Incubation within Hyperledger is to provide a space for projects that have high potential to grow in the community. Ideas should start in [Hyperledger Labs](https://labs.hyperledger.org/).
+This document provides information to help people who are considering bringing their projects to LF Decentralized Trust (hereafter "LFDT") for [Incubation](../governing-documents/project-lifecycle.md#incubation). Specifically, it will outline items that the TOC will take into consideration when evaluating the project, as well as, some best practices that have been followed by other projects prior to the project proposal being submitted to the TOC. Our hope is that this document will smooth the entry process for new projects being proposed. The [project proposal process](../governing-documents/project-lifecycle.md#proposal) and the [template for project proposals](https://LFDT.github.io/LFDT-hip/) are outlined outside of this document. The goal of Incubation within LFDT is to provide a space for projects that have high potential to grow in the community. Ideas should start in [LFDT Labs](https://labs.LFDT.org/).
 
 ## Considerations
-When considering projects that are proposed for incubation to Hyperledger, the TOC will consider the following items: codebase, maintainers, community, sponsors, legal, and overlap with existing projects. The below items are not hard and fast rules for projects being accepted. The considerations are a guide to project proposers. If you meet most of the considerations, you are most likely to be accepted. If you do not meet any of the considerations, you are most likely to not be accepted.
+When considering projects that are proposed for incubation to LFDT, the TOC will consider the following items: codebase, maintainers, community, sponsors, legal, and overlap with existing projects. The below items are not hard and fast rules for projects being accepted. The considerations are a guide to project proposers. If you meet most of the considerations, you are most likely to be accepted. If you do not meet any of the considerations, you are most likely to not be accepted.
 
-### Goal Setting
-Every project team has a vision for why they exist. The project is more likely to succeed if it sets annual goals with expected outcomes. Hyperledger Foundation's governance model allows for projects to go through an annual review process against these set goals. The goal evaluation helps the stakeholders, and the community that is invested in the project to anticipate what's coming next. This process will open-up collaboration opportunities to those having similar interests.
+### Roadmap
+A project is more likely to succeed if it publicly states its intent and estimated timelines for how the project evolves. LFDT Foundation's governance model allows for projects to go through an annual review process against its roadmap. The roadmap evaluation helps the stakeholders, and the community that is invested in the project to anticipate what's coming next. This process will open-up collaboration opportunities to those having similar interests.
 
 ### Codebase
 * Code should exist as open source software in some form. Previous accepted projects have come up through labs (e.g., Cactus, Ursa); while others previously had stand alone governance prior to joining (e.g., Besu).
-* DCO sign off should exists in the code repository. If not 100% ready, the code must be capable of becoming compliant upon entry (i.e., squash commit).
+* DCO sign off should be enforced in the code repository as it transitions to LFDT. Historical commits that existed in the repository before a decision to transition the project to LFDT was made do not need to be squashed, in order to preserve metadata.
 
 ### Maintainers
 * The project should have multiple maintainers. These maintainers need not be from different companies; however, having maintainers from different companies is seen as a positive sign. Proposals with only one maintainer have been rejected by prior TOCs.
 * The project should have demonstrable examples of POC/production uses publicly available.
 * The project should have the backing of more than one organization/individuals (i.e., the project proposers should be able to demonstrate significant, long term contribution in codebase).
 
 ### Community
-* The TOC is more likely to accept projects that have contributors familiar with open source practices. Participating in existing projects or starting in Hyperledger Labs is a great place to grow this experience.
+* The TOC is more likely to accept projects that have contributors familiar with open source practices. Contributing to existing LFDT projects or starting in LFDT Labs is a great place to grow this experience.
 
 ### Sponsors
 * Sponsors are advocates for the project. There should be more than one sponsor, and they should be from different organizations. They may or may not be committing resources to the project.
 
 ### Legal
-* Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to Hyperledger. Project names must be approved by the Hyperledger marketing committee
+* Trademark concerns – project names should not be trademarked by a contributing company or if it is, then the trademark will need to be handed over to LFDT. Project names must be approved by the LFDT marketing committee
 * Projects do not require a name prior to being submitted.
   * Codebase should be Apache 2 licensable, without encumbrances
-  * Non-Apache 2 licensed code is possible, but requires Governing board approval (Section 12 subsection d of the [Hyperledger Charter](https://www.hyperledger.org/about/charter))
+  * Non-Apache 2 licensed code is possible, but requires Governing board approval (Section 12 subsection d of the [LFDT Charter](https://www.hyperledger.org/about/charter))
   * Special examination should be given to copyleft and non-licensed code.
   * Required patent licensing issues have prevented projects from entering Incubation.
   * GPL licensing issues have prevented projects from entering Incubation.
-* If code does not already have copyright, the code should be modified to include copyright as per [Copyright and License Policy](https://wiki.hyperledger.org/display/TSC/Copyright+and+License+Policy) prior to being brought into Hyperledger.
+* If code does not already have copyright, the code should be modified to include copyright as per [Copyright and License Policy](https://wiki.hyperledger.org/display/TSC/Copyright+and+License+Policy) prior to being brought into LFDT.
 
 ### Overlap with Existing Projects
-* The TOC has mentioned that they are not interested in bringing in additional distributed ledger projects. There should be a distinct advantage for a new distributed ledger project. This will be similar for other types of projects. In general, if a project is similar to an existing project, there should be a distinct advantage that the project brings over and beyond the existing project and that this cannot be contributed directly to the existing project.
-* New projects should bring something to the table that current projects do not.  
+There should be a distinct advantage for a new distributed ledger project. In general, if a project is similar to an existing project, there should be a distinct advantage that the project brings over and beyond the existing project and that this cannot be contributed directly to the existing project.
+* New projects should bring something to the table that current projects do not.
+* Distributed ledger projects without a proven track record of adoption would not be considered.
 
 ## Best Practices
 The following best practices have been identified by previous proposals.
 
 * Discuss the new project proposal within the community prior to submitting to the TOC for consideration. You might do this through existing chat channels, mailing lists, or direct communication with members of the community.
 * Make sure that any links provided in the proposal are publicly available.
-* If you need an introduction into the Hyperledger Community, the [Learnings Material Development Working Group](https://wiki.hyperledger.org/display/LMDWG) will provide a good introduction.
+* If you need an introduction into the LFDT Community, the [Learnings Material Development Working Group](https://wiki.hyperledger.org/display/LMDWG) will provide a good introduction.