Update file names

Signed-off-by: Ry Jones <[email protected]>

Author: ryjones

.gitignore

@@ -1,2 +1,3 @@
 .jekyll-cache/*
 _site/*
+.DS_Store

HIPs/incubation/hedera-hashgraph.md renamed to HIPs/incubation/hiero.md

@@ -27,23 +27,23 @@ When talking about core network software we mean all projects that are needed ne
 and interact with that network.
 We want to leverage and contribute to the existing community and resources for further development and adoption across
 the Decentralized Trust ecosystem in a vendor-neutral process.
-Under the new foundation, the project will be rebranded and trademarked as `PROJECT`. 
+Under the new foundation, the project will be rebranded and trademarked as Hiero. 
 
 # Context
-`PROJECT` offers a robust decentralized ledger platform leveraging a unique consensus mechanism known as Hashgraph,
+Hiero offers a robust decentralized ledger platform leveraging a unique consensus mechanism known as Hashgraph,
 which provides asynchronous Byzantine Fault Tolerance (aBFT), making it secure, fast, and fair.
 By joining with the existing Hyperledger project under the umbrella of LF Decentralized Trust,
-`PROJECT` will aim to enhance collaboration with other blockchain and DLT projects,
+Hiero will aim to enhance collaboration with other blockchain and DLT projects,
 contribute to the open-source community, and accelerate the adoption of enterprise-grade DLT solutions.
 
 # Dependent Projects
-`PROJECT` is using Hyperledger projects internally:
+Hiero is using Hyperledger projects internally:
 
 - The consensus node is using the Hyperledger Besu EVM.
 - The Mirror Node is using Web3j.
 
 # Motivation
-Hedera envisions significant mutual benefits by donating the `PROJECT` codebase to LF Decentralized Trust.
+Hedera envisions significant mutual benefits by donating the Hiero codebase to LF Decentralized Trust.
 Introducing Hedera's advanced consensus algorithm will create synergies between diverse blockchain technologies and
 promote enhanced collaboration and integration both within and outside the LF Decentralized Trust.
 Our contribution will enrich the array of open-source consensus mechanisms, bolstering the versatility and robustness
@@ -53,7 +53,7 @@ vital link to the existing Hedera ecosystem and its Web3 developer community.
 This collaboration with the Linux Foundation and its LF Decentralized Trust will also offer Hedera access to a broader
 community of enterprise developers and valuable insights into incorporating open-source governance best practices.
 
-Among the primary rationale for moving `PROJECT` to Linux Foundation’s Decentralized Trust includes:
+Among the primary rationale for moving Hiero to Linux Foundation’s Decentralized Trust includes:
 - Enhanced Collaboration: Foster cross-community collaboration with other leading blockchain projects and leverage
   the existing Hyperledger community and governance framework.
 - Increased Adoption: Accelerate enterprise adoption through Linux Foundation's established ecosystem and the
@@ -67,7 +67,7 @@ Among the primary rationale for moving `PROJECT` to Linux Foundation’s Decentr
 
 # Status
 We acknowledge that all projects entering LF Decentralized Trust start with Incubation status.
-`PROJECT` is a production-ready project with a robust 1.0 release, multiple production deployments, and a vibrant,
+Hiero is a production-ready project with a robust 1.0 release, multiple production deployments, and a vibrant,
 active community.
 Our team has meticulously reviewed the Project Incubation Exit Criteria and believes we fulfill all the requirements
 for Graduated status, with the exception of being onboarded onto Linux Foundation’s tools and build processes.
@@ -77,15 +77,15 @@ this designation immediately.
 We anticipate that this designation process will proceed swiftly if the TOC concurs that all criteria have been met.
 
 # Solution
-A `PROJECT` network is based on several individual components.
+A Hiero network is based on several individual components.
 The following diagram gives an overview of all components that are needed to run a network and interact with the network.
 
 ![Components of a network](../assets/hedera-structure.svg "Components of a network")
 
 The components shown in the diagram will be described in the following sections.
 
 ## Consensus Node
-The Consensus Node is the core software that runs a `PROJECT` network like the Hedera public network.
+The Consensus Node is the core software that runs a Hiero network like the Hedera public network.
 The node is responsible for maintaining the public ledger, processing requested transactions, holding all accounts and other entities,
 and running the Consensus Service, the Token Service, and the Smart Contract Service to fulfill service requests.
 The node is written in Java and runs on the JVM.
@@ -100,23 +100,23 @@ The node can also run additional business logic to support applications.
 A visual Explorer interface built on top of a Mirror node providing a human interface for a network.
 
 ## Exchange Rate Tool
-Tool to calculate and send the median of exchange rates from various exchanges to `PROJECT` network to
+Tool to calculate and send the median of exchange rates from various exchanges to Hiero network to
 establish the cost of transactions.
 
 ## JSON-RPC-Relay
-Allows Ethereum clients to interact with a `PROJECT` network.
+Allows Ethereum clients to interact with a Hiero network.
 This project is an implementation of the Ethereum JSON RPC APIs that delegates to both the
 Consensus and Mirror Nodes to fulfill the JSON RPC Specification.
 
 ## Client SDKs (Java, JavaScript, Go, C++, Rust, Swift)
-The SDKs for interacting with a `PROJECT` network: the official distributed consensus platform built using the
+The SDKs for interacting with a Hiero network: the official distributed consensus platform built using the
 hashgraph consensus algorithm for fast, fair, and secure transactions.
 
 ## Solo
-Solo provides a framework and associated tools for conducting end-to-end and full stack tests against a `PROJECT` network.
+Solo provides a framework and associated tools for conducting end-to-end and full stack tests against a Hiero network.
 
 ## Licenses and dependencies of the sub-projects
-All sub-projects of `PROJECT` use the Apache license V2.0 (https://www.apache.org/licenses/LICENSE-2.0.txt).
+All sub-projects of Hiero use the Apache license V2.0 (https://www.apache.org/licenses/LICENSE-2.0.txt).
 Since all the subprojects are part of separate repositories and even created in different programming languages,
 their dependencies differ. Based on that, it doesn’t make sense to provide a global list of dependencies.
 All dependencies and related licenses can be identified by automatic project analysis.
@@ -149,20 +149,20 @@ We propose the creation of the following projects and their repositories in GitH
 - `https://github.com/PROJECT/SUBPROJECT` - This repository contains the Solo CLI that today can be found at
   https://github.com/hashgraph/solo
 
-As shown, the Hedera ecosystem already contains several sub-projects that must be part of `PROJECT`.
+As shown, the Hedera ecosystem already contains several sub-projects that must be part of Hiero.
 All those sub-projects are necessary to deploy and run a full Hashgraph-based network and interact with that network.
 All the mentioned projects are currently part of the Hashgraph organization on GitHub.
 In addition to the aforementioned repositories and projects, the community and ecosystem around Hedera and its unique
 hashgraph consensus algorithm is quite extensive, and we will want to transition a number of third-party projects
-coming from the community as an initial step once `PROJECT` has been set up. 
+coming from the community as an initial step once Hiero has been set up. 
 An example of such a community project is https://github.com/OpenElements/hedera-enterprise.
 
 The https://github.com/hashgraph GitHub org contains way more projects than the ones mentioned above.
 Examples for other projects are supplemental repositories include supporting tooling to deploy and validate
 a network built using the above codebases like https://github.com/hashgraph/hedera-cli
 or https://github.com/hashgraph/full-stack-testing.
-Those repositories are part of the Hedera ecosystem and should be part of `PROJECT`, too.
-We plan to migrate all those repositories to the new `PROJECT` GitHub organization in the future.
+Those repositories are part of the Hedera ecosystem and should be part of Hiero, too.
+We plan to migrate all those repositories to the new Hiero GitHub organization in the future.
 
 ## GitHub issues
 The Hedera projects use GitHub issues today.
@@ -174,10 +174,10 @@ By transferring the repositories to the new GitHub organization all issues will
 Next to the issues, each of the repositories uses GitHub Actions for continuous integration.
 While the GitHub Action workflow definitions are stored as part of the repository, we use custom action runners on
 hardware in the Google Cloud.
-The default GitHub action runners can not be used due to the complexity of `PROJECT`, especially for the services sub-project.
-To continue the development of `PROJECT` based on best practices and continuous integration, we propose to use 
+The default GitHub action runners can not be used due to the complexity of Hiero, especially for the services sub-project.
+To continue the development of Hiero based on best practices and continuous integration, we propose to use 
 action runners provided by Hedera.
-Here we can reuse the existing ones or Hedera will provide clones that can be used by `PROJECT`.
+Here we can reuse the existing ones or Hedera will provide clones that can be used by Hiero.
 
 The Hedera Hashgraph projects define teams with specific authorities.
 Those configurations should be migrated, and maintainers and committers for each sub-project should be defined.
@@ -205,29 +205,29 @@ We will double-check all repositories to ensure that there is no commit that is
 ## HIP
 The https://github.com/hashgraph/hedera-improvement-proposal repository contains the Hedera improvement proposals (HIP)
 of Hedera.
-For `PROJECT` we need improvement proposals and a process for them, too.
+For Hiero we need improvement proposals and a process for them, too.
 Here, the HIP repo should be migrated to https://github.com/PROJECT/PROJECT-improvement-proposal.
 Today a frontend showing all HIPs is hosted at https://hips.hedera.com/.
 We propose to host a clone of that at https://NAME.PROJECT.com. 
 
 ## Build
-As you can see in this chapter, `PROJECT` contains many sub-projects that need specific build steps and infrastructure.
-Therefore, it is important to invest in `PROJECT`’s build, release, and deployment.
+As you can see in this chapter, Hiero contains many sub-projects that need specific build steps and infrastructure.
+Therefore, it is important to invest in Hiero’s build, release, and deployment.
 The goal must be to have a vendor-neutral build and release process led by LF.
 We propose to nominate a release manager by LF who is involved in the project’s transition as soon as possible.
 
 ## Slack
-With all the given sub-projects and the big community around `PROJECT`, it will be a must to have an open and easy way
+With all the given sub-projects and the big community around Hiero, it will be a must to have an open and easy way
 to communicate with the community.
-Therefore, we propose to create a `PROJECT` Slack.
+Therefore, we propose to create a Hiero Slack.
 
 ## GitHub applications
 We have several GitHub applications that are used in the repositories today.
 We propose to migrate those applications with the repositories and check, as a step in the near future,
 what can be replaced by LF best practices.
 
 # How To
-All repositories that should be transitioned to `PROJECT` have already defined an entire CI pipeline today.
+All repositories that should be transitioned to Hiero have already defined an entire CI pipeline today.
 As already mentioned, GitHub actions are used to run builds and tests for each pull request / commit in the projects.
 Since the GitHub actions are part of the repositories the full build and test workflow of all projects is
 already open today.
@@ -239,7 +239,7 @@ We support Linux, macOS, and Windows as environments for most projects.
 Only projects that already have a specific need based on their dependencies or programming language are more restricted.
 An example is the Swift SDK, which needs macOS to be built.
 
-The projects differ greatly in deployment and hosting, so `PROJECT` will contain libraries that are only
+The projects differ greatly in deployment and hosting, so Hiero will contain libraries that are only
 used as 3rd party dependencies in external projects next to full backend services and web applications.
 Each project type is described in the sections below.
 
@@ -251,8 +251,8 @@ All the tokens need to be created for the new repositories to support the releas
 ## SDKs
 All SDK projects and some other repositories provide workflows to deploy the build artifacts of a release to a global
 registry, like Maven Central or NPM, which require accounts and tokens.
-Here we propose to create new accounts and tokens in all needed registries to upload all releases done under `PROJECT`
-in new namespaces of `PROJECT`.
+Here we propose to create new accounts and tokens in all needed registries to upload all releases done under Hiero
+in new namespaces of Hiero.
 
 ## Consensus Node
 The Consensus Node project (https://github.com/hashgraph/hedera-services) defines the software that is running on each
@@ -286,7 +286,7 @@ Documentation for hosting and configuration of these services is part of the res
 - The Hashgraph Consensus Algorithm: https://www.swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf
 
 # Closure
-The successful migration of `PROJECT` to the Linux Foundation’s Decentralized Trust will be measured through
+The successful migration of Hiero to the Linux Foundation’s Decentralized Trust will be measured through
 several key metrics and outcomes.
 
 **Community Engagement and Growth**
@@ -296,7 +296,7 @@ several key metrics and outcomes.
 - Number of new distributed applications running on the network.
 
 **Adoption and Usage**
-- The number of enterprises and projects integrating or deploying `PROJECT` technology.
+- The number of enterprises and projects integrating or deploying Hiero technology.
 - Case studies and success stories showcasing the practical applications and benefits of the technology.
 
 **Release and Development Milestones**
@@ -313,7 +313,7 @@ several key metrics and outcomes.
 - Collaborative initiatives and synergy with the broader LF Decentralized Trust ecosystem.
 - Contributions to and from other open-source projects, fostering a rich, collaborative environment.
 
-By tracking these metrics and continuously engaging with the community, we can ensure that `PROJECT` thrives within
+By tracking these metrics and continuously engaging with the community, we can ensure that Hiero thrives within
 LF Decentralized Trust, driving innovation and adoption in the distributed ledger technology space.
 Any successive projects or additional initiatives stemming from this migration will be documented and tracked to ensure
 ongoing success and impact.