Spell check (#1585)

* Spell check

Signed-off-by: kevburnsjr <kevburnsjr@gmail.com>

* Missed one

Signed-off-by: kevburnsjr <kevburnsjr@gmail.com>

---------

Signed-off-by: kevburnsjr <kevburnsjr@gmail.com>

docs/project_guideposts.md

@@ -2,7 +2,7 @@
 
 Guide Posts are intended to outline guiding points that have assisted past cloud native projects as they grew and matured in the cloud native ecosystem. They are NOT requirements for moving between levels, please refer to [the criteria for moving levels](https://github.com/cncf/toc/blob/main/process/graduation_criteria.md) for requirements. 
 
-Projects may leverage these as steps towards increasing contributors, adopters, maturity, etc. and in doing so may find their path towards Incubation and Graduation is more structured, clear, and achievable _however_ this is subject to each projects' implementation, design, and community. Even after projects are Graduated, they may refer back to Guide Posts as a mechanism to continue sustaining their project in a manner anticipated by their community and adopters particularly as they experience change and turnover. These are not organized by maturity level, but are presented in an ordering that is commonly experienced as projects mature and move levels.
+Projects may leverage these as steps towards increasing contributors, adopters, maturity, etc. and in doing so may find their path towards Incubation and Graduation is more structured, clear, and achievable _however_ this is subject to each project's implementation, design, and community. Even after projects are Graduated, they may refer back to Guide Posts as a mechanism to continue sustaining their project in a manner anticipated by their community and adopters particularly as they experience change and turnover. These are not organized by maturity level, but are presented in an ordering that is commonly experienced as projects mature and move levels.
 
 The community is welcome to submit PRs to improve and add additional Guide Posts based on their experiences in maturing their projects.
 
@@ -17,15 +17,15 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
   * [TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy) has many great [governance templates](https://github.com/cncf/project-template) and plenty of additional templates on [contribute.cncf.io](https://contribute.cncf.io/maintainers/templates/)
 
 * May demonstrate the application, practice, and adjustments of its governance documentation as a result of regular project operations
-  * Ensuring documented, transparent, and open decision making is a hallmark of maturing governance for any project. Contributors and community members should have access to sufficient records and decisions to understand what has occurred and why. Blogs, articles, GitHub & Slack discussions, etc. all serve as methods to demonstrate application and continued alignment with a project's governances (so long as they are not private)
+  * Ensuring documented, transparent, and open decision making is a hallmark of maturing governance for any project. Contributors and community members should have access to sufficient records and decisions to understand what has occurred and why. Blogs, articles, GitHub & Slack discussions, etc. all serve as methods to demonstrate application and continued alignment with a project's governance (so long as they are not private)
 
 * Establish and exercise contributor growth ladder or other community construct to "build the bench" of maintainers or project leaders
   * Such as a Contribution Ladder which considers succession planning and getting maintainers from multiple organizations
-  * In addition to defining how contributors may move up the ladder to roles with more responsbility, current project leaders and maintainers should identify potential contributors interested in moving up the ladder and periodically check in to support them
+  * In addition to defining how contributors may move up the ladder to roles with more responsibility, current project leaders and maintainers should identify potential contributors interested in moving up the ladder and periodically check in to support them
   * Beyond just planning for one, actively exercising a growth ladder can establish a pipeline of contributors that can step forward and distribute work of existing maintainers while passing along institutional knowledge to ensure successful succession when the existing maintainers are ready for their next adventure
 
 * Experiencing successful turnover in leadership that showcases adherence to governance
-  * Governance is only beneficial when it is used and exercised, its creation is often down in at a neutral time with no pressure of outcome. It is most needed when problems arise, pressure exists on a specific outcome, and temperments may create tension and conflict in the project. Establishing and agreed upon process prior to these problems gives the project a "cool head" and clear path forward
+  * Governance is only beneficial when it is used and exercised, its creation is often down in at a neutral time with no pressure of outcome. It is most needed when problems arise, pressure exists on a specific outcome, and temperaments may create tension and conflict in the project. Establishing an agreed upon process prior to these problems gives the project a "cool head" and clear path forward
 
 * Regularly update governance documentation to accurately reflect changes to processes, staffing, roles, and activities as they occur
   * May re-review as new maintainers come in or as other's move to Emeritus
@@ -34,7 +34,7 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
 * Refreshing long-term planning with a reasonable cadence
   * Long term planning can be a roadmap, vision/feature goals, GitHub project board, etc
   * Long term planning is an open and transparent effort by the project to describe their intended future work and is subject to change
-  * Long term planning is leveraged as part of the evaluation for moving levels, it is often leveraged by potential adopters to schedule or plan for adoption if a particular feature is wanted, and also helps communitiy members identify where they can contribture or align their interests
+  * Long term planning is leveraged as part of the evaluation for moving levels, it is often leveraged by potential adopters to schedule or plan for adoption if a particular feature is wanted, and also helps community members identify where they can contribute or align their interests
 
 ### Contributors and community
 
@@ -48,8 +48,8 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
   * Constructive and welcoming feedback on PRs and issues allows for a positive first experience with a project and can increase the probability of a contributor returning
 
 * Increasing regular contributors to the project
-  * Such as identifying potentional contributors from different organizations beyond the current adopters
+  * Such as identifying potential contributors from different organizations beyond the current adopters
-  * Setting goals to identify contributors that would be wonderful maintainters, and partnering with them to onboard or prepare for that role
+  * Setting goals to identify contributors that would be wonderful maintainers, and partnering with them to onboard or prepare for that role
 
 * A second organization begins contributing
   * Those contributions may begin path to maintainership
@@ -60,10 +60,10 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
   * TAGs also support projects in navigating the moving levels process and often provide the TOC with domain specific context about a given project that supports the technical due diligence performed by the TOC
 
 * Engaging with a few Technical Advisory Groups to consider best practices across multiple technical and governance facets
-  * Socializing a project with TAGs outside the project's domain area can increase exposure of the project to more potentially interested individuals. This can also identify areas of potential integration which can improve the adopter experience or even provide ideas that allow a project to be competitve in the ecosystem
+  * Socializing a project with TAGs outside the project's domain area can increase exposure of the project to more potentially interested individuals. This can also identify areas of potential integration which can improve the adopter experience or even provide ideas that allow a project to be competitive in the ecosystem
 
 * Contribution and community documentation clearly defines expectations when contributing (to include non-code contributions)
-  * Expectations when contributing could be as simple as providing an overview of what happens after they submit a PR (review, discussion, etc.). They can also be more detailed and outline a variety of mechanisms by which someone can contribute to the project, like triaging issues, updating docs, facillitating community meetings, etc
+  * Expectations when contributing could be as simple as providing an overview of what happens after they submit a PR (review, discussion, etc.). They can also be more detailed and outline a variety of mechanisms by which someone can contribute to the project, like triaging issues, updating docs, facilitating community meetings, etc
 
 * Defined a process for managing the conduct of its community, either establishing its own group to do this, leveraging the existing leadership, or deferring to the CNCF
   * Every CNCF project adopts the Code of Conduct, however each project may choose to establish a group dedicated to promoting adherence and embodiment of the code of conduct. Projects may find that a dedicated group in this area can also provide additional support in promoting an inclusive and welcoming community
@@ -77,7 +77,7 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
   * Many projects will initially begin with more frequent releases, sometimes once a month or once a quarter, it just depends on the project. Expect to adjust the frequency of releases as the project continues to mature, becoming more stable and robust with less active development
 
 * Documentation includes getting started guides, operating/administration instruction, security call-outs, and other core elements necessary to ease adoption
-  * As project maintainers, we're often very close to the project and know all the ins and outs. Ensuring our project documentation is robust, easy to understand, and makes no assumptions about the expected experitse or skill level of a potential adopter or contributor allows the project to more readily be understood, tested, and adopted. Consider having someone not familiar with the project review project documentation and provide feedback
+  * As project maintainers, we're often very close to the project and know all the ins and outs. Ensuring our project documentation is robust, easy to understand, and makes no assumptions about the expected expertise or skill level of a potential adopter or contributor allows the project to more readily be understood, tested, and adopted. Consider having someone not familiar with the project review project documentation and provide feedback
 
 * Providing information on performance and scalability for deployment options/configurations, autoscaling, or providing benchmarks in these areas for comparison or evaluation
   * Many adopters appreciate performance and scalability information as it allows them to understand more readily what they are getting into. It also gives them a reasonable understanding if their deployment is configured and performing correctly or if there are other issues. It may also support their transition from an existing solution to a more performant and competitive open source project
@@ -88,7 +88,7 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
 
 * Ensuring all sub-projects are clearly defined in their maturity level, whether they ship with the core project or can be used independently but is subject to the same governance processes
   * Providing statuses of sub-projects and their definitions (alpha, beta, stable, unstable, experimental, etc) can provide adopters with a very clear understanding of what to expect when they adopt or configure a sub-project
-  * Distinguishing between which sub-projects are packaged up or included by a project's artifacts allows adopters to understand what features and capabilities are included in the project and enables them to add sub-projects as-needed to suite their needs. It also allows the project to assert what has and hasnt been done or enforced on a sub-project, to remove assumptions on its security posture, trust boundary, and performance capabilities
+  * Distinguishing between which sub-projects are packaged up or included by a project's artifacts allows adopters to understand what features and capabilities are included in the project and enables them to add sub-projects as-needed to suite their needs. It also allows the project to assert what has and hasn't been done or enforced on a sub-project, to remove assumptions on its security posture, trust boundary, and performance capabilities
 
 * Maintains or provides a dependency graph so adopters fully understand the complexity and risk of use
   * Dependency graphs can provide maintainers with insights into new features or bugs introduced by their dependencies which may impact a projects stability, performance, and security posture. They also provide a more comprehensive understanding of what packages a project depends on and how the project is constructed. This also allows adopters to know what they are getting _without installing the software_ to ensure it aligns with their organization's policies for licensing and dependencies
@@ -104,7 +104,7 @@ The community is welcome to submit PRs to improve and add additional Guide Posts
     * [Joint review](https://github.com/cncf/tag-security/tree/main/assessments#components-of-the-security-review-package)
     * [OpenSSF Best Practice Badge](https://bestpractices.coreinfrastructure.org/) [Passing level](https://bestpractices.coreinfrastructure.org/en/criteria/0) or [Silver](https://bestpractices.coreinfrastructure.org/en/criteria/1)
       * Note: Completion and maintenance of **an** OpenSSF Best Practice Badge is [a requirement for graduation](../.github/ISSUE_TEMPLATE/template-graduation-application.md#required-3)
-      * The OpenSSF Best practices badging program provides a series of best practices for open source projects in increasing levels of maturity. While passing is the current criteria for Graduation projects, the current trends in industry are focusing on more secure projects and demonstrating a project's committment to security through more advanced security checks and critier, such as silver or gold best practices badging, can distinguish your project from the next.
+      * The OpenSSF Best practices badging program provides a series of best practices for open source projects in increasing levels of maturity. While passing is the current criteria for Graduation projects, the current trends in industry are focusing on more secure projects and demonstrating a project's commitment to security through more advanced security checks and criteria, such as silver or gold best practices badging, can distinguish your project from the next.
 
 ### Ecosystem
 

docs/tech_leadership_principles_guidance.md

@@ -32,7 +32,7 @@ Once escalated, the TOC Chair and/or Vice Chair will assign two TOC members to g
 
 Innovation is often born from the diversity of opinion, perspective, and experience of individuals collaborating towards a common goal or objective. Fostering an engaging and exploratory discussion, debate, and exchange of ideas to drive innovation requires a foundation of respect, grace, and curiosity so all voices may be elevated, heard, and incorporated into the discussion.
 
-Navigating conflict within a project or group to a positive resolution is achievable, even with different backgrounds and perspectives involved. The project or group's leadership is responsible for developing a culture of understanding and respect through the example they set. When conflict does occur, finding a root of agreement to begin building consensus around the problem space is essential before moving on to a solution. Many individuals come to a problem, or perceived problem, with a solution or implementation in hand, often fixated as the correct path forward. As leader, encouraging inviduals to set aside their predisposed ideas allows for the group to discover a solution together.
+Navigating conflict within a project or group to a positive resolution is achievable, even with different backgrounds and perspectives involved. The project or group's leadership is responsible for developing a culture of understanding and respect through the example they set. When conflict does occur, finding a root of agreement to begin building consensus around the problem space is essential before moving on to a solution. Many individuals come to a problem, or perceived problem, with a solution or implementation in hand, often fixated as the correct path forward. As leader, encouraging individuals to set aside their predisposed ideas allows for the group to discover a solution together.
 
 ### Building and breaking trust
 

operations/README.md

@@ -1,6 +1,6 @@
 # TOC Operations
 
-This directory contains various files, procedures, responsibilties, and expectations of TOC members. Within this folder, TOC members and the community can understand more about how the TOC conducts themselves, what work they perform and how. As the TOC continues to refine and improve its processes, this directory will be updated.
+This directory contains various files, procedures, responsibilities, and expectations of TOC members. Within this folder, TOC members and the community can understand more about how the TOC conducts themselves, what work they perform and how. As the TOC continues to refine and improve its processes, this directory will be updated.
 
 ## Operations structure
 

operations/dd-toc-guide.md

@@ -12,9 +12,9 @@ Wrapping it up: **[TOC internal review](#toc-internal-review)** | **[Public Comm
 
 ## What is due diligence?
 
-Due diligence is the process by which the TOC performs an independent review of CNCF projects to assess their posture, maturity, and adoption across a variety of technical, governance, and community focuses. The intent of the due diligence is to provide project and adopters with an independent senior technical evaluation of a project's readiness for production. Similar to how organizations have established software development processes and check points prior to software delivery or deployment that ensure the software meets the organization's goals and objectives, the due diligence is a point in time artifact of the project's acheivement for meeting the goals and objectives expected for their maturity level. By performing the due diligence on CNCF projects, the TOC supports our adopters in gaining confidence that the project has been reviewed against documented criteria for their maturity level, can understand any deviations from those criteria, and may not need to repeat this type of evaluation, rather they may incorporate or leverage the contents of the due diligence to guide and information their decision making. It also conveys to adopters the potential level of effort in adopting and integrating the project into their archicture and infrastructure.  For projects, the due diligence provides an evaluation of the project against the expectations of adopters across multiple focuses. It can and often will include additional recommendations to the project that may support them in reaching the next level of maturity, improving their documentation or architecture, and in some cases highlight opportunities to distinguish themselves and their features or functionality from other projects within the same area.
+Due diligence is the process by which the TOC performs an independent review of CNCF projects to assess their posture, maturity, and adoption across a variety of technical, governance, and community focuses. The intent of the due diligence is to provide project and adopters with an independent senior technical evaluation of a project's readiness for production. Similar to how organizations have established software development processes and check points prior to software delivery or deployment that ensure the software meets the organization's goals and objectives, the due diligence is a point in time artifact of the project's achievement for meeting the goals and objectives expected for their maturity level. By performing the due diligence on CNCF projects, the TOC supports our adopters in gaining confidence that the project has been reviewed against documented criteria for their maturity level, can understand any deviations from those criteria, and may not need to repeat this type of evaluation, rather they may incorporate or leverage the contents of the due diligence to guide and information their decision making. It also conveys to adopters the potential level of effort in adopting and integrating the project into their architecture and infrastructure.  For projects, the due diligence provides an evaluation of the project against the expectations of adopters across multiple focuses. It can and often will include additional recommendations to the project that may support them in reaching the next level of maturity, improving their documentation or architecture, and in some cases highlight opportunities to distinguish themselves and their features or functionality from other projects within the same area.
 
-Due Diligence is typically conducted when a project has applied to move levels, after the project completes and asserts their adherence to the criteria for the level they are seeking to move to. For example, an incubating project must complete the graduation criteria before applying to graduate. Part of the TOC's responsiblity is to not only independently verify those assertions, but to understand those assertions in the context of the individual project, its domain, its interoperability, and subsequent alignment with the Foundation, ecosystem, adopters, and overall industry.
+Due Diligence is typically conducted when a project has applied to move levels, after the project completes and asserts their adherence to the criteria for the level they are seeking to move to. For example, an incubating project must complete the graduation criteria before applying to graduate. Part of the TOC's responsibility is to not only independently verify those assertions, but to understand those assertions in the context of the individual project, its domain, its interoperability, and subsequent alignment with the Foundation, ecosystem, adopters, and overall industry.
 
 The criteria for moving levels sets the expectations for what projects are to complete prior to applying for the next level. Criteria are outcome oriented and have been developed to provide projects with maximum flexibility in implementation while demonstrating the characteristics and hallmarks of maturing projects. TOC members may exercise their discretion in evaluating conformance to the criteria, however deviations, waivers, and exceptions should be clearly articulated and reasoned such that the desired outcome is still met through compensating mechanisms or demonstrated to not be relevant.
 
@@ -54,7 +54,7 @@ We expect all TOC members to be mindful of their obligations and timelines, whet
 
 ### Project has applied to move levels
 
-**Projects apply to move levels by submitting an Issue on the TOC repo that details their conformance to the criteria.** These Issues go into the [TOC backlog](https://github.com/orgs/cncf/projects/27/views/9) and are worked on a first-in, first-out/started basis to the extent that is reasonably practical - each TOC member has subject matter expertise in one domain or another and each TOC member serves as a liasion to a Technical Advisory Group that may or may not align with that domain. The TOC strives to align their skills and background with the project applying they are assigned to ensure they have the context to understand the project within that domain. 
+**Projects apply to move levels by submitting an Issue on the TOC repo that details their conformance to the criteria.** These Issues go into the [TOC backlog](https://github.com/orgs/cncf/projects/27/views/9) and are worked on a first-in, first-out/started basis to the extent that is reasonably practical - each TOC member has subject matter expertise in one domain or another and each TOC member serves as a liaison to a Technical Advisory Group that may or may not align with that domain. The TOC strives to align their skills and background with the project applying they are assigned to ensure they have the context to understand the project within that domain. 
 
 The issue will contain a limited set of information about the project at the time of its application, commonly asserting its conformance to the stated criteria with links to where or descriptions as to how they are implemented.
 
@@ -109,7 +109,7 @@ Once the TOC has triaged the application and found all criteria to have content,
 
 TOC members are expected to triage projects in the "new" column on the board for projects that are returning from a previous not-ready application, verify completion, and move them to the top of the ready for assignment column. 
 
-TOC members are to priortize selecting projects from the ready for assignment column over the new column to expedite the queue and make the best use of TOC time.
+TOC members are to prioritize selecting projects from the ready for assignment column over the new column to expedite the queue and make the best use of TOC time.
 
 ### TOC member(s) step forward to be assigned
 
@@ -117,13 +117,13 @@ Commonly referred to as the Project's Application Sponsor, TOC members assign th
 
 The TOC member that assigns themselves a project to sponsor the application for moving levels may request a secondary TOC member to support the due diligence according to eligibility.
 
-TOC members ready to perform due diligence a project's application will socialize this internally with the TOC to provide opportunity for other members to participate. Once a TOC member or members is determined, those TOC members must assign themselves to the Issue and move the issue's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Assigned".
+TOC members ready to perform due diligence a project's application will socialize this internally with the TOC to provide opportunity for other members to participate. Once a TOC member or members is determined, those TOC members must assign themselves to the Issue and move the issue's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Assigned".
 
-TOC members may occassionally be contacted by projects asking the TOC member to sponsor their application to move levels. When this occurs, politely reminder projects of the TOC's first-in, first-started process and let them know it is subject to TOC availability. Follow up internally to the TOC that you were contacted and by which project so we may all be aware of which projects are reaching out as it may identify a backlog, timing, or communication issue.
+TOC members may occasionally be contacted by projects asking the TOC member to sponsor their application to move levels. When this occurs, politely reminder projects of the TOC's first-in, first-started process and let them know it is subject to TOC availability. Follow up internally to the TOC that you were contacted and by which project so we may all be aware of which projects are reaching out as it may identify a backlog, timing, or communication issue.
 
 #### Conflicts of interest
 
-The Due Diligence process provides several mechansims that serve as check points for bias or uncomprehensive evaluation. The public comment period is the most open and transparent point at which the community and others may indepedently review the diligence performed by the TOC.  Additionally, TOC members conduct an internal review of the due diligence to verify all aspects of the project have been thoroughly reviewed.
+The Due Diligence process provides several mechanisms that serve as check points for bias or uncomprehensive evaluation. The public comment period is the most open and transparent point at which the community and others may independently review the diligence performed by the TOC.  Additionally, TOC members conduct an internal review of the due diligence to verify all aspects of the project have been thoroughly reviewed.
 
 A TOC member will require a co-sponsor for a project if any of the following conflicts apply:
 * Hard Conflicts
@@ -145,15 +145,15 @@ Once the project is assigned to the TOC member(s), the TOC member(s) engages the
 
 Any form of communication must include _two members_ of CNCF staff to ensure consistency and continuity throughout the process. 
 
-TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchrounous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder.
+TOC members, with support from CNCF staff, should schedule a meeting with the project to the extent possible given availability and timezones. Asynchronous kick-offs can occur, but may result in additional back and forth or delays. Each Kick-off meeting should have a central kick-off document that allows the TOC and the project to capture expectations, decisions, timelines, and other pertinent references needed for successful completion of the due diligence. A [kick-off meeting template](toc-templates/template-kickoff-notes.md) is located in the [toc-templates](toc-templates/) folder.
 
 Once the Kick-off is scheduled, the TOC member(s) should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "In Due Diligence". It is *strongly* recommended that you inform the project to verify compliance with the CNCF's licensing policy (set forth in the [Section 11 of the Charter](https://github.com/cncf/foundation/blob/master/charter.md) with [additional information here](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md)).
 
 ### Completing Due Diligence
 
-NOTE: the Due Diligence can be completed in conjuction with adopter interviews, some TOC members find completion of the DD as informative to conducting interviews, but not in all cases.
+NOTE: the Due Diligence can be completed in conjunction with adopter interviews, some TOC members find completion of the DD as informative to conducting interviews, but not in all cases.
 
-The TOC will use the appropriate Due Diligence for the project's applied level as the basis for a PR ([Incubation template](toc-templates/template-dd-pr-incubation.md), [Graduation template](toc-templates/template-dd-pr-graduation.md)) and will evaluate the project's assertions in the application issue against the discoverable and publically available sites, repos, files, and other artifacts of the project. The TOC's evaluation against each criteria goes in the corresponding area of the PR template.
+The TOC will use the appropriate Due Diligence for the project's applied level as the basis for a PR ([Incubation template](toc-templates/template-dd-pr-incubation.md), [Graduation template](toc-templates/template-dd-pr-graduation.md)) and will evaluate the project's assertions in the application issue against the discoverable and publicly available sites, repos, files, and other artifacts of the project. The TOC's evaluation against each criteria goes in the corresponding area of the PR template.
 
 Previously, the project was responsible for completing the due diligence such that it allowed the TOC member(s) to review and comment. Due to the extensive back and forth in this prior process and with recent changes to the criteria, the TOC has altered the process leverage a Due Diligence PR as the TOC's assessment of the projects completion of the criteria. Therefore TOC members are expected to complete the Due Diligence PR with support from the project and TAG(s).
 
@@ -161,7 +161,7 @@ As the TOC member(s) reviews the criteria, any deviations or implementation note
 
 As an example, let's say a project is asserting their sub-projects have leadership, contribution information, maturity statuses, and add/removal processes. The TOC member(s), in confirming this may determine that the sub-projects share the same contributor file on the org's evolution directory and may change the maturity level in accordance with their documented process, but the process is not clear as to what initiates that change or who. For a sandbox project seeking incubation, this may be non-blocking but the TOC may recommend the project improve the documented process. As such, the TOC member(s) will record their finding and corresponding recommendation.
 
-Another example, if the TOC member(s) is looking over the project's stated goals and objectives that have not changed since the project was accepted into the CNCF, and they are now applying to Graduate, the TOC member(s) will ask the project to clarify or provide additional information as to why the project hasn't iniatiated any changes and if they still feel those goals and objectives are accurate for the future of the project. The TOC member(s) will then summarize the response and record it in the PR under the corresponding criteria evaluation.
+Another example, if the TOC member(s) is looking over the project's stated goals and objectives that have not changed since the project was accepted into the CNCF, and they are now applying to Graduate, the TOC member(s) will ask the project to clarify or provide additional information as to why the project hasn't initiated any changes and if they still feel those goals and objectives are accurate for the future of the project. The TOC member(s) will then summarize the response and record it in the PR under the corresponding criteria evaluation.
 
 It is expected that the TOC's evaluation of a project's completion of the criteria may reveal a mismatch in understanding or an unexpected implementation. Documenting the TOC evaluation in the Due Diligence PR provides the project, TAGs, community, adopters, and TOC with a point of reference to understand if the criteria are meeting the outcomes required of a project for a certain maturity level, or if compensating mechanisms that supplement or augment the criteria are in place that work best for that specific project.
 
@@ -173,7 +173,7 @@ Sub-projects packaged with the main project are within scope of the due diligenc
 
 #### Licensing
 
-In the course of conducting a project's due diligence, you may become aware of license isues, outstanding exception requests, or other matters concerning the licensing of the project and its dependencies. If in the course of Due Diligence you find the project appears to be missing a license exception for their code or dependencies (dynamic or staticly linked), notify the project to [file a license exception request](https://github.com/cncf/foundation/issues/new/choose). The project's application to move levels may not go to a vote until the exception has been approved, however activities such as adopter interviews and public comment may proceed. It is expected that sandbox projects, when accepted, undergo a licensing review to ensure compliance with [CNCF's licensing policy](https://github.com/cncf/foundation/blob/main/license-exceptions/README.md) and exceptions. Refer to the [allowed third party licensing policy](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md) for more information.
+In the course of conducting a project's due diligence, you may become aware of license issues, outstanding exception requests, or other matters concerning the licensing of the project and its dependencies. If in the course of Due Diligence you find the project appears to be missing a license exception for their code or dependencies (dynamic or statically linked), notify the project to [file a license exception request](https://github.com/cncf/foundation/issues/new/choose). The project's application to move levels may not go to a vote until the exception has been approved, however activities such as adopter interviews and public comment may proceed. It is expected that sandbox projects, when accepted, undergo a licensing review to ensure compliance with [CNCF's licensing policy](https://github.com/cncf/foundation/blob/main/license-exceptions/README.md) and exceptions. Refer to the [allowed third party licensing policy](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md) for more information.
 
 #### Graduated project security audits
 
@@ -185,7 +185,7 @@ If a project is a specification project such as the TUF, SPIFFE and in-toto proj
 
 ### Finalizing the Due Diligence
 
-When the TOC has finished their criteria evaluation, they should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items neededing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may be copied into the kick-off document to faciliate discussion and to provide for additional context and discussion with the project until they are finalized.
+When the TOC has finished their criteria evaluation, they should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Adopter Interviews & Project Discussion" and re-engage the project to elevate and discuss any items needing clarity, correction, or improvement. This includes notifying the project of any recommendations. Recommendations and discussion points may be copied into the kick-off document to facilitate discussion and to provide for additional context and discussion with the project until they are finalized.
 
 The TOC member(s) may then file the PR and place it in draft until the Adopter Interviews are completed.
 
@@ -237,9 +237,9 @@ Once you have summarized the interview, typically about 5 paragraphs in length d
 
 Once approval is received, the summarized content is copied into the Due Diligence PR in the appropriate section. Linking to the summary is NOT recommended as it may convey identifying information in the history if not properly access controlled which will circumvent anonymity assurances.
 
-### Summarizing the Due Diligence Evalution
+### Summarizing the Due Diligence Evaluation
 
-Once you have completed evaluating the project's implementation of the criteria and included the Adopter Interviews, you can summarize the overall evalution.
+Once you have completed evaluating the project's implementation of the criteria and included the Adopter Interviews, you can summarize the overall evaluation.
 
 Evaluation summary is composed of two parts: the Criteria and the Adoption. The evaluation summary should read like an executive summary of the due diligence, conveying any notable areas and the assessment of sufficient adoption for the level the project applied. An example structure is provided below:
 
@@ -251,7 +251,7 @@ Evaluation summary is composed of two parts: the Criteria and the Adoption. The
 
 ## TOC Internal Review
 
-Once the TOC member(s) has completed the Due Diligence, they should create a PR in their personal TOC repo and share the link with the TOC for review. The TOC member(s) should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review".
+Once the TOC member(s) has completed the Due Diligence, they should create a PR in their personal TOC repo and share the link with the TOC for review. The TOC member(s) should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "TOC Review".
 
 The TOC member(s) should craft a slack message thread that provides the project name, level applied, links to the PR and issue, and thread any additional call outs, questions, or potential issues warranting further discussion not otherwise captured in the PR. The internal review is expected to last 1 week, assuming no issues are brought up. 
 
@@ -263,16 +263,16 @@ In the event a project was not ready to move levels after the due diligence was
 
 ## Public Comment Period
 
-Assuming no issues have come up during the TOC internal review, the TOC member may put the due diligence out for public comment. The TOC member(s) should move the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Public Comment".
+Assuming no issues have come up during the TOC internal review, the TOC member may put the due diligence out for public comment. The TOC member(s) should move the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Public Comment".
  
 TOC members are to leverage the [public comment template](toc-templates/template-dd-public-comment.md) and be mindful of the timeline to consider if a freeze is in effect or soon will be. All public comment messages are to be sent on the [TOC public mailing list](https://lists.cncf.io/g/cncf-toc/topics).  Once sent, they should be linked on the PR and the project notified.
 
 ## Voting
 
-Once the public comment period is complete, the TOC member needs to adjudicate any responses and comments on the PR. Provided no new or blocking information has been shared, the TOC member should request CNCF Staff to initiate voting on the PR, at which point the project's card on the [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Voting". 
+Once the public comment period is complete, the TOC member needs to adjudicate any responses and comments on the PR. Provided no new or blocking information has been shared, the TOC member should request CNCF Staff to initiate voting on the PR, at which point the project's card on the [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) to "Voting". 
 
 TOC members, especially those who filed the PR, need to record their vote by the thumbs up or thumbs down on the PR comment where gitvote was initiated.
 
 ## Press Coordination and Completion
 
-Once voting has passed, the CNCF Staff take over the remainder of the process, coordinating press releases and announcements for the prokject. CNCF Staff will update the project' card on the  [Appliction to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) accordingly.
+Once voting has passed, the CNCF Staff take over the remainder of the process, coordinating press releases and announcements for the project. CNCF Staff will update the project' card on the  [Application to Move Levels board](https://github.com/orgs/cncf/projects/27/views/9) accordingly.

operations/onboarding.md

@@ -24,7 +24,7 @@ You will be added to both public and private slacks, mailing lists, and receive
 
 The expected time commitment of a TOC member is anywhere from **10-25% of their monthly regular work time** and will vary month to month with surges and slow downs throughout their term. TOC members should also anticipate travel to conferences and offsites at least twice a year, with participation and attendance at various meetings during the CNCF flagship conference: KubeCon+CloudNativeCon (KCCN).
 
-The TOC has four (4) hour-long meetings per month held on Tuesdays at 0800 PST/1100 EST/1700 CET.  The first meeting of each month are [Technical Advisory Group (TAG)](../tags/README.md#cncf-technical-advisory-groups-tags) updates and discussion. As a [Liaison](../../tags/cncf-tags.md#toc-liaisons) to one or more TAGs, the content presented and discussed by the TAG should be information you are already aware of. For TAGs that you are not a liaison for, this is your opportunity to become aware of the broader work being done within speciality technical domains and verticals.  It allows you to connect various TAGs and projects together, promoting interoperability for the benefit of the technical community and its adopters.
+The TOC has four (4) hour-long meetings per month held on Tuesdays at 0800 PST/1100 EST/1700 CET.  The first meeting of each month are [Technical Advisory Group (TAG)](../tags/README.md#cncf-technical-advisory-groups-tags) updates and discussion. As a [Liaison](../../tags/cncf-tags.md#toc-liaisons) to one or more TAGs, the content presented and discussed by the TAG should be information you are already aware of. For TAGs that you are not a liaison for, this is your opportunity to become aware of the broader work being done within specialty technical domains and verticals.  It allows you to connect various TAGs and projects together, promoting interoperability for the benefit of the technical community and its adopters.
 
 The second and fourth meetings are generally private meetings. During these meetings, the TOC meets to review issues on the repo, conduct vote parties (to ensure outstanding votes are completed), and discuss any open issues, activities, tasks, and other efforts. Periodically, we may invite the Maintainers, projects, or other groups to join us so we may connect with them, understand any challenges and successes they encounter, and take feedback to improve our engagements.
 
@@ -36,7 +36,7 @@ TOC members rotate meeting facilitation as often as we can to ensure the TOC Cha
 
 In the course of performing our duties, TOC members are expected to:
 
-* Lead or meaninfully contribute to at least 1 Project Due Diligence per year that is brought to TOC internal review status. The TOC Chair or Vice Chair (with support of Staff) will determine if the DD brought forward meets the TOC's DD criteria above and beyond the technical review by the TOC.
+* Lead or meaningfully contribute to at least 1 Project Due Diligence per year that is brought to TOC internal review status. The TOC Chair or Vice Chair (with support of Staff) will determine if the DD brought forward meets the TOC's DD criteria above and beyond the technical review by the TOC.
     * Some Due Diligence efforts may result in the TOC internal review stating the project is not ready after adopter interviews, these are still considered as meeting this expectation as determined by the Chair or Vice Chair. 
     * Lightweight reviews/triage of DD applications, while also required, do not meet the expectations of leading or participating in a Project DD.
 * Be available to field questions and concerns from community members and redirect as needed
@@ -88,7 +88,7 @@ There are additional social events at KCCN that TOC members are invited to as a
 
 #### TOC Offsite
 
-The TOC offsite is a relatively new event, happening at least once per year lasting about 1-2 days plus travel. It is focused time, ideally face-to-face but virtual is also an option, for the TOC to come together and perform strategic planning and operational health development of the TOC, community, TAGs, and projects. Many initiatives the TOC has had success in executing are the result of these offsites and thus highlights their importance.
+The TOC offsite is a relatively new event, happening at least once per year lasting about 1-2 days plus travel. It is focused time, ideally face-to-face but virtual is also an option, for the TOC to come together and perform strategic planning and operational health development of the TOC, community, TAGs, and projects. Many initiatives the TOC has had success in executing are the result of these off-sites and thus highlights their importance.
 
 ### Preparedness and communicating availability
 
@@ -115,7 +115,7 @@ If, for whatever reason, a TOC member feels they cannot sustain the commitment r
 
 One of the most critical aspects of the TOC is our ability to facilitate effective communication, particular among ourselves. The TOC holds many discussions over Slack. Members do their best to summarize content and may use emojis to indicate types of information for quick review or action. An effective tactic that is being normalized is:
 * `:information_source:` (light blue square with an 'i' in it) This emoji is used to indicate the content is for information only and no action is needed.
-* `:reminder_ribbon:` (yellow ribbon shaped like an open bottom figure eight) This emoji is used to indicate the content was previously provided and is providing a courtesy reminder. It usually indicates some task or action needs completed if you havent already done so. It is also used to remind members of upcoming items such as topics on an upcoming Agenda.
+* `:reminder_ribbon:` (yellow ribbon shaped like an open bottom figure eight) This emoji is used to indicate the content was previously provided and is providing a courtesy reminder. It usually indicates some task or action needs completed if you haven't already done so. It is also used to remind members of upcoming items such as topics on an upcoming Agenda.
 * `:exclamation:` (red exclamation point) This emoji is used to indicate an action is needed by the TOC, either for an individual or for the group.
 
 Emojis can be used individually or with other emojis, this usually happens to indicate a reminder has an action with it or a reminder is informational but an update may make it more topical. It is common practice to **bold** the topic immediately following the emoji for longer updates, such as summarization of a meeting.
@@ -130,7 +130,7 @@ Another element of the TOC's work is to review project applications for Sandbox
 
 ### Due Diligence (Incubating and Graduating)
 
-The primary work a TOC member engages is in conducting the due diligence of cloud native projects as they advance in their maturity, this process is commonly referred to the moving levels or maturation process. After a TOC member steps forward to sponsor a project, it is anticipated that a kick-off meeting is held to set expectations for what the process will be like, provide rough timelines, collect additional information and allow the project to ask any questions.  This kick-off is commonly conducted as a virtual meeting, not lasting more than an hour. Additionally, TOC members should anticipate a few hours of concentrated review, analysing the project, its repository(ies), and clarifying the content of the due diligence. Additional time is expected to be spent conducting and summarizing Adopter interviews to ascertain the current usage of the project within the industry.
+The primary work a TOC member engages is in conducting the due diligence of cloud native projects as they advance in their maturity, this process is commonly referred to the moving levels or maturation process. After a TOC member steps forward to sponsor a project, it is anticipated that a kick-off meeting is held to set expectations for what the process will be like, provide rough timelines, collect additional information and allow the project to ask any questions.  This kick-off is commonly conducted as a virtual meeting, not lasting more than an hour. Additionally, TOC members should anticipate a few hours of concentrated review, analyzing the project, its repository(ies), and clarifying the content of the due diligence. Additional time is expected to be spent conducting and summarizing Adopter interviews to ascertain the current usage of the project within the industry.
 
 ### Health and alignment
 
@@ -140,7 +140,7 @@ When a health or alignment concern is elevated to the TOC, TOC members should ad
 
 ## Voting
 
-The TOC primarily votes in one of two mechanisms, gitvote or on the mailing list. It is our preference that voting occur with [gitvote](https://github.com/cncf/gitvote) in the repository as this provides better transparency and is easier to verify and track vote execution. Voting conducted over the mailing list is performed by responding with a +1 Binding (+1B), or -1 Binding (-1). TOC members may abstain if they have a conflict of interest. Indication of abstention from voting for any other reason is discouraged and should not be confused with not yet voting as indication of abstention is active, not passive, and results in no vote being rendered by that individual. In the absence of information, we cannot make an informed decision, so it is imperative that we ask questions openly and provide answers with clarity for our peer TOC members, particularly on topics that may not be their strength. A vote passes with two-thirds vote of votes cast based on the charter (see [6(c)(viii)](https://www.cncf.io/about/charter)). In the rare event that an issue requiring a vote is senstive, the TOC will leverage the private mailing list to conduct the vote with the resulting decision made public.
+The TOC primarily votes in one of two mechanisms, gitvote or on the mailing list. It is our preference that voting occur with [gitvote](https://github.com/cncf/gitvote) in the repository as this provides better transparency and is easier to verify and track vote execution. Voting conducted over the mailing list is performed by responding with a +1 Binding (+1B), or -1 Binding (-1). TOC members may abstain if they have a conflict of interest. Indication of abstention from voting for any other reason is discouraged and should not be confused with not yet voting as indication of abstention is active, not passive, and results in no vote being rendered by that individual. In the absence of information, we cannot make an informed decision, so it is imperative that we ask questions openly and provide answers with clarity for our peer TOC members, particularly on topics that may not be their strength. A vote passes with two-thirds vote of votes cast based on the charter (see [6(c)(viii)](https://www.cncf.io/about/charter)). In the rare event that an issue requiring a vote is sensitive, the TOC will leverage the private mailing list to conduct the vote with the resulting decision made public.
 
 ### Impartiality and Conflicts of Interest
 
@@ -156,20 +156,20 @@ The sandbox application process identifies “Project Champions." In the past, a
 
 The sandbox voting process removes any single member’s ability to dictate preference or favoritism on accepting a project. However, discussions for voting consideration (whether a project should move to a vote or not) can be highly influential and very informative. TOC members familiar with a project or technical area can and should certainly speak to their experience and insights, while being mindful of how they're presenting information to avoid the appearance of bias. If it cannot be avoided, be sure to recuse yourself.
 
-For incubating and graduation, due to the limited number of TOC members available to sponsor the application for moving levels, Conflicts of interest on incubation and graduation are to be provided. While the identity and affiliation of the sponsor are ultiamtely irrelevant, a single sponsor could make assertions about the project without oversight up until the TOC internal review (more below). Regardless, if a perceived or real conflict is present, a secondary unconflicted TOC member is also assigned as sponsor. 
+For incubating and graduation, due to the limited number of TOC members available to sponsor the application for moving levels, Conflicts of interest on incubation and graduation are to be provided. While the identity and affiliation of the sponsor are ultimately irrelevant, a single sponsor could make assertions about the project without oversight up until the TOC internal review (more below). Regardless, if a perceived or real conflict is present, a secondary unconflicted TOC member is also assigned as sponsor. 
 
-TOC members are expected to review one-another’s work for moving levels during the internal 1-week review, as it assists in reducing biases regardless of what conflicts are perceived or claimed. It is also an opportunity to understand the project more indepth, identify any areas of that may have been missed, and to allow the TOC to make an informed voting decision.
+TOC members are expected to review one-another’s work for moving levels during the internal 1-week review, as it assists in reducing biases regardless of what conflicts are perceived or claimed. It is also an opportunity to understand the project more in depth, identify any areas of that may have been missed, and to allow the TOC to make an informed voting decision.
 
 Ultimately voting is the final arbitration to reduce bias as a result of conflict of interest and when preceded by the public comment period, it is anticipated sufficient public, non-TOC reviewers have evaluated the content presented to the community for public record and informed decision making.
 
 ## Lobbying and Direct Messages
 
-Historically, the TOC has had a problem with “lobbying”, e.g. a project approaching individual TOC members for feedback / comment, often moving on to another TOC member if they didn’t get the answer they wanted. This was particularly true for the old Sandbox model and was a key reason for changing from sponsorship to a voting model. With this in mind, TOC members should disclose to the rest of the TOC if they have been approached by a project or individual within the community or have any hard or soft conflicts of interest. It is acceptable and expected that projects or community members will reach out to the TOC for advice, however to maintain consistency in expectations, *all TOC members should be made aware of those discussions, with the opportunity to provide additional information or recommendations*. This ensures the TOC maintains a strong, clear voice to our technical communtiy, consistent with our processes, [values](https://github.com/cncf/foundation/blob/main/charter.md#3-values), [principles](../PRINCIPLES.md), and the Charter.
+Historically, the TOC has had a problem with “lobbying”, e.g. a project approaching individual TOC members for feedback / comment, often moving on to another TOC member if they didn’t get the answer they wanted. This was particularly true for the old Sandbox model and was a key reason for changing from sponsorship to a voting model. With this in mind, TOC members should disclose to the rest of the TOC if they have been approached by a project or individual within the community or have any hard or soft conflicts of interest. It is acceptable and expected that projects or community members will reach out to the TOC for advice, however to maintain consistency in expectations, *all TOC members should be made aware of those discussions, with the opportunity to provide additional information or recommendations*. This ensures the TOC maintains a strong, clear voice to our technical community, consistent with our processes, [values](https://github.com/cncf/foundation/blob/main/charter.md#3-values), [principles](../PRINCIPLES.md), and the Charter.
 
 As the TOC continues to work through updating our documentation on the repo, older references to "seeking sponsorship" may result in projects reaching out to TOC members directly to "sponsor" their project for moving levels.  When this occurs, kindly direct them to the Moving Levels resources which details how projects are recommended for promotion to the next level.  The TOC strives to pick up projects from the backlog in the order which they are recommended for promotion, while balancing alignment of TOC member expertise, liaisoning assignment, and availability of our members. 
 
 ## Public persona and engagement
 
-As a member of the TOC, you may receive requests to speak at conferences, community days or events, or even on podcasts and webcasts and contribute to or participate in panels, blogs, and articles. It is important that you are aware of the capacity that you are participating in these activities in.  Depending on the activity, particularly for conferences and community days or events facillitated by the CNCF, support may be available to allow a TOC member to attend and speak. If you are approached to do this for a CNCF facillitated event and interested, reach out to CNCF Staff.
+As a member of the TOC, you may receive requests to speak at conferences, community days or events, or even on podcasts and webcasts and contribute to or participate in panels, blogs, and articles. It is important that you are aware of the capacity that you are participating in these activities in.  Depending on the activity, particularly for conferences and community days or events facilitated by the CNCF, support may be available to allow a TOC member to attend and speak. If you are approached to do this for a CNCF facilitated event and interested, reach out to CNCF Staff.
 
 It is important that you conduct yourself in a manner expected of a Technical Leader that aligns, exemplifies, and promotes the [TOC Leadership Principles](../PRINCIPLES.md).

operations/project-health-review.md

@@ -1,17 +1,17 @@
 # Project Health Reviews
 
-The TOC may choose to review a project when a concern is registered by a community or TAG member or as a result of a health indicator, project event, or other occassion. These reviews are typically specific to the occassion that warranted them but involves researching the problem or indicator, understanding if the metric or occassion is accurate in its depiction and warrants attention, action, or other next step.
+The TOC may choose to review a project when a concern is registered by a community or TAG member or as a result of a health indicator, project event, or other occasion. These reviews are typically specific to the occassion that warranted them but involves researching the problem or indicator, understanding if the metric or occasion is accurate in its depiction and warrants attention, action, or other next step.
 
 When a project health concern is raised, the following must occur:
 - A [Project Health issue](https://github.com/cncf/toc/issues/new/choose) is created on the TOC repo
 - A TOC member is assigned to coordinate and orchestrate resolution with the project and TOC
 - The assigned TOC member engages with the project by filing an issue on their repo regarding the concern, linked to the TOC issue
 
-It is imperative that the TOC maintain documentation regarding engagements with projects to include direct messages, exchanges, and conversations with individuals. Capturing these notes, discussions, and dates is key in the event of TOC member turnover, long-standing or sporadic issues with the same project, or if additional TOC members are needed to weigh in and understand what is occurring. We strive to maintain this documentation in the open, however there are occassions where the TOC may annotate these events in private due to the sensitive nature of items under discussion. Such sensitive matters may include: lay-offs, acquisitions, or other business/proprietary decisions impacting the project.
+It is imperative that the TOC maintain documentation regarding engagements with projects to include direct messages, exchanges, and conversations with individuals. Capturing these notes, discussions, and dates is key in the event of TOC member turnover, long-standing or sporadic issues with the same project, or if additional TOC members are needed to weigh in and understand what is occurring. We strive to maintain this documentation in the open, however there are occasions where the TOC may annotate these events in private due to the sensitive nature of items under discussion. Such sensitive matters may include: lay-offs, acquisitions, or other business/proprietary decisions impacting the project.
 
 ## Initial outreach
 
-Once an issue is filed with the project regarding concerns, this initiates the first outreach to the project. Occassionally health concerns are miscommunciations or lack of clarity issues that just need sorted with the project and don't involve much beyond that. The TOC expects projects to respond to the issue files within two (2) months of filing and the TOC member MUST provide the project with a date. 
+Once an issue is filed with the project regarding concerns, this initiates the first outreach to the project. Occasionally health concerns are miscommunications or lack of clarity issues that just need sorted with the project and don't involve much beyond that. The TOC expects projects to respond to the issue files within two (2) months of filing and the TOC member MUST provide the project with a date. 
 
 For example:
 > Related: https://github.com/cncf/toc/pull/1119/files. & #147
@@ -21,7 +21,7 @@ The nature of the response determines next steps.
 
 ### No response
 
-In the event that after two months you do not receive a response, you will need to conduct a health and alignment review unless it is obvious the project is abandoned. If the project is abandonded, the TOC member should propose the project for [archive](../process/archiving.md).
+In the event that after two months you do not receive a response, you will need to conduct a health and alignment review unless it is obvious the project is abandoned. If the project is abandoned, the TOC member should propose the project for [archive](../process/archiving.md).
 
 The health and alignment review focuses on the following areas:
 - **Project scope and goals remain consistent.**
@@ -31,7 +31,7 @@ The health and alignment review focuses on the following areas:
  - What to expect: The project may hold meetings, discussions, and/or other forms of community-focused communication. The frequency of these is set by the project and should be open to the public. It is expected the project is balancing community growth with project development.
  - Verify: Check out the Project’s docs for information of meetings or community activities such as presence on CNCF calendar for metrics, meeting times/location in the project’s repo or other equivalent communication. Check if there is information on setting up development environments, this may be an indicator of progress towards incubation. Additionally, check if the number of contributors and number of contributing organizations is increasing. Review whether new contributors are core or transient and capture context. Also take note of directed efforts to grow the community. 
 - **Appropriate project governance.**
- - What to expect: The project has clearly defined governance commensurat with their maturity level that addresses the core areas needed to successfully operate the project. The project will likely have a minimal history of changes to the governance beyond initial introduction, as they may be too early to fully exercise their governance process (such as maintainer emeritus changes). This governance should capture the basics of decision making, particularly as it pertains to PR reviews and how contributors may participate in the project. More mature projects should have governance that is comprehensive and minimally meets the criteria for the current level of the project.
+ - What to expect: The project has clearly defined governance commensurate with their maturity level that addresses the core areas needed to successfully operate the project. The project will likely have a minimal history of changes to the governance beyond initial introduction, as they may be too early to fully exercise their governance process (such as maintainer emeritus changes). This governance should capture the basics of decision making, particularly as it pertains to PR reviews and how contributors may participate in the project. More mature projects should have governance that is comprehensive and minimally meets the criteria for the current level of the project.
  - Verify:  Look for changes to governance.md, readme.md, contributing.md or other governance files - such changes may be refining the governance structure, its processes, or even defining project principles, determine if the CNCF CoC is present (either through a link or as a dedicated file - and is up to date). Also verify that the governance is enforced - for example, ensure that the projects don’t merge changes without review, add maintainers without using their process, etc. If any major concerns or issues were presented, check if they were followed up on.
 - **Long-term planning exists.**
  - What to expect: The project defines long term goals, objectives, features, or releases. It is not expected the project will achieve every defined goal or objective within the timeframe or release they specify, rather that they are considering the future of the project and tracking completion of those activities. This may be extremely lightweight in the form of identifying primary components in a v1.0 release, or it may be more detailed and use project boards, milestones, and other planning flows.
@@ -60,4 +60,4 @@ In the event that the concerns are disputed, the TOC member will need to engage
 
 #### Additional Notes
 
-There may be occassions where a project is continually being reviewed for health concerns and not making substantive progress in resolving them. It is important to note that the CNCF exists for the benefits of its members. It is those members, through their elected or named individuals who define the conditions and criteria for projects to receive the benefits of the Foundation. If a project chooses to no longer meet the conditions and criteria, or apply the CNCF values, the TOC may choose to archive the project.
+There may be occasions where a project is continually being reviewed for health concerns and not making substantive progress in resolving them. It is important to note that the CNCF exists for the benefits of its members. It is those members, through their elected or named individuals who define the conditions and criteria for projects to receive the benefits of the Foundation. If a project chooses to no longer meet the conditions and criteria, or apply the CNCF values, the TOC may choose to archive the project.

operations/toc-chair-vicechair.md

@@ -2,11 +2,11 @@
 
 This document serves to provide the TOC Chair and vice chair with details on their responsibilities, role, and expectations that are in addition to those of a TOC member.
 
-## Selection and time committment
+## Selection and time commitment
 
-The TOC Chair and Vice Chair are members of the TOC that are chosen by each seated TOC to lead and represent the TOC in the execution of it's work. The expected time commitment of a TOC member who is serving as Chair and Vice Chair is roughly **20-25% of their monthly regular work time**, and may be higher or lower depending on existing community and project challenges, activity of the TOC, and other occurrences that may occupy their time (such as serving in an interim capacity on other groups). They should also anticipate travel to conferences and offsites at least twice a year, with participation and attendence at various meetings during the CNCF flagship conference: KubeCon+CloudNativeCon (KCCN).
+The TOC Chair and Vice Chair are members of the TOC that are chosen by each seated TOC to lead and represent the TOC in the execution of it's work. The expected time commitment of a TOC member who is serving as Chair and Vice Chair is roughly **20-25% of their monthly regular work time**, and may be higher or lower depending on existing community and project challenges, activity of the TOC, and other occurrences that may occupy their time (such as serving in an interim capacity on other groups). They should also anticipate travel to conferences and off-sites at least twice a year, with participation and attendance at various meetings during the CNCF flagship conference: KubeCon+CloudNativeCon (KCCN).
 
-When the TOC is fully seated, CNCF staff open an issue on the TOC repo for current TOC members to nominate themselves or others (with concurrence) for the Chair and Vice Chair. If multiple nominations for a given role (Chair or Vice Chair) are received, the selection moves to a vote. Otherwise, the nominated indidividual for each role is selected due to no other nominees.
+When the TOC is fully seated, CNCF staff open an issue on the TOC repo for current TOC members to nominate themselves or others (with concurrence) for the Chair and Vice Chair. If multiple nominations for a given role (Chair or Vice Chair) are received, the selection moves to a vote. Otherwise, the nominated individual for each role is selected due to no other nominees.
 
 ## Functions of the Chair
 
@@ -35,7 +35,7 @@ In addition to serving as the Governing Board alternate for the TOC seat, the Vi
 
 ## Governing Board Meetings
 
-When a new TOC chair is selected, the following governing board meeting the chair provides a brief introduction about themselves, their vision and principles, and provides a "state of the TOC" address. The State of the TOC address identified curent activities, challenges, and work planned or unplanned. It may include a roadmap of what the next year of the TOC looks like.
+When a new TOC chair is selected, the following governing board meeting the chair provides a brief introduction about themselves, their vision and principles, and provides a "state of the TOC" address. The State of the TOC address identified current activities, challenges, and work planned or unplanned. It may include a roadmap of what the next year of the TOC looks like.
 
 At subsequent GB meetings, the Chair will provide the GB with a status update of the TOC's work. It is recommended these updates be information with links to where interested GB members may participate or engage.
 
@@ -50,4 +50,4 @@ The TOC receives support from the CNCF to offload much of the project management
 * Ensure notes and actions are documented and issued for TOC meetings with follow-up
 * Ensure TOC meetings have a facilitator and agenda
 * Coordinate TOC Keynote and panel at KubeCon + CloudNativeCon (KCCN)
-* Facillitate status updates and traction on project applications to move levels
+* Facilitate status updates and traction on project applications to move levels

operations/toc-templates/template-dd-pr-graduation.md

@@ -45,7 +45,7 @@ N/A
 
 <!-- (TOC Evaluation goes here) --> 
 
-Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.
+Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
 
 - [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
 
@@ -205,7 +205,7 @@ N/A
 
 ## Security
 
-Note: this section may be augemented by a joint-assessment performed by TAG Security.
+Note: this section may be augmented by a joint-assessment performed by TAG Security.
 
 ### Suggested
 

operations/toc-templates/template-dd-pr-incubation.md

@@ -46,7 +46,7 @@ N/A
 
 - [ ] **Due Diligence Review.**
 
-Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.
+Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
 
 - [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
 
@@ -192,7 +192,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
 
 ## Security
 
-Note: this section may be augemented by a joint-assessment performed by TAG Security.
+Note: this section may be augmented by a joint-assessment performed by TAG Security.
 
 ### Suggested
 

operations/toc-templates/template-kickoff-notes.md

@@ -39,7 +39,7 @@ Agenda:
 
 Discussion:
 * Covered recent changes in the TOC repo for expectations and freeze
-* Covered adopter list for interviews, looking for 5-7 across multiple industries for a total of 3 final interviews to be conducted (additional on the list ensures lack of availability doesnt delay interviews)
+* Covered adopter list for interviews, looking for 5-7 across multiple industries for a total of 3 final interviews to be conducted (additional on the list ensures lack of availability doesn't delay interviews)
 
 Actions:
 * Share links to other DD for examples

process/README.md

@@ -32,7 +32,7 @@ Sandbox projects are the initial stage in the CNCF's project maturity levels. Th
 Incubating projects in the CNCF represent the middle stage of project maturity. These projects have progressed beyond the experimental phase of the Sandbox and are starting to demonstrate stability. Incubating projects exhibit a slower rate of change, with fewer breaking changes and more stable, versioned APIs. This signifies that the project's core functionality is solid, making it more reliable for production use. Importantly, this stage marks the point where the CNCF's Technical Oversight Committee (TOC) begins to actively evaluate the project's adoption. The TOC assesses the project's usefulness to interested parties, gauging its potential for wider adoption and integration within the cloud native ecosystem.
 
 **Graduation**:
-CNCF Graduated projects represent the pinnacle of project maturity within the Cloud Native Computing Foundation's ecosystem. These projects have successfully navigated the previous stage(s), demonstrating a high level of stability, functionality, and widespread adoption within their specific market area. Graduated projects are characterised by their adherence to mature and evolved practices, ensuring consistent and reliable performance. They offer a high degree of confidence to adopters and contributors alike, demonstrating stability, robust performance, comprehensive security measures, and active engagement with the community. Reaching the Graduated level signifies that the project has proven its value and is considered a reliable and trusted solution within the cloud native landscape.
+CNCF Graduated projects represent the pinnacle of project maturity within the Cloud Native Computing Foundation's ecosystem. These projects have successfully navigated the previous stage(s), demonstrating a high level of stability, functionality, and widespread adoption within their specific market area. Graduated projects are characterized by their adherence to mature and evolved practices, ensuring consistent and reliable performance. They offer a high degree of confidence to adopters and contributors alike, demonstrating stability, robust performance, comprehensive security measures, and active engagement with the community. Reaching the Graduated level signifies that the project has proven its value and is considered a reliable and trusted solution within the cloud native landscape.
 
 **Archived**:
 Archived projects are inactive or no longer recommended for use. This stage ensures the CNCF community focuses on active, impactful projects.
@@ -70,7 +70,7 @@ All exceptions and "declined" or "postponed" outcomes are handled by the TOC. Pr
 
 ### Applying to become an Incubating or Graduating project
 
-While the details of the process are described in detail further for Incubating and Graduting proposals, the high level steps that occur when a project moves levels are as follows:
+While the details of the process are described in detail further for Incubating and Graduating proposals, the high level steps that occur when a project moves levels are as follows:
 
 #### Applications to move levels are done by submitting an incubation or graduation [application issue](https://github.com/cncf/toc/issues/new/choose) on the TOC repo
 *Who: Project*
@@ -204,6 +204,6 @@ The TOC, with support from the [Technical Advisory Groups](/tags/README.md), hav
 
 Additionally, projects interested in preparing to apply to move levels are encouraged to pursue the following activities as the resulting artifacts can and often are leveraged in the TOC's completion of the Due Diligence in lieu of certain sections of the DD.
 
-* Pursue a [Goverance Review with TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy/issues/new?template=governance-review-request.yaml) - A governance review is an indepth look at how your project is governed, its documentation, its practices, and general project operations. For more information please [checkout the maintainer page on governance](https://contribute.cncf.io/maintainers/governance/overview/) or join the [Governance Review Group](https://github.com/cncf/tag-contributor-strategy/tree/main/governance).
+* Pursue a [Governance Review with TAG Contributor Strategy](https://github.com/cncf/tag-contributor-strategy/issues/new?template=governance-review-request.yaml) - A governance review is an in depth look at how your project is governed, its documentation, its practices, and general project operations. For more information please [checkout the maintainer page on governance](https://contribute.cncf.io/maintainers/governance/overview/) or join the [Governance Review Group](https://github.com/cncf/tag-contributor-strategy/tree/main/governance).
 * Complete a [General Technical Review (GTR)](../tags/resources/toc-supporting-guides/general-technical-questions.md) or [Domain Technical Review (DTR)](../tags/resources/toc-supporting-guides/tag-domain-technical-review-template.md) - these reviews provide a structured framework to explore the technical lifecycle aspects of a project experienced or sought by adopters as well as dive deep on the design and architecture of the project within its technical domain of focus. The results of these can support projects in identifying next steps to increase usability, resilience, scale, performance, and ease-of-use.
 * Collaborate with [TAG Security on a joint-review](https://github.com/cncf/tag-security/blob/main/community/assessments/guide/README.md#joint-assessment) - highly recommended for currently incubating projects, the joint review is a comprehensive assessment of a project's security, it helps project's prepare for a successful security audit.

projects/aeraki/2023-Aeraki-Mesh-annual.md

@@ -20,7 +20,7 @@ a service mesh. It supports Dubbo, Thrift, Redis, Kafka, ZooKeeper, and any prop
 can be supported as well with the help of the MetaProtocol framework.
 
 ### What does Aeraki stand for ?
-Aeraki [Air-rah-ki] is the Greek word for 'breeze'. We hope this breeze can help Kubernets and Istio
+Aeraki [Air-rah-ki] is the Greek word for 'breeze'. We hope this breeze can help Kubernetes and Istio
 sail further in the cloud native adventure.
 
 ### Why Aeraki Mesh ?
@@ -41,7 +41,7 @@ Aeraki Mesh was launched in November 2020, and was accepted into the CNCF as a S
 
 ## DevStats
 
- [Aeraki Mesh Devstats](https://aerakimesh.devstats.cncf.io/d/1/activity-repository-groups?orgId=1&var-period=d7&var-repogroups=All&from=now-1y&to=now) shows that contributions have remainded strong in the last year. Since joining the CNCF, we have attracted 13 contributors from 11 organizations including Tecent, Huawei, Microsoft, AlaudaInc, etc.
+ [Aeraki Mesh Devstats](https://aerakimesh.devstats.cncf.io/d/1/activity-repository-groups?orgId=1&var-period=d7&var-repogroups=All&from=now-1y&to=now) shows that contributions have remained strong in the last year. Since joining the CNCF, we have attracted 13 contributors from 11 organizations including Tecent, Huawei, Microsoft, AlaudaInc, etc.
 
   - [13 contributors](https://aerakimesh.devstats.cncf.io/d/22/prs-authors-table?orgId=1&var-period_name=Last%20year&var-repogroup_name=All)
   - [11 Organizations](https://aerakimesh.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=commits)

projects/akri/2022-akri-annual.md

@@ -51,7 +51,7 @@ We now have maintainers from 4 different companies.
 
 The Akri community has released five versions since joining CNCF, with 18 different contributors to these releases in total.
 
-Akri has also since participated in many CNCF talks and hosted booths at the Project Pavillion in KubeCon EU 2022 and 2023. You can view some of our talks here:
+Akri has also since participated in many CNCF talks and hosted booths at the Project Pavilion in KubeCon EU 2022 and 2023. You can view some of our talks here:
 
 - [Wasm Day 2021](https://www.youtube.com/watch?v=8hF9hnUJyCY)
 - [KubeCon EU 2022](https://www.youtube.com/watch?v=CMthyqMhuq4)

projects/artifact-hub/artifact-hub-sandbox-proposal.md

@@ -22,11 +22,11 @@ The Artifact Hub provides search and discovery for distributed artifacts. The hu
 
 ## Comparison With Similar Projects
 
-There are four classes of similar projects in existance and we will cover each along with how the Artifact Hub is different from them.
+There are four classes of similar projects in existence and we will cover each along with how the Artifact Hub is different from them.
 
 ### General Search Engines
 
-General search engines (e.g., Google and Bing) can be used to discover distributed artifacts. General search engines provide general content. Artifacts are intermixed with general content. When using search engines one needs to use more descripting language to find artifacts. Doing a search on "PostgreSQL" won't produce a Helm chart or Falco rules. You need to know to search specifically for those. General search engines also lack metadata to make it easier to figure out what to use.
+General search engines (e.g., Google and Bing) can be used to discover distributed artifacts. General search engines provide general content. Artifacts are intermixed with general content. When using search engines one needs to use more descriptive language to find artifacts. Doing a search on "PostgreSQL" won't produce a Helm chart or Falco rules. You need to know to search specifically for those. General search engines also lack metadata to make it easier to figure out what to use.
 
 The Artifact Hub provides a custom and targeted search for users. A search for "PostgreSQL" will return artifacts and display information to help end-users make decisions on what to pick. Faceted search is also available to help reduce options in a manner the end-users can choose.
 
@@ -34,15 +34,15 @@ The Artifact Hub provides a custom and targeted search for users. A search for "
 
 The [Helm Hub](https://hub.helm.sh), [OperatorHub](https://operatorhub.io/), and [Cloud Native Security Hub](https://securityhub.dev/) are examples of existing hubs. Each of these hubs is for a subset of the cloud native artifacts available. The Helm Hub lists Helm charts, the OperatorHub lists operators compatible with the Operator Frameworks Operator Lifecycle Manager (OLM), and the Cloud Native Security Hub lists Falco rules and is experimenting with Open Policy Agent policies.
 
-These hubs work a little differently from each other. The Helm Hub lists distributed Helm charts managed by various organizations (e.g., VMware, AWS, etc). The organizations register a repositry and the Helm Hub regularly fetches updates to know about changes, new, or removed charts. It is a distributed discovery mechanism. The OperatorHub lists operators that are listed in a git repository. New operators and versions need to be merged into the repository to be listed. The Cloud Native Security Hub holds the rules for Falco and is maintained by the Falco project via Sysdig.
+These hubs work a little differently from each other. The Helm Hub lists distributed Helm charts managed by various organizations (e.g., VMware, AWS, etc). The organizations register a repository and the Helm Hub regularly fetches updates to know about changes, new, or removed charts. It is a distributed discovery mechanism. The OperatorHub lists operators that are listed in a git repository. New operators and versions need to be merged into the repository to be listed. The Cloud Native Security Hub holds the rules for Falco and is maintained by the Falco project via Sysdig.
 
-The Artifact Hub most closely follows the Helm Hub as it pulls in from external locations to make finding them more accessible. This enables organizations to host their own artifacts while making them discoverable. Where it's different from the Helm Hub is that varying artifacts from different projects can be discovered and the architecutre is being built in a manner that enables new artifact types to be added. The Artifact Hub also makes self management easier than existing hubs.
+The Artifact Hub most closely follows the Helm Hub as it pulls in from external locations to make finding them more accessible. This enables organizations to host their own artifacts while making them discoverable. Where it's different from the Helm Hub is that varying artifacts from different projects can be discovered and the architecture is being built in a manner that enables new artifact types to be added. The Artifact Hub also makes self management easier than existing hubs.
 
 ### OCI Registries
 
 OCI Registries (e.g., Docker Hub) provide a means to store artifacts, usually container images but more things are being made available, and the experience around them enables discovery of the artifacts.
 
-The Artifact Hub does not host artifacts like container images or Helm charts. The artifacts are hosted by 3rd parties, like the CNCF member organizations who operate those services. The Artifact Hub is not attempting to compete with those. Instead, the Aretifact Hub is attempting to make discovering artifacts that are being stored in various services and locations more accessible.
+The Artifact Hub does not host artifacts like container images or Helm charts. The artifacts are hosted by 3rd parties, like the CNCF member organizations who operate those services. The Artifact Hub is not attempting to compete with those. Instead, the Artifact Hub is attempting to make discovering artifacts that are being stored in various services and locations more accessible.
 
 ### Package Searches For Other Platforms
 
@@ -114,7 +114,7 @@ The following list contains direct dependencies.
 
 ## Initial committers
 
-The initial committers are Sergio C. Arteaga and Cynthia S. Garcia who are the primary developers. Matt Farina (of Samsung SDS) also has commit priviledges.
+The initial committers are Sergio C. Arteaga and Cynthia S. Garcia who are the primary developers. Matt Farina (of Samsung SDS) also has commit privileges.
 
 ## Infrastructure requests
 
@@ -122,7 +122,7 @@ To host the instance of the hub software powering https://artifacthub.io/.
 
 ## Communication channels
 
-Communication is currently in CNCF Slack and primairly in the #artifact-hub room.
+Communication is currently in CNCF Slack and primarily in the #artifact-hub room.
 
 ## Issue tracker
 

projects/backstage/2021-backstage-annual.md

@@ -65,7 +65,7 @@ This is our first annual review, so we didn’t have any goals to focus on from
 
 ### Project Visibility
 
-We’d like to give more talks at conferences like KubeCon and have open office hours during these conferences to really spread the word about Backstage and provide first class support for existing or upcoming adopters. Also having access to the Project Pavillion and having our own booth at these conferences would also help us here.
+We’d like to give more talks at conferences like KubeCon and have open office hours during these conferences to really spread the word about Backstage and provide first class support for existing or upcoming adopters. Also having access to the Project Pavilion and having our own booth at these conferences would also help us here.
 
 ### Security Reviews
 

projects/brigade/2020-brigade-annual.md

@@ -33,7 +33,7 @@ This last year was arguably Brigade's most exciting, including:
 ## Annual Review Items
 
 - *Include a link to your project’s devstats page. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on devstats.*
-  - Pulling frrom the main [Brigade devstats dashboard](https://brigade.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m):
+  - Pulling from the main [Brigade devstats dashboard](https://brigade.devstats.cncf.io/d/8/dashboards?orgId=1&refresh=15m):
     - Participation from [50 companies](https://brigade.devstats.cncf.io/d/5/companies-table?orgId=1) and counting
     - [Consistent release cadence](https://brigade.devstats.cncf.io/d/47/github-events?orgId=1&from=1553666400000&to=now) of a feature release every 3-4 months since 1.0
     - Seeing an average of [5 new PRs a week](https://brigade.devstats.cncf.io/d/15/new-prs-in-repository-groups?orgId=1&from=1553666400000&to=now) in the last year

projects/brigade/brigade-sandbox-proposal.adoc

@@ -8,7 +8,7 @@ Brigade is an in-cluster runtime that interprets scripts and executes generic pi
 
 Brigade use cases:
 * carrying out CI/CD workflows
-* building opinioned CI/CD platforms
+* building opinionated CI/CD platforms
 * Meta-testing various codebases at regular intervals (language specific linters, code quality assessments, security scanning) and then automatically notifying responsible teams of the results.
 * Assembling weekly rollup reports using a Brigade pipeline by aggregating and analyzing data from multiple data systems.
 * Processing image data

projects/cert-manager/cert-manager-graduation.md

@@ -250,7 +250,7 @@ The project has six levels of responsibility, each one building on the previous:
 - [x] **Clearly defined and discoverable process to submit issues or changes.**
 
 <!-- (TOC Evaluation goes here) -->
-cert-manager makes use of GitHub issues and PRs. The following templates are avaialble:
+cert-manager makes use of GitHub issues and PRs. The following templates are available:
 - [Report a bug](https://github.com/cert-manager/cert-manager/blob/fc198e91979a5c1e869d2fc45750de2d6aacea7a/.github/ISSUE_TEMPLATE/bug.md)
 - [Feature request](https://github.com/cert-manager/cert-manager/blob/fc198e91979a5c1e869d2fc45750de2d6aacea7a/.github/ISSUE_TEMPLATE/feature-request.md)
 - [Submit a Pull Request ](https://github.com/cert-manager/cert-manager/blob/fc198e91979a5c1e869d2fc45750de2d6aacea7a/.github/PULL_REQUEST_TEMPLATE.md)
@@ -384,7 +384,7 @@ The [supported releases](https://cert-manager.io/docs/releases/) page lists proj
 
 ## Security
 
-Note: this section may be augemented by a joint-assessment performed by TAG Security.
+Note: this section may be augmented by a joint-assessment performed by TAG Security.
 
 ### Suggested
 

projects/chaosblade/2022-ChaosBlade-annual.md

@@ -10,7 +10,7 @@ ChaosBlade contains the following main components:
 ![ChaosBlade Architecture](https://chaosblade.io/img/chaosblade-main-components.png)
 
 - **ChaosBlade-Box Console**：The ChaosBlade visualization component mainly provides a set of user-friendly Web UI, through which users can arrange and manage chaos engineering experiments.
-- **ChaosBlade-Box Server**：The core logic component is mainly responsible for the management and arrangement of chaos engineering experiments, probe and application management. Including components, Chaos Engine: exercise engine, including process orchestration, security control, exercise report and other functions; Chaos Runner: exercise executor, compatible with a variety of execution tools; Chaos Experinece: exercise experience library, etc.
+- **ChaosBlade-Box Server**：The core logic component is mainly responsible for the management and arrangement of chaos engineering experiments, probe and application management. Including components, Chaos Engine: exercise engine, including process orchestration, security control, exercise report and other functions; Chaos Runner: exercise executor, compatible with a variety of execution tools; Chaos Experience: exercise experience library, etc.
 - **ChaosBlade-Agent**：The core logic component is deployed on the host of the user terminal or in the Kubernetes cluster. It is mainly responsible for establishing a connection with ChaosBlade-Box Server, reporting the heartbeat and serving as a command delivery channel.
 - **ChaosBlade**：The main execution tool can perform fault injection on different environments such as the Host and Kubernetes, and can perform fault interference on system network devices, file systems, kernels, and applications running on the system.
 

projects/cilium/cilium-graduation-proposal.md

@@ -33,7 +33,7 @@ Project governance including granting and revoking rights, expectations, and vot
 
 ### Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence.
 
-Commiters may be removed after 6 months of inactivity and are removed based on the [process outlined in the docs](https://docs.cilium.io/en/v1.12/community/governance/commit_access/#revoking-commit-access). Those removed will be changed to [emeritus in the MAINTAINERS.md](https://github.com/cilium/cilium/blob/main/MAINTAINERS.md#cilium--hubble-emeritus-committers)
+Committers may be removed after 6 months of inactivity and are removed based on the [process outlined in the docs](https://docs.cilium.io/en/v1.12/community/governance/commit_access/#revoking-commit-access). Those removed will be changed to [emeritus in the MAINTAINERS.md](https://github.com/cilium/cilium/blob/main/MAINTAINERS.md#cilium--hubble-emeritus-committers)
 
 ### Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). For a specification, have a list of adopters for the implementation(s) of the spec.
 

projects/cilium/cilium-incubation-proposal.md

@@ -140,7 +140,7 @@ cilium
 
 ## License
 
-* The main agent is licensered under [Apache 2.0](https://github.com/cilium/cilium/blob/master/LICENSE)
+* The main agent is licensed under [Apache 2.0](https://github.com/cilium/cilium/blob/master/LICENSE)
 * Portions of the eBPF datapath code are licensed under the [GPL](https://github.com/cilium/cilium/blob/master/bpf/COPYING)
 
 ## Maturity Level
@@ -262,7 +262,7 @@ N/A
 
 ## Statement on alignment with CNCF mission
 
-Cilium's misson is to provide open source networking and network security for
+Cilium's mission is to provide open source networking and network security for
 the cloud native ecosystem. Cilium is deeply integrated with Kubernetes, etcd,
 Prometheus, Envoy, and other CNCF projects. More and more users are adopting Cilium
 and making it a key part of their infrastructure. As such, there is a mutual
@@ -281,7 +281,7 @@ https://cilium.io/
 
 ## Release methodology and mechanics
 
-Cilium employs semantic versioning to name each release ([release process details](https://docs.cilium.io/en/v1.9/contributing/release/)) and compiled container images hosted on [Quay](https://quay.io/repository/cilium/cilium) and [Docker Hub](https://hub.docker.com/u/cilium). SHA256 checksums are provided for all distributed binaries. The release process is fully automated. A new minor release is released every 4 months with extensive release notes. In between minor releaess, micro releaes for the last 3 minor releases are provided regularly with backports of crucial bugfixes and security fixes.
+Cilium employs semantic versioning to name each release ([release process details](https://docs.cilium.io/en/v1.9/contributing/release/)) and compiled container images hosted on [Quay](https://quay.io/repository/cilium/cilium) and [Docker Hub](https://hub.docker.com/u/cilium). SHA256 checksums are provided for all distributed binaries. The release process is fully automated. A new minor release is released every 4 months with extensive release notes. In between minor releases, micro releases for the last 3 minor releases are provided regularly with backports of crucial bugfixes and security fixes.
 
 ## Security processes
 

projects/cloudevents/cloudevents-graduation-proposal.md

@@ -86,7 +86,7 @@ resolved.
 Yes, see our
 [Governance](https://github.com/cloudevents/spec/blob/main/docs/GOVERNANCE.md)
 and
-[Contibuting](https://github.com/cloudevents/spec/blob/main/docs/CONTRIBUTING.md)
+[Contributing](https://github.com/cloudevents/spec/blob/main/docs/CONTRIBUTING.md)
 docs.
 
 ### * Explicitly define the criteria, process and offboarding or emeritus conditions for project maintainers; or those who may interact with the CNCF on behalf of the project. The list of maintainers should be preferably be stored in a MAINTAINERS.md file and audited at a minimum of an annual cadence.
@@ -94,7 +94,7 @@ docs.
 Yes, see first section of this doc and our
 [Governance](https://github.com/cloudevents/spec/blob/main/docs/GOVERNANCE.md)
 and
-[Contibuting](https://github.com/cloudevents/spec/blob/main/docs/CONTRIBUTING.md)
+[Contributing](https://github.com/cloudevents/spec/blob/main/docs/CONTRIBUTING.md)
 docs.
 
 ### * Have a public list of Project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the Project website). For a specification, have a list of adopters for the implementation(s) of the spec. Refer to [FAQs](https://github.com/cncf/toc/blob/main/FAQ.md#what-is-the-definition-of-an-adopter) for guidelines on identifying adopters.

projects/cloudevents/cloudevents-sandbox-proposal.md

@@ -71,14 +71,14 @@ CloudEvents org: https://github.com/cloudevents
 
 CloudEvents repo for the specification: https://github.com/cloudevents/spec
 
-**External dependencie**: None
+**External dependencies**: None
 
 **Initial Maintainers**:
 
 The CloudEvents group does not have "maintainers" that approve
 Pull Requests (PRs) like traditional GitHub projects. Rather, the group
 discusses/reviews PRs in the PRs themselves and then when consensus is reached
-they are approved during our weekly calls. If concensus can not be reached
+they are approved during our weekly calls. If consensus can not be reached
 then a formal vote is taken. 
 
 Voting rights: each member company designates a "primary" and "alternate"

projects/cni-genie/cni-genie-sandbox-proposal.adoc

@@ -26,7 +26,7 @@ CNI Genie consists of 3 major components
 
 
 *Statement on alignment with CNCF mission:*
-The Cloud Native CNI-Genie project is well-alligned with the CNCF's mission statement of supporting cloud native systems. Kubernetes is a leading open source container orchestration engine. Standard kubernetes allows pods to have only single network interface. But these pods can have use-cases to host containers supporting service provisioning applications or virtual network functions (VNFs) that may typically require multiple network interfaces. CNI-Genie supports that and can continue support for several new use-cases on these aspects 
+The Cloud Native CNI-Genie project is well-aligned with the CNCF's mission statement of supporting cloud native systems. Kubernetes is a leading open source container orchestration engine. Standard kubernetes allows pods to have only single network interface. But these pods can have use-cases to host containers supporting service provisioning applications or virtual network functions (VNFs) that may typically require multiple network interfaces. CNI-Genie supports that and can continue support for several new use-cases on these aspects 
 
 CNI Genie is open to engage community and enable more innovations towards multi-networking usecases
 

projects/cni/cni-incubation-proposal.adoc

@@ -7,7 +7,7 @@
 The CNI (Container Network Interface) project consists of a specification and libraries for writing plugins to configure network interfaces
 in Linux containers, along with a number of supported plugins. CNI concerns itself only with network connectivity of containers and removing
 allocated resources when the container is deleted. Because of this focus, CNI has a wide range of support and the specification is simple to
-implement. CNI consists of 3 separate comonents:
+implement. CNI consists of 3 separate components:
 
 *  CNI Specification: defines an straightforward API between runtimes and network plugins for container network setup/teardown.  No more, no less.
 *  Plugins: provide network setup for a variety of use-cases and serve as reference examples of plugins conforming to the CNI specification

projects/cnigenie/2022-CNIGenie-annual.md

@@ -71,7 +71,7 @@ CNI-Genie was originally designed to enable multihoming for Kubernetes pods by e
 
 As mentioned above, this project had stalled for over two years due to resource reprioritization following 2019 events. So we have not tracked how we did against [goals](https://github.com/cni-genie/CNI-Genie/blob/master/ROADMAP-old.md) that were earlier set.
 
-While the initial goals to offer CNI choice & flexibility were great, users really only care that they get reliable multihoming capability with performant data-plane (traffic throughput) and control-plane (low network-ready latencies for pods) out of box that works well. This became clear from a 2022 KubeCon EU stories. One talk in particluar discussed the complexities they encountered using alternative solutions for multihomed networking. In the end, the other solution did not work because they designed their network for scale out rather than scale up. The ability to pick and choose CNI drivers becomes a much more appealing feature with a default that intuitively works well when networks start scaling.
+While the initial goals to offer CNI choice & flexibility were great, users really only care that they get reliable multihoming capability with performant data-plane (traffic throughput) and control-plane (low network-ready latencies for pods) out of box that works well. This became clear from a 2022 KubeCon EU stories. One talk in particular discussed the complexities they encountered using alternative solutions for multihomed networking. In the end, the other solution did not work because they designed their network for scale out rather than scale up. The ability to pick and choose CNI drivers becomes a much more appealing feature with a default that intuitively works well when networks start scaling.
 
 ### New Approach
 

projects/confidential-containers/2022-Confidential-Containers-annual.md

@@ -20,7 +20,7 @@ computing technologies.
 ## DevStats
 
 The Confidential Containers project is a collection of logically and
-programatically bound sub-projects, hosted across multiple git repositories
+programmatically bound sub-projects, hosted across multiple git repositories
 under the Confidential Containers GitHub organization.
 
 Below is a chart of all GitHub activities across all Confidential Containers
@@ -111,7 +111,7 @@ enhancements:
   cadence.
 - A hardware backed CI, i.e. a CI that runs tests on actual confidential
   computing hardware instances like e.g. Intel TDX, AMD SEV, and Intel SGX.
-- A Kubernetes Operartor for easily deploying the Confidential Containers
+- A Kubernetes Operator for easily deploying the Confidential Containers
   runtime, stack, and payload on Kubernetes clusters.
 - Support for process-based TEEs like e.g. SGX.
 - Technical debt reduction, in particular the dependencies on `umoci` and
@@ -145,7 +145,7 @@ Containers solution; both members of our community and external. Our target is
 to have at least 3 direct adopters by the end of 2023, helping us to grow to
 the next level of incubation.
 
-Aside from customer adoption, we also need to improve our current vulnerabilty
+Aside from customer adoption, we also need to improve our current vulnerability
 management process. Based on the [CNCF Security Guidelines](https://contribute.cncf.io/maintainers/security/security-guidelines/),
 we have to define a more formal way of tracking security issues, from the
 initial reporting steps up to the project release management for rapidly

projects/cubefs/cubefs-graduation-dd.md

@@ -36,10 +36,10 @@ The following recommendations were provided to the project that are non-blocking
 - To foster a more inclusive global community, TOC Reviewer recommends making a plan for global community development. This plan may include initiatives like English-language community meetings and cultivating contributors from various regions to better support adopters worldwide.
 - TOC Reviewer recommends organizing dedicated TSC meeting, in order to keep TSC members engaged.
 - To enhance community decision-making transparency, the TOC Reviewer recommends the project provide explicit records of voting processes, e.g. manual vote counts or using [gitvote](https://github.com/cncf/gitvote).
-- TOC Reviewer recommends to add explicit descripion of platforms supported in the [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md)
+- TOC Reviewer recommends to add explicit description of platforms supported in the [RELEASE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md)
 - TOC Reviewer recommends to cross reference the [roadmap governance(https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#roadmap)] and [change process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-roadmap) on the [ROADMAP.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ROADMAP.md) to make it easier to find for potential contributors.
-- And for the [roadmap change process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-roadmap), it's recommneded to include collecting roadmap proposals through public channels, and use more community fashion phrasing, which would encourage contributors to join the discussion and better understand whhere the project is heading to.
+- And for the [roadmap change process](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#changes-in-project-roadmap), it's recommended to include collecting roadmap proposals through public channels, and use more community fashion phrasing, which would encourage contributors to join the discussion and better understand where the project is heading to.
-- TOC Reviewer recommends to update security policy to include an embargo and private disclosure period before doing public disclosure for security vulnerbilities. And tagging a release clearly as "security-fixes-only" will help users to prioritize an upgrade.
+- TOC Reviewer recommends to update security policy to include an embargo and private disclosure period before doing public disclosure for security vulnerabilities. And tagging a release clearly as "security-fixes-only" will help users to prioritize an upgrade.
 
 ### Adoption Evaluation
 
@@ -99,7 +99,7 @@ N/A
 - [x] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
 
   - [CubeFS introduction documentation](https://cubefs.io/docs/master/overview/introduction.html) introduces the CubeFS architecture and main features.
-  - [CubeFS installation documentation](https://cubefs.io/docs/master/deploy/env.html) covers serveral ways of deployment.
+  - [CubeFS installation documentation](https://cubefs.io/docs/master/deploy/env.html) covers several ways of deployment.
   - [CubeFS end user documentation](https://cubefs.io/docs/master/user-guide/volume.html) includes basics operations as creating a volume, using volume and using cli tool.
 
 ## Governance and Maintainers
@@ -112,9 +112,9 @@ Note: this section may be augmented by the completion of a Governance Review fro
 
   CubeFS has been continuously updating governance doc to reflect project growth, some examples are:
   - CubeFS initial governance: <https://github.com/cubefs/cubefs/blob/v1.1.0/GOVERNANCE.md>
-  - Added Commiter role in May. 2023: <https://github.com/cubefs/cubefs/pull/1976>
+  - Added Committer role in May. 2023: <https://github.com/cubefs/cubefs/pull/1976>
   - Added Steering Committee in Apr. 2024: <https://github.com/cubefs/cubefs/pull/3312>
-  - Update maintainer list according to activity and add steering commitee member: <https://github.com/cubefs/cubefs/pull/3311>
+  - Update maintainer list according to activity and add steering committee member: <https://github.com/cubefs/cubefs/pull/3311>
   - Update the Governance Document to eliminate the role of the leader: <https://github.com/cubefs/cubefs/pull/3382>
     The description of 'project lead' implies a somewhat authoritarian role, but with the establishment of a Steering Committee, the Steering Committee should be considered the highest decision-making body.Thus CubeFS delete the role of 'project lead'.
   - Adding governance rules related to SIGs.: <https://github.com/cubefs/cubefs/pull/3430>
@@ -189,7 +189,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
   According to the [Maintainers list](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/MAINTAINERS.md), CubeFS currently has top level maintainers from OPPO, JD.com, BEIKE, Bytedance, LinkedIn, and additional committers from BIGO, VIVO.
 
   Definition of Maintainers and Committers can be found in the [GOVERNANCE.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md).
-  Both Maintainers and Committers require diversed membership: `No single vendor can exceed 50% of the total number of personnel.`
+  Both Maintainers and Committers require diversified membership: `No single vendor can exceed 50% of the total number of personnel.`
 
 - [x] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
 
@@ -214,7 +214,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
 
   According to [Governance.md#sub-projects](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#sub-projects), sub-projects can have their own repositories but follow the same governance mechanism as the main project
 
-  Subprojects Goverance descriptions can be found at:
+  Subprojects Governance descriptions can be found at:
   - cubefs-helm Governance: <https://github.com/cubefs/cubefs-csi#governance>
   - cubefs-csi Governance: <https://github.com/cubefs/cubefs-csi#governance>
   - cubefs-dashboard Governance: <https://github.com/cubefs/cubefs-dashboard#governance>
@@ -230,7 +230,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
   Cubefs has the following roles for contributors that are related to code and non-code contributions:
   - Technical Steering committee member: [GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-the-technical-steering-committeetsc)
   - Maintainer: [GOVERNANCE.md#expectations-from-maintainers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-maintainers)
-  - Commiter: [GOVERNANCE.md#expectations-from-committers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-committers)
+  - Committer: [GOVERNANCE.md#expectations-from-committers](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-committers)
   - SIG member: [GOVERNANCE.md#expectations-from-sigs-member](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#expectations-from-sigs-member)
   - Product Security Committee (PSC): [security-release-process.md#product-security-committee-psc](https://github.com/cubefs/cubefs/blob/master/security/security-release-process.md#product-security-committee-psc)
 
@@ -317,7 +317,7 @@ N/A
 
 - [x] **Roadmap change process is documented.**
 
-  CubeFS documentes its roadmap rules and changing process in [GOVERNANCE.md#roadmap](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#roadmap)
+  CubeFS documents its roadmap rules and changing process in [GOVERNANCE.md#roadmap](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/GOVERNANCE.md#roadmap)
 
 - [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
 
@@ -333,7 +333,7 @@ N/A
 
     CubeFS uses beta to mark their unstable releases. Ref: [RELEASE.md#types-of-releases](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/RELEASE.md#types-of-releases).
 
-    Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md). CubeFS doesn't have explict tagging rule for security releases. Though this is not required, tagging a release with "security-fixes-only" alike markers would be helpful for users to prioritize upgrades.
+    Security release process is documented at: [security-release-process.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/security/security-release-process.md). CubeFS doesn't have explicit tagging rule for security releases. Though this is not required, tagging a release with "security-fixes-only" alike markers would be helpful for users to prioritize upgrades.
 
   - [x] **Information on branch and tag strategies**
 
@@ -358,13 +358,13 @@ N/A
 
 ## Security
 
-Note: this section may be augemented by a joint-assessment performed by TAG Security.
+Note: this section may be augmented by a joint-assessment performed by TAG Security.
 
 ### Suggested
 
 - [x] **Achieving OpenSSF Best Practices silver or gold badge.**
 
-  CubeFS has achieved the OpenSSF Best Practices siler badge: <https://www.bestpractices.dev/projects/6232>
+  CubeFS has achieved the OpenSSF Best Practices silver badge: <https://www.bestpractices.dev/projects/6232>
 
   [![OpenSSF Best Practices](https://www.bestpractices.dev/projects/6232/badge)](https://www.bestpractices.dev/projects/6232)
 
@@ -416,7 +416,7 @@ N/A
 
 - [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)**
 
-  The [ADOPTERS.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ADOPTERS.md) documentes adopters with adoption level and success stories.
+  The [ADOPTERS.md](https://github.com/cubefs/cubefs/blob/206d5ddadf1f99abde6401b7aa18b57fc46e6bed/ADOPTERS.md) documents adopters with adoption level and success stories.
 
 - [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)**
 
@@ -493,7 +493,7 @@ Note: Adopter3 preferred to remain anonymous. The interview details are kept in
 
 JD.com has been using CubeFS since 2018 as the foundation for its entire storage infrastructure. This adoption supports a diverse range of unstructured storage needs across the company's retail operations, including middleware, online and offline business, big data, and AI training, etc. In production for more than 6 years, they have multiple clusters, with the largest one consisting of over 4,000 servers and a total storage capacity exceeding 300TB, serving over 1 million clients concurrently. They use the 2020 version from the community and manually backport bug fixes.
 
-JD.com choses CubeFS because it is customizable for their specific scenarios and supports large-scale clusters. CubeFS supports operating on the same dataset with different protocols simultaneously, like POSIX and S3, while alternatives like CephFS support only one. The adopter has also evaulated MooseFS, however it didn't met their requirements in scalability and stability.
+JD.com choses CubeFS because it is customizable for their specific scenarios and supports large-scale clusters. CubeFS supports operating on the same dataset with different protocols simultaneously, like POSIX and S3, while alternatives like CephFS support only one. The adopter has also evaluated MooseFS, however it didn't met their requirements in scalability and stability.
 
 JD.com has found the project documentation invaluable, particularly the design documents, which facilitated a deeper understanding and customization of CubeFS. The adoption has led to significant value, including reduced maintenance and resource costs, and improved resource utilization, reaching up to 98% in some environments.
 

projects/cubefs/cubefs-graduation-proposal.md

@@ -9,7 +9,7 @@ CubeFS, an open-source project that joined CNCF as a sandbox project in December
 **Multi-Engine Support** CubeFS supports two storage engines, multiple copies and erasure coding, and has made a lot of multidimensional optimizations for these engines. This enables the flexibly to meet the demands of different business scenarios for IO performance and storage cost.
 
 **Strong Scalability** The metadata of CubeFS has horizontal scalability, and a single cluster can easily support billions of files and exabytes of storage capacity.
-**High Performance** It supports multi-level caching, delicated optimizations for small files, and various high-performance replication protocols.
+**High Performance** It supports multi-level caching, dedicated optimizations for small files, and various high-performance replication protocols.
 
 **Multi-tenancy** CubeFS provides multi-tenant management and achieves access isolation and performance non-interference between tenants through namespace management and QoS.
 

projects/dapr/dapr-graduation-due-diligence.md

@@ -93,7 +93,7 @@ N/A
 
   The project maintainers have been highly responsive throughout the process.
 
-  Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria.
+  Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
 
 - [x] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
  
@@ -226,9 +226,9 @@ Note: this section may be augmented by the completion of a Governance Review fro
 
 - [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.**
 
-  The goal of the Dapr project is to codify the traditional 3-tier software architecture pattern - client/server/database - into a cloud native microservice architecture via software building blocks. The objective is to negate the traditional drawbacks of the 3-tier software pattern by enabling agility, redudancy, scale-out/scale-in, resiliency, platform independence and high availability through a cloud native software design.
+  The goal of the Dapr project is to codify the traditional 3-tier software architecture pattern - client/server/database - into a cloud native microservice architecture via software building blocks. The objective is to negate the traditional drawbacks of the 3-tier software pattern by enabling agility, redundancy, scale-out/scale-in, resiliency, platform independence and high availability through a cloud native software design.
   
-  An additional objective is to simplify building microservice applications for traditional and cloud native application developers by providing standardized service building blocks and familiar SDKs for multiple programming languages - allowing organizations with teams that utilize disparate programming languages a lower barrier to entry for writing and maintaining coud native microservice applications. 
+  An additional objective is to simplify building microservice applications for traditional and cloud native application developers by providing standardized service building blocks and familiar SDKs for multiple programming languages - allowing organizations with teams that utilize disparate programming languages a lower barrier to entry for writing and maintaining cloud native microservice applications. 
 
   The Dapr project is currently targeted for medium to large enterprises. The most common adoption pattern being seen mostly in financial service, retail and healthcare. The target persona is application developers, who interact with Dapr via SDKs, Rest APIs or native gRPC clients.
   
@@ -294,7 +294,7 @@ Note: this section may be augmented by the completion of a Governance Review fro
   
   [Issue #8188 in the Dapr repo](https://github.com/dapr/dapr/issues/8188) has been created to track tagging policy clarification.
 
-  The current tagging strategy is sufficent to meet the requirements for Graduation with the recommendation to complete the issues identified soon after Graduation.
+  The current tagging strategy is sufficient to meet the requirements for Graduation with the recommendation to complete the issues identified soon after Graduation.
   
   - [x] Information on branch and tag strategies
 
@@ -359,7 +359,7 @@ Note: this section may be augmented by a joint-assessment performed by TAG Secur
   
   TOC reviewers do not view completing the TAG Security self-assessment as a blocker to Graduation given review of all presented materials.
   
-  TOC issue [1451](https://github.com/cncf/toc/pull/1451) was created and merged to link to the TAG Security self-assessment for future applicationa.
+  TOC issue [1451](https://github.com/cncf/toc/pull/1451) was created and merged to link to the TAG Security self-assessment for future applications.
 
 - [x] **Third Party Security Review.**
 

projects/dapr/dapr-incubation-proposal.md

@@ -47,7 +47,7 @@ Dapr has a set of [building block APIs](https://docs.dapr.io/concepts/building-b
 
 The Dapr CLI provides a simple local development experience to develop, build and test cloud native applications. 
 
-Although Dapr can be used with localhost HTTP or gRPC calls, language SDKs provide a more familar developer experience and integration with language specific tooling.
+Although Dapr can be used with localhost HTTP or gRPC calls, language SDKs provide a more familiar developer experience and integration with language specific tooling.
 
 ## Statement on alignment with CNCF charter mission
 
@@ -57,7 +57,7 @@ Dapr is aligned with the CNCF mission to make cloud native computing ubiquitous
 
 Similar projects outside of CNCF:
 
-- **[Micro](https://github.com/micro/micro)** is a microservices framework that has some similaries to Dapr. A significant difference is that Dapr is a set of APIs that can be used from any language or framework and is incremental in its adoption. Most microservice frameworks today like Micro are restricted to certain languages, require developers to rewrite their code and do not expose a set of common APIs that can be extended by the community.
+- **[Micro](https://github.com/micro/micro)** is a microservices framework that has some similarities to Dapr. A significant difference is that Dapr is a set of APIs that can be used from any language or framework and is incremental in its adoption. Most microservice frameworks today like Micro are restricted to certain languages, require developers to rewrite their code and do not expose a set of common APIs that can be extended by the community.
 
 - Service meshes such as CNCF **[Linkerd](https://github.com/linkerd/linkerd)** and non-CNCF **[Istio](https://github.com/istio/istio)** both have network routing, security and observability that Dapr also provides. The primary difference between Dapr and service meshes is that Dapr operates at the application level by exposing APIs for developers, whereas service meshes operate at the infrastructure networking layer.
 
@@ -81,7 +81,7 @@ Lei Zhang (Harry)
 
 Incubation
 
-Having built Dapr in conjunction with customers, adoptors and the community who are running production workloads, Dapr is ready for incubation level maturity.  
+Having built Dapr in conjunction with customers, adopters and the community who are running production workloads, Dapr is ready for incubation level maturity.  
 
 ## License
 

projects/dex/2021-dex-annual.md

@@ -115,7 +115,7 @@ We have a number of items on our roadmap that we'd like to accomplish next:
 - Get more maintainers and adopters
 - Run tests on ARM architecture (already in progress, thanks to CNCF infra)
 - OIDC certification
-- Connector middleware allowin users to inject custom logic into the auth process (eg. use custom claims)
+- Connector middleware allowing users to inject custom logic into the auth process (eg. use custom claims)
 - Custom connectors
 
 Our current priority is adoption, documentation and stabilization.

projects/distribution/2022-distribution-annual.md

@@ -16,7 +16,7 @@ This is the annual review for the [distribution](https://github.com/distribution
 
 Distribution provides an implementation of the Open Source Registry for storing and distributing container images [and other application content] via the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec). The goal of this project is to provide a simple, secure, and scalable base for building a large scale registry solution or running a simple private registry. It is a core library for many registry operators including [Docker Hub](https://hub.docker.com/), GitHub Container Registry, [GitLab Container Registry](https://gitlab.com/gitlab-org/container-registry), [DigitalOcean Container Registry](https://www.digitalocean.com/products/container-registry), as well as the [CNCF Harbor Project](https://goharbor.io/), and VMware Harbor Registry.
 
-Additionally, the project provides various libraries (a.k.a. `Go` programming langauge packages) that are widely used across large number of actively maintained OSS projects such as [moby](https://github.com/moby/moby/), [argocd](https://github.com/argoproj-labs), etc.
+Additionally, the project provides various libraries (a.k.a. `Go` programming language packages) that are widely used across large number of actively maintained OSS projects such as [moby](https://github.com/moby/moby/), [argocd](https://github.com/argoproj-labs), etc.
 
 ## DevStats
 
@@ -38,7 +38,7 @@ There is not doubt the project's adoption is quite high. As mentioned previously
 
 ## Project goals
 
-The Distribution project has the long term goal of providing a secure tool chain for distributing contentt hat allow users to:
+The Distribution project has the long term goal of providing a secure tool chain for distributing content hat allow users to:
 * Enjoy an efficient, secured and reliable way to store, manage, package and exchange content
 * Hack/roll their own on top of healthy open-source components
 * Implement their own home made solution through good specs, and solid extensions mechanism.

projects/distribution/2023-distribution-annual.md

@@ -16,7 +16,7 @@ This is the annual review for the [distribution](https://github.com/distribution
 
 Distribution provides an implementation of the Open Source Registry for storing and distributing container images [and other application content] via the [OCI Distribution Specification](https://github.com/opencontainers/distribution-spec). The goal of this project is to provide a simple, secure, and scalable base for building a large scale registry solution or running a simple private registry. It is a core building block for many registry operators including [Docker Hub](https://hub.docker.com/), GitHub Container Registry, [GitLab Container Registry](https://gitlab.com/gitlab-org/container-registry), [DigitalOcean Container Registry](https://www.digitalocean.com/products/container-registry), as well as the [CNCF Harbor Project](https://goharbor.io/), and VMware Harbor Registry.
 
-Additionally, the project provides various libraries (a.k.a. `Go` programming langauge packages) that are widely used across large number of actively maintained OSS projects such as [moby](https://github.com/moby/moby/), [argocd](https://github.com/argoproj-labs), etc.
+Additionally, the project provides various libraries (a.k.a. `Go` programming language packages) that are widely used across large number of actively maintained OSS projects such as [moby](https://github.com/moby/moby/), [argocd](https://github.com/argoproj-labs), etc.
 
 ## DevStats
 
@@ -36,7 +36,7 @@ There is very little doubt the project's adoption continue to be quite high and
 
 ## Project goals
 
-The Distribution project has the long term goal of providing a secure tool chain for distributing contentt hat allow users to:
+The Distribution project has the long term goal of providing a secure tool chain for distributing content hat allow users to:
 * Take advantage of an efficient, secure and reliable way to store, manage, package and exchange content
 * Hack/roll their own on top of healthy open-source components
 * Implement their own home made solution through good specs, and solid extensions mechanism.

projects/dragonfly/dragonfly-sandbox-proposal.adoc

@@ -86,7 +86,7 @@ Additional Maintainers:
 
 _Development needs:_
 
-We currently use Travis and CircleCI for CI, but we may want to use CNCF resources to deploy jenkis for node e2e test.
+We currently use Travis and CircleCI for CI, but we may want to use CNCF resources to deploy jenkins for node e2e test.
 
 _Production needs:_
 

projects/etcd/etcd-graduation-proposal.md

@@ -27,7 +27,7 @@ The etcd project has a [documented governance](https://github.com/etcd-io/etcd/b
 
 ### * Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). For a specification, have a list of adopters for the implementation(s) of the spec.
 
-The [AOPTERS.md](https://github.com/etcd-io/etcd/blob/master/ADOPTERS.md ) file shows the list of etcd project adopters.
+The [ADOPTERS.md](https://github.com/etcd-io/etcd/blob/master/ADOPTERS.md ) file shows the list of etcd project adopters.
 
 ## Incubation Details
 _**Project should address each area listed below**_

projects/fabedge/2022-FabEdge-annual.md

@@ -32,7 +32,7 @@ This is the project’s first annual review, but since FabEdge joined CNCF, we h
 
 * Multi-cluster communication and cross-cluster DNS service.
 * Dual-stack network.
-* Hole-punching to enable edge nodes to establish VPN tunnels betwwen each other even if NAT network exists.
+* Hole-punching to enable edge nodes to establish VPN tunnels between each other even if NAT network exists.
 * Auto-networking on edge nodes in the same LAN. 
 * Provide coredns and kube-proxy capability on edge side.
 

projects/falco/falco-graduation-proposal.md

@@ -98,7 +98,7 @@ Maintainership-related decisions are taken with respect to the rules established
 
 Maintainers are defined by [OWNERS](https://www.kubernetes.dev/docs/guide/owners/) files on a per-repository basis. The [MAINTAINERS.md](https://github.com/falcosecurity/evolution/blob/main/MAINTAINERS.md) file summarizes the content of all OWNERS files across all repositories. The document is automatically updated by our infra and frequently audited using the PR review process.
 
-As per our governace, core maintainers (listed by [MAINTAINERS.md#core-maintainers](https://github.com/falcosecurity/evolution/blob/main/MAINTAINERS.md#core-maintainers)) are those maintaining the [core repositories](https://github.com/falcosecurity/evolution#official) of the project. Core maintainers are responsible for overseeing the overall project health and growth, and speaking on behalf of the project, and also entitled to interact with the CNCF.
+As per our governance, core maintainers (listed by [MAINTAINERS.md#core-maintainers](https://github.com/falcosecurity/evolution/blob/main/MAINTAINERS.md#core-maintainers)) are those maintaining the [core repositories](https://github.com/falcosecurity/evolution#official) of the project. Core maintainers are responsible for overseeing the overall project health and growth, and speaking on behalf of the project, and also entitled to interact with the CNCF.
 
 
 

projects/falco/falco-incubation-proposal.md

@@ -23,7 +23,7 @@ In short, the Falco project has seen terrific growth and project participation s
 
 #### Github
 
-The CNCF provides Falco Github metrics through its [devstats site](https://falco.devstats.cncf.io/d/65/summary-dashboard?orgId=1&from=now-3y&to=now-1w&var-period=m&var-repo_name=Falco&var-repogroup_name=All&var-repogroups=All). The devstats metrics show that the Falco team has maintained a constant flow of commits, and has increased the velocity of commits. This is due in part to Sysdig's sponsorship of the project, providing 4 full time employees for the project. Overall comitters increased by 40 to 56, showing that while the sponsorship does influence commit velocity, the project is taking commits from a wider group outside of Sysdig. This is also evidenced by the Contributing Companies metric increasing from a max of 7 to a max of 13.
+The CNCF provides Falco Github metrics through its [devstats site](https://falco.devstats.cncf.io/d/65/summary-dashboard?orgId=1&from=now-3y&to=now-1w&var-period=m&var-repo_name=Falco&var-repogroup_name=All&var-repogroups=All). The devstats metrics show that the Falco team has maintained a constant flow of commits, and has increased the velocity of commits. This is due in part to Sysdig's sponsorship of the project, providing 4 full time employees for the project. Overall committers increased by 40 to 56, showing that while the sponsorship does influence commit velocity, the project is taking commits from a wider group outside of Sysdig. This is also evidenced by the Contributing Companies metric increasing from a max of 7 to a max of 13.
 
 | GitHub |Pre-Sandbox* (< 10-2018) | Post-Sandbox (>= 10-2018) | | 
 |--------|-------------------------|---------------------------|-|
@@ -124,7 +124,7 @@ Falco shipped a number of features and improvements since Sandbox. Below is a pa
 * MITRE Tagged Rules
 * Minimal Images
 * Response Engine for AWS & Google Cloud
-* Publish Events to SNS or Pub/Sub, Respond with Lamba or Functions
+* Publish Events to SNS or Pub/Sub, Respond with Lambda or Functions
 * Falco Operator in Red Hat Operator Hub (operatorhub.io)
 * Falco in GKE Marketplace
 * Falco Training open sourced
@@ -181,6 +181,6 @@ Longer term improvements included:
 The Falco project maintainers propose that Falco move to Incubation based on:
 
 * Use in production by 3 end users of note (Shopify, BAH, Frame.io).
-* A healthly number of committers and a growing committer base. In addition, a healthy online community.
+* A healthy number of committers and a growing committer base. In addition, a healthy online community.
 * Demonstrating a substantial ongoing flow of commits and merged contributions that focused on delivering a defined project roadmap and integrations.
 * A clear versioning scheme with dev and stable releases.

projects/falco/falco-sandbox-proposal.adoc

@@ -149,7 +149,7 @@ A https://github.com/sysdiglabs/falco-nats[proof of concept] was created showing
 Code is currently hosted by Sysdig:
 https://github.com/draios/falco[https://github.com/draios/falco]
 
-The code will move to a vendor netural github organization at:
+The code will move to a vendor neutral github organization at:
 https://github.com/falcosecurity[https://github.com/falcosecurity]
 
 

projects/fluid/2022-fluid-annual.md

@@ -34,7 +34,7 @@ Here are several key concepts:
   dimensions, such as security, version management and data acceleration. We hope to start with data
   acceleration to support the management of datasets.
 * **Runtime**: The execution engine that enforces dataset security, provides version management and data
-  acceleration capabilities. The Runtime defines a set of interfaces to mangage DataSets in their
+  acceleration capabilities. The Runtime defines a set of interfaces to manage DataSets in their
   life cycle, so the management and acceleration of datasets can be implemented behind these
   interfaces.
 
@@ -95,7 +95,7 @@ the [MAINTAINERS_COMMITTERS.md](https://github.com/fluid-cloudnative/fluid/blob/
 
 # Project adoption
 
-Fluid has been adopted as the foundation of public cloud Kubernetes AI/Big Data solutions. Many companies have fully leveraged Fluid build their cloud native AI/Big Data platform accross hybrid, multi-cloud, serverless environments.
+Fluid has been adopted as the foundation of public cloud Kubernetes AI/Big Data solutions. Many companies have fully leveraged Fluid build their cloud native AI/Big Data platform across hybrid, multi-cloud, serverless environments.
 
 Beyond this, Fluid have **15 adopters** totally, and the whole adopters list can be found in the existing [ADOPTERS file](https://github.com/fluid-cloudnative/fluid/blob/master/ADOPTERS.md).
 

projects/harbor/harbor-graduation-proposal.md

@@ -8,7 +8,7 @@ On behalf of the maintainers team, we believe Harbor is ready for the CNCF [Grad
 
 *Project Description:* Harbor is an open source cloud native registry that provides trust, compliance, performance, and interoperability. As a private on-premises registry, Harbor fills a gap for organizations that prefer not to use a public or cloud-based registry or want a consistent experience across clouds. Harbor secures images with role-based access control, scans images for vulnerabilities, and signs images as trusted. A CNCF Incubating project, Harbor helps you consistently and securely manage images across cloud native compute platforms like Kubernetes and Docker.
 
-Harbor in essense solves common problems in organizations building cloud native applications by offering them a choice to deploy their own private on-premises registry and apply a consistent policy across artifact management in any cloud.
+Harbor in essence solves common problems in organizations building cloud native applications by offering them a choice to deploy their own private on-premises registry and apply a consistent policy across artifact management in any cloud.
 
 === CNCF Alignment & Why does CNCF need a container registry? 
 

projects/in-toto/in-toto-graduation-dd.md

@@ -126,7 +126,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN
     Email: aditya.sirish@nyu.edu
     GitHub username: @adityasaky
 
-Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low and the current list of maintainers appears to be sufficient. The maintainers also have a few active sub-project maintainers in the core maintainer pipeline if needed to promote one of them. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU.
+Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low and the current list of maintainers appears to be sufficient. The maintainers also have a few active sub-project maintainers in the core maintainer pipeline if needed to promote one of them. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committee members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU.
 
 - [x] **A number of active maintainers which is appropriate to the size and scope of the project.**
 
@@ -193,7 +193,7 @@ A contribution guide is placed at the top level [community repository](https://g
 
 - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.**
 
-Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailng list, a slack join link, github and IRC contacts.
+Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailing list, a slack join link, github and IRC contacts.
 
 - [X] **List and document all project communication channels, including subprojects (mail list/slack/etc.).  List any non-public communications channels and what their special purpose is.**
 
@@ -227,7 +227,7 @@ Roadmap for project with pointers to subproject ROADMAPs are encoded in a [ROADM
 
 - [X] **Roadmap change process is documented.**
 
-Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide rodamap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs
+Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide roadmap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs
 
 - [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
 
@@ -244,7 +244,7 @@ The [friends](https://github.com/in-toto/friends) repository outlines how cloud
 
 The in-toto project has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence.
 
-All implementations follow semver to communicate their feature support, as well as backwards and forwards compatiblity.
+All implementations follow semver to communicate their feature support, as well as backwards and forwards compatibility.
 
 - [x] **History of regular, quality releases.**
 
@@ -303,7 +303,7 @@ Adoptions are documented in the [in-toto friends repository](https://github.com/
 
 - [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)**
 
-Adopters are [documented](https://github.com/in-toto/friends) which includes at least 3 indepdendent adopters.  Adopter interviews also showed 3 independent adopters. All adopters I interviewed are using in-toto for production.
+Adopters are [documented](https://github.com/in-toto/friends) which includes at least 3 independent adopters.  Adopter interviews also showed 3 independent adopters. All adopters I interviewed are using in-toto for production.
 
 The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
 
@@ -323,8 +323,8 @@ This adopter interview is performed in Sept 2024 and recorded a very happy adopt
 
 ##### Adopter 2 - GitHub/Software company
 
-This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details.
+This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great experience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details.
 
 ##### Adopter 3 - Chainguard/Software company
 
-This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details.
+This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great experience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details.

projects/in-toto/in-toto-sandbox-proposal.adoc

@@ -11,7 +11,7 @@ Current cloud native deployments build software using a complex process that
 is vulnerable to attack.  Building software involves a software supply chain 
 comprised of version control systems, build servers, CI/CD systems, test frameworks, 
 localization, etc. that must all be honest or else the software may be tampered with.  
-in-toto is the first framework to provide cryptograpically
+in-toto is the first framework to provide cryptographically
 verifiable, full-system provenance of all the artifacts (e.g., source code files, 
 executables, documentation, pictures, etc.) within the supply chain.  As a result,
 in-toto is able to defend against malicious parties that tamper with a company's
@@ -118,7 +118,7 @@ Blogposts related to in-toto are currently published in NYU's secure systems's l
 in-toto's release process for the reference implementation has a strict
 adherence with semver. The release schedule is as follows:
 
-* 2 months of feature develoment
+* 2 months of feature development
 * 1 one month of feature freeze
 * 1 month of release candidacy
 
@@ -139,6 +139,6 @@ ensure compliance and security for all tools, hence protecting cloud application
 
 in-toto aligns with the CNCF mission statement by:
 
-* being-container transparent: when designing in-toto, we considered the nature of all toolchains involved in contemporary applications. As such, in-toto can be used in and out of the cloud interchangably. Furthermore, in-toto can be used in hybrid cloud setups.
+* being-container transparent: when designing in-toto, we considered the nature of all toolchains involved in contemporary applications. As such, in-toto can be used in and out of the cloud interchangeably. Furthermore, in-toto can be used in hybrid cloud setups.
 * Helping to enforce cloud native best practices: in-toto layouts are a great place to locate cloud native policy information. With it, parties can judge and verify that a project is, in-fact, running a correct process in their cloud native pipeline. Our admission webhook can be used to enforce the admission of pods, daemonsets and statefulsets that strictly followed the layout assigned to them.
  

projects/jaeger/jaeger-incubation-proposal.adoc

@@ -66,7 +66,7 @@ Some features added recently in response to community requests or as community c
 * Deployment templates for Kubernetes - https://github.com/jaegertracing/jaeger-kubernetes
 * Jaeger as a drop-in replacement for Zipkin - https://github.com/uber/jaeger/milestone/2
 * Allow Istio/Envoy to report span data to Jaeger - https://github.com/uber/jaeger/issues/225
-* Add health checks for better intergation with Kubernetes - https://github.com/uber/jaeger/pull/280
+* Add health checks for better integration with Kubernetes - https://github.com/uber/jaeger/pull/280
 * Use cpf13/cobra for flexible configuration under Kubernetes - https://github.com/uber/jaeger/issues/233
 * Instrumentation libraries in more languages - https://github.com/uber/jaeger/issues/366
 

projects/k3s/2022-k3s-annual.md

@@ -112,7 +112,7 @@ Currently, the project has 17 maintainers, all with SUSE:
 
 Based on issues filed on GitHub and interactions on Slack, K3s continues to see a healthy adoption from many different types of users from hobbyists to large organizations. While we have setup an ADOPTERS.md, we've not yet start to reach out to known adopters in earnest to get them listed.  There are however several known adopters, specifically Civo Cloud, Rocketchat, and Gitpod.  We will continue to reach out to these and other adopters to ensure they are properly tracked in ADOPTERS.md.
 
-Additionally, through our devstats, you can see a healthy number of contributors from outside collaborators across several companies, in fact you can see in the last year, we've accepted contribtuions from over [180 different companies](https://k3s.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions).
+Additionally, through our devstats, you can see a healthy number of contributors from outside collaborators across several companies, in fact you can see in the last year, we've accepted contributions from over [180 different companies](https://k3s.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions).
 
 
 K3s is also used as a building block for other projects and products. Here are a few that are independent of K3s, but leverage or build on top of it:

projects/karmada/2022-karmada-annual.md

@@ -29,7 +29,7 @@ Karmada presents its value in the following two aspects:
 
 Karmada was proposed and accepted as a sandbox project in September 2021 ([Sandbox project onboarding issue](https://github.com/cncf/toc/issues/721)).
 
-## Continous Community Momentum
+## Continuous Community Momentum
 
 In the past year, we joined hand with end users across industries and witnessed successful implementations of Karmada in many real-world projects.
 We have built channels to reach out to our users to know better what they want and need, such as meetups and online activities.

projects/keda/2021-KEDA-annual.md

@@ -44,7 +44,7 @@ The full maintainer list can be found in our [GitHub repository](https://github.
 
 Since we have joined as a CNCF Sandbox project we've seen a **big growth in terms of our scalers, community, and users**.
 
-When we initially joined KEDA, we provided around ~15 scalers to our users which were targetting the major cloud providers (AWS, Azure, Google Cloud) as well as popular technologies such as Prometheus and Kafka. **Over the past year, we've grown to more than 30+ scalers** supporting more cloud providers, more technologies, added various features, and providing production-grade security. This effort was not only by our maintainers but mainly by our community who started contributing back more and more.
+When we initially joined KEDA, we provided around ~15 scalers to our users which were targeting the major cloud providers (AWS, Azure, Google Cloud) as well as popular technologies such as Prometheus and Kafka. **Over the past year, we've grown to more than 30+ scalers** supporting more cloud providers, more technologies, added various features, and providing production-grade security. This effort was not only by our maintainers but mainly by our community who started contributing back more and more.
 
 One of our focus points has been in **growing the community** by getting people to our community standups, listing who is using KEDA provide, and give it a [central place in our documentation](https://keda.sh/community/). This allows people who are considering to use KEDA to get trust in the technology and start using it themselves or learn how they are using it.
 

projects/keda/keda-sandbox-proposal.adoc

@@ -8,7 +8,7 @@ Deploying applications on Kubernetes has become trivial, but that's only where i
 
 While Kubernetes provides application autoscaling out-of-the-box with Horizontal Pod Autoscalers (HPA), it is sometimes too limited as it only covers resource metrics while often you want to scale on external metrics instead. In reality, that means you have to deploy 3r party metric adapters based on the system you depend on, but you can only run one in the same cluster and have to manage it.
 
-In 2019, Kubernetes Event-driven Autoscaling (KEDA) was launched by Microsoft and Red Hat to build an open application-oriented scaling mechanism that is vendor-agnostic and acts as an external metric aggregater which allows you to use 0-to-n scaling based on a variety of external metrics for different vendors. On November 19th, 2019 KEDA v1.0 has been released which makes it production-ready and provides enterprise-grade security.
+In 2019, Kubernetes Event-driven Autoscaling (KEDA) was launched by Microsoft and Red Hat to build an open application-oriented scaling mechanism that is vendor-agnostic and acts as an external metric aggregator which allows you to use 0-to-n scaling based on a variety of external metrics for different vendors. On November 19th, 2019 KEDA v1.0 has been released which makes it production-ready and provides enterprise-grade security.
 
 With Kubernetes Event-driven Autoscaling (KEDA) we aim to make application autoscaling super simple, regardless of the data source that you are using, by abstracting away the metric adapters and allowing KEDA customers to only focus on their scaling needs of their platform.
 
@@ -18,9 +18,9 @@ Instead of reinventing the wheel, Kubernetes Event-driven Autoscaling (KEDA) is
 
 Kubernetes Event-driven Autoscaling (KEDA) provides a variety of 15+ scalers which allows customers to automatically scale workloads based on external systems. Our portfolio includes AWS, GCP, Microsoft Azure & Huawei cloud as well as other technologies such as Kafka, Prometheus, NATS and more but new scalers can be added very easily.
 
-By leveraging scale-to-0, Kubernetes Event-driven Autoscaling (KEDA) allows customers to build resource-friendly applications by making the unused resouces available to other applications in the Kubernetes cluster that really need them.
+By leveraging scale-to-0, Kubernetes Event-driven Autoscaling (KEDA) allows customers to build resource-friendly applications by making the unused resources available to other applications in the Kubernetes cluster that really need them.
 
-Kubernetes Event-driven Autoscaling (KEDA) provides production-grade security by supporting pod identities, like Azure AD Pod Identity, to avoid secret management and allow for authentication re-use across multiple scalers. This allows existing deployments to run under the same minimal permissions while KEDA scalers can use higher-priviledged authentication to gain the required metrics. With this approach, we allow developers to focus on their workload while ops manages the authentication & configuration of the autoscaling, although it can be managed end-to-end by a full-stack as well.
+Kubernetes Event-driven Autoscaling (KEDA) provides production-grade security by supporting pod identities, like Azure AD Pod Identity, to avoid secret management and allow for authentication re-use across multiple scalers. This allows existing deployments to run under the same minimal permissions while KEDA scalers can use higher-privileged authentication to gain the required metrics. With this approach, we allow developers to focus on their workload while ops manages the authentication & configuration of the autoscaling, although it can be managed end-to-end by a full-stack as well.
 
 KEDA was presented at KubeCon 2019 (https://www.youtube.com/watch?v=ZK2SS_GXF-g).
 

projects/keptn/2021-keptn-annual.md

@@ -10,7 +10,7 @@
 
 ## Background
 
-[Keptn](https://keptn.sh/) is a cloud-native application life-cycle orchestration tool. Its goal is not to replace tools that are already present in an organization but to connect and orchestrate them to support the life-cycle management of applications. Keptn enables DevOps engineers as well as Site Reliabiliy Engineers (SRE) to scale delivery and operations automation in their organizations. 
+[Keptn](https://keptn.sh/) is a cloud-native application life-cycle orchestration tool. Its goal is not to replace tools that are already present in an organization but to connect and orchestrate them to support the life-cycle management of applications. Keptn enables DevOps engineers as well as Site Reliability Engineers (SRE) to scale delivery and operations automation in their organizations. 
 
 Keptn builds upon declarative definitions for multi-stage environments, SLO-based quality gates, and auto-remediation and integrates with tools via an event-based approach. 
 

projects/keycloak/keycload-incubation-proposal.adoc

@@ -20,10 +20,10 @@ Link to GitHub project: https://github.com/keycloak
 
 Getting Started / Trying out: https://www.keycloak.org/getting-started
 
-CNCF SIG Security assesment request:
+CNCF SIG Security assessment request:
 https://github.com/cncf/sig-security/issues/372
 
-CNCF SIG Security Self Assesment document with great level of details about the project:
+CNCF SIG Security Self Assessment document with great level of details about the project:
 https://docs.google.com/document/d/14IIGliP3BWjdS-0wfOk3l_1AU8kyoSiLUzpPImsz4R0/edit#
 
 Link to initial 2018 Presentation: (Oct 2018 TOC presentation - slide 26)
@@ -144,7 +144,7 @@ release while keeping backwards compatibility.
 Github and community stats (March 2020): 
 * Forks: 2.8k 
 * Stars: 6.4k 
-* Controbutors: 393 
+* Contributors: 393 
 * Commits: 12.5k 
 * Website visits: >60k unique users per month 
 * Developer mailing list: ~100 posts/month 
@@ -176,7 +176,7 @@ Production usage
 
 "Document that it is being used successfully in production by at least three independent end users which, in the TOC’s judgement, are of adequate quality and scope."
 
-Refering endorsements from Submission:
+Referring endorsements from Submission:
 
 * listed in: https://github.com/cncf/toc/issues/406
 * grouped and summarized in: https://github.com/cncf/toc/pull/405#issuecomment-623491056 and https://github.com/cncf/toc/pull/405#issuecomment-624043670 
@@ -378,10 +378,10 @@ External Identity Providers (SAML 2.0, OpenID Connect, custom)
 Alignment with SIG Reference Model
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-CNCF SIG Securiry assesment request:
+CNCF SIG Security assessment request:
 https://github.com/cncf/sig-security/issues/372
 
-CNCF SIG Security Self Assesment:
+CNCF SIG Security Self Assessment:
 https://docs.google.com/document/d/14IIGliP3BWjdS-0wfOk3l_1AU8kyoSiLUzpPImsz4R0/edit?usp=sharing
 
 High level architecture
@@ -422,7 +422,7 @@ Project and Code Quality. Other information
 -------------------------------------------
 
 Comprehensive overview of the project has been performed for SIG
-Security Assesment:
+Security Assessment:
 
 https://github.com/cncf/sig-security/issues/372
 

projects/keylime/2021-Keylime-annual.md

@@ -56,7 +56,7 @@ allowing them to learn but also take exams on their own device. Lernstick is
 using Keylime to guarantee the integrity of the system being loaded on student's
 computers. It is currently in a proof of concept stage, but once in use it will
 translate to hundreds of student machines using Keylime to prove to the exam
-server that they are runnnig a system that hasn't been tampered with.
+server that they are running a system that hasn't been tampered with.
 
 Using Keylime in a "bring your own device" (BYOD) context is a novel and interesting use, which we are excited about. 
 

projects/keylime/keylime-sandbox-proposal.md

@@ -76,9 +76,9 @@ Keylime can provide remote:
   - If a targeted node **fails** its trust attestation, a signed event will be
   sent to all other nodes monitored by Keylime, instructing them to perform
   specific actions. This uses an open framework where any action that is
-  programtically possible can be triggered, such as:
+  programmatically possible can be triggered, such as:
    - Revoke TLS Certificates
-   - Fail over a sysem
+   - Fail over a system
    - Shutdown network / VPN interfaces
    - Remove host from SSH `known_hosts`
    - Call various APIs
@@ -176,14 +176,14 @@ ensure nothing has occurred to change the hash measurement of the file originall
 checked in by a developer and measured by [in-toto](https://in-toto.io/).
 
 Users of Keylime have demonstrated Keylime bootstrapping a Kubernetes cluster
-and monitoring a etcd cluser. A demonstration of this can be seen on the following
+and monitoring a etcd cluster. A demonstration of this can be seen on the following
 [YouTube video](https://www.youtube.com/watch?v=Qhr_aVBCZPw)
 
 The CNCF sandbox [parsec](https://github.com/parallaxsecond/parsec) project and
 Keylime our in discussion to have Keylime use the parsec [TSS crate](https://github.com/keylime/rust-keylime/issues/74#issuecomment-650206630)
 and our exploring closer integration of the two projects, as both teams see lots
 of synergy between Keylime and Parsec. Keylime orchestrates trust and Parsec
-abstracts secruity for the platform, so both projects have their own specialised
+abstracts security for the platform, so both projects have their own specialised
 area and do not try to solve the same issue.
 
 We would also like to explore synergies with the Notary v2 project and other
@@ -404,7 +404,7 @@ is required to have the agent deployed first.
 Keylime will benefit from CNCF positioning the project as a Remote Attestation
 trust project for cloud native technologies. It would also benefit from having
 the Governance and support available from being a CNCF project. It will also
-help to attact more developers and users to the project and help foster
+help to attract more developers and users to the project and help foster
 collaboration with other CNCF projects.
 
 **Has a security assessment by the security SIG been done? If not, what is the status/progress of

projects/kube-ovn/2023-Kube-OVN-annual.md

@@ -57,7 +57,7 @@ This year, we are continuing to add new features to Kube-OVN, as well as making
 
 Some key features and refactors added to the project:
 - A brand new Document website with all documents rewrite.
-- More underlay network features and optimization like overlay/underlay interconnection, better performance and more reslient.
+- More underlay network features and optimization like overlay/underlay interconnection, better performance and more resilient.
 - Refactor the Virtual Private Cloud (VPC) Network Address Translation (NAT) Gateway implementation to gain greater flexibility.
 - More VPC network functions like DHCP, DNS, and LoadBalance.
 - Use libovsdb to replace all the connection to OVN to achieve better performance.  

projects/kubedl/2022-kubedl-annual.md

@@ -2,8 +2,8 @@
 
 ## Table of Contents
 
-## Backgroud
+## Background
-KubeDL is a suite of Kubernentes controllers that enable running machine learning workloads on Kubernentes, such as model training and inferences, configuration tuning for model deployments.
+KubeDL is a suite of Kubernetes controllers that enable running machine learning workloads on Kubernetes, such as model training and inferences, configuration tuning for model deployments.
 Project website https://kubedl.io/
 
 ## DevStats
@@ -29,12 +29,12 @@ KubeDL has achieved great progress in adopting production usages. Many of the us
 KubeDL has also a number of contributors from research institutes and universities to innovate on forward-thinking features in ML infra to improve the scheduling and performance efficiency.
 
 ## Project Past
-KubeDL has added many significat features since last year.
+KubeDL has added many significant features since last year.
 - Accelerate training speed by natively integrating data cache.
 - Enhanced KubeDL dashboard for better interactive experiences.
 - Miscellaneous bug fixes and improvements.
 -
-KubeDL has also been under serveral summer of code projects, such as ASOC(link), xxx, where a number of students are actively participating.
+KubeDL has also been under several summer of code projects, such as ASOC(link), xxx, where a number of students are actively participating.
 
 KubeDL/Morphling project is honored to have a paper published at ACM SoCC 2021.
 
@@ -55,4 +55,4 @@ Community
 We focused a lot in enhancing the project quality to production grade, and continuously contribute our best practices in large production to the community. We have many users using KubeDL in production, but have not get many external contributors in community. We had short amount of resources. Next year, we will focus more on building more awareness of the project by writing more blogs, showcasing, and presentation in conferences, and hope to engage more users to contribute.
 
 ## Incubation
-KubeDL is not yet ready for incubation, though KubeDL has been used heavily at Alibaba in large scale. We would like to see more contributors and maintiners and more adopters.
+KubeDL is not yet ready for incubation, though KubeDL has been used heavily at Alibaba in large scale. We would like to see more contributors and maintainers and more adopters.

projects/kubeedge/2020-kubeedge-annual.md

@@ -106,9 +106,9 @@ KubeEdge falls in the scope of [CNCF Runtime SIG](https://github.com/cncf/sig-ru
         - EdgeSite
 
       - Added v1.1:
-        - CSI suuport on the Edge
+        - CSI support on the Edge
-        - Device CRD validaton
+        - Device CRD validation
-        - L4 Proxy suuport in EdgeMesh
+        - L4 Proxy support in EdgeMesh
 
       - Added v1.2:
         - Application layer reliable message delivery from cloud to edge

projects/kubeedge/kubeedge-graduation-proposal.md

@@ -90,7 +90,7 @@ The figure below shows the key nodes in the evolution of the KubeEdge project：
   - Governance doc
     - <https://github.com/kubeedge/community/blob/master/GOVERNANCE.md>
   - Established Technical Steering Committee:
-    - **7 members** from **6 companies**, 1 Arm, 1 Google, 2 Huawei, 1 DaoCloud, 1 HarmonyCloud, 1 KubeShpere
+    - **7 members** from **6 companies**, 1 Arm, 1 Google, 2 Huawei, 1 DaoCloud, 1 HarmonyCloud, 1 KubeSphere
     - <https://github.com/kubeedge/community/tree/master/committee-technical-steering>
   - Multiple SIGs established:
     - SIG AI
@@ -167,7 +167,7 @@ KubeEdge has been widely used in industries such as intelligent transportation,
 
 ### 1. Have committers from at least two organizations.
 
-KuhbeEdge community has 7 Technical Steering Committees from 6 companies, who are the governing body for the KubeEdge project, providing decision-making and oversight pertaining to the KubeEdge project bylaws. The Technical Steering Committee also defines the project values and structure.
+KubeEdge community has 7 Technical Steering Committees from 6 companies, who are the governing body for the KubeEdge project, providing decision-making and oversight pertaining to the KubeEdge project bylaws. The Technical Steering Committee also defines the project values and structure.
 
 KubeEdge has 10 core maintainers from 7 companies, who are responsible for maintaining code development for overall projects. And KubeEdge also has 15+ SIG maintainers who Focus on maintaining corresponding modules.
 

projects/kubescape/kubescape-incubation-proposal.md

@@ -241,7 +241,7 @@ The project's release process is documented in the [release file](https://github
 
 ## Security
 
-Note: this section may be augemented by a joint-assessment performed by TAG Security.
+Note: this section may be augmented by a joint-assessment performed by TAG Security.
 
 ### Suggested
 
@@ -261,7 +261,7 @@ The project should make additional improvements to its repository security postu
 
 - [X] **Document assignment of security response roles and how reports are handled.**
 
-The [central SECURITY.md](https://github.com/kubescape/project-governance/blob/main/SECURITY.md) file explains that maintainers are responsbile for responding to reported vulnerabilities and will test to confirm the existence of the reported vulnerability. They further detail the issuance of Security advisory after confirmed and the expected timelines for disclosure.
+The [central SECURITY.md](https://github.com/kubescape/project-governance/blob/main/SECURITY.md) file explains that maintainers are responsible for responding to reported vulnerabilities and will test to confirm the existence of the reported vulnerability. They further detail the issuance of Security advisory after confirmed and the expected timelines for disclosure.
 
 - [X] **Document Security Self-Assessment.**
 

projects/kubevirt/2020-KubeVirt-annual.md

@@ -66,7 +66,7 @@ An informal usage poll was conducted recently through
 [twitter](https://twitter.com/kubevirt/status/1319251272772603904) and
 [Slack](https://kubernetes.slack.com/archives/C8ED7RKFE/p1603368795347300). Of
 the ~100 respondents, a majority expressed that they are _evaluating_ KubeVirt
-at the moment. About 20% metioned a _development or pre-production_ use case,
+at the moment. About 20% mentioned a _development or pre-production_ use case,
 and around 5% had _production_ workloads.
 
 As highlighted by devstats we have also seen an increase in companies

projects/kubevirt/kubevirt-sandbox-proposal.adoc

@@ -70,7 +70,7 @@ non Red Hat contributors, and a few drive-by contributions.
 
 An https://kubevirt.io/api-reference/ is generated from OpenAPI definitions.
 
-*Release methodology and mechanics*: semver, a time based release process, with container artifatcs, all defined in
+*Release methodology and mechanics*: semver, a time based release process, with container artifacts, all defined in
 https://github.com/kubevirt/kubevirt/blob/master/docs/release.md
 
 *Project logo*: https://raw.githubusercontent.com/kubevirt/community/master/logo/KubeVirt_logo.png

projects/kuma/2021-kuma-annual.md

@@ -14,7 +14,7 @@
 
 By bundling the Envoy proxy as the underlying data-plane technology, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs, while at the same time providing a RESTful API, a native CLI tool and a built-in GUI that can be used to better integrate Kuma with the rest of the organization.
 
-While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networing stack.
+While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networking stack.
 
 
 **Kuma was accepted as a CNCF Sandbox project on June, 2020.**

projects/kuma/2022-kuma-annual.md

@@ -13,7 +13,7 @@
 
 By bundling the Envoy proxy as the underlying data-plane technology, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs, while at the same time providing a RESTful API, a native CLI tool and a built-in GUI that can be used to better integrate Kuma with the rest of the organization.
 
-While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networing stack.
+While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networking stack.
 
 
 **Kuma was accepted as a CNCF Sandbox project on June, 2020.**
@@ -75,11 +75,11 @@ The goals of Kuma remain building a simple service mesh that doesn't only work f
 We're still very much aligned with this goal.
 In 2022 we've shipped features like:
 
-- ZoneEgress, enabling users to funel traffic through some hosts, to accomodate restrictive networking setups
+- ZoneEgress, enabling users to funnel traffic through some hosts, to accommodate restrictive networking setups
 - New Policy API making our policies more flexible and easier to use.
 - Support for Gateway API
 - Native Gateway avoiding the need to run a 3rd party gateway
-- Fully rewrote transparent proxy to accomodate more non kubernetes use cases
+- Fully rewrote transparent proxy to accommodate more non kubernetes use cases
 - Move to a predictable versioning policy which frequent patches especially for security.
 
 ### What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
@@ -87,7 +87,7 @@ In 2022 we've shipped features like:
   - Technical
     - Performance improvements and qualification (we want to demonstrate that Kuma scales to O(10K) dataplanes and O(100) zones)
     - Make our new policy API default
-    - Simplify deployment topology for multi-zone setups. With the possibility to run Global and Zone in the same kubernes cluster.
+    - Simplify deployment topology for multi-zone setups. With the possibility to run Global and Zone in the same kubernetes cluster.
 
   - Community
     - Further, grow the number of contributors

projects/kuma/kuma-sandbox-proposal.md

@@ -19,7 +19,7 @@ Kuma is a modern control plane for Service Mesh and Microservices. It can run an
 
 By bundling the Envoy proxy as the underlying data-plane technology, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs, while at the same time providing a RESTful API, a native CLI tool and a built-in GUI that can be used to better integrate Kuma with the rest of the organization.
 
-While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networing stack.
+While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the `ProxyTemplate` policy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networking stack.
 
 ## Current Status
 
@@ -54,7 +54,7 @@ Kuma is currently being adopted by a few enterprise organizations to build zero-
 * WebAssembly support
 * Extending Health-Checking
 * Hooks for RBAC controls in RESTful API (+ CLI)
-* Internazionalization
+* Internationalization
 * Replicable benchmarks to demonstrate performance of Envoy as the sidecar proxy
 * ADA support for enterprise adoption
 * And more
@@ -97,7 +97,7 @@ We leverage the APIs of some projects (like Kubernetes) but we don't require _sp
 
 **_Does the project augment or benefit other CNCF projects?_**
 
-Kuma benefits the adoption of Envoy, Prometheus, Jager and of course Kubernetes.
+Kuma benefits the adoption of Envoy, Prometheus, Jaeger and of course Kubernetes.
 
 ## Anticipated use cases
 
@@ -342,7 +342,7 @@ Not at moment since we are in the process of donating, but it can obviously be a
 
 **_Are all defaults for upstream reporting either unset or community hosted infrastructure (i.e. doesn’t point to vendor hosted SaaS control plane or analytics server for usage data)? Is all project naming independent of vendors?_**
 
-We are using Google Analytics and Splunk on our accounts, but those can certainly be transfered.
+We are using Google Analytics and Splunk on our accounts, but those can certainly be transferred.
 
 **_Relevant Assets regarding vendor independence_**
 

projects/kyverno/2021-Kyverno-annual.md

@@ -96,7 +96,7 @@ The main goals of the project have been in the following categories:
 
 * **Availability**: Kyverno has added the ability to support multiple replicas for fault-tolerance and increased availability in Release 1.4.0 (June 2021).
 
-* **Scalability**: Several fixes and improvenents have been made to reduce memory usage and handle large clusters. This remains an on-going area of test and improvement.
+* **Scalability**: Several fixes and improvements have been made to reduce memory usage and handle large clusters. This remains an on-going area of test and improvement.
 
 * **Security**: Kyverno participated in the CNCF TAG Security [Security Pals](https://github.com/cncf/tag-security/issues/554) program. As a result, Kyverno has adopted recommended security best practices. The [Security](https://main.kyverno.io/docs/security/) section in the Kyverno documentation lists these and acts as a security guide for adopters.
 

projects/kyverno/kyverno-incubation-proposal.md

@@ -198,7 +198,7 @@ Kyverno uses the [Semantic Versioning scheme](https://semver.org/#semantic-versi
 
 ## Statement on Alignment with the CNCF Mission
 
-A recent [CNCF security survey](https://www.cncf.io/blog/2021/10/12/cloud-native-security-microsurvey-more-than-80-of-organizations-want-to-build-modern-security-systems-with-open-source-software/) revealed that more than 80% of organizations are looking for modern security systems with open source software. Kyverno's goal is to help address and close this gap. Kyverno secures and automates Kubernetes configurations by providing a powerful but easy-to-use policy engine that allows developers, operators, and security engineers to leverage policies as contracts for collaboration. By making Kubernetes easier to use and secure, Kyverno's mission directly aligns with the Foundations mission of making cloud native ubiquitious.
+A recent [CNCF security survey](https://www.cncf.io/blog/2021/10/12/cloud-native-security-microsurvey-more-than-80-of-organizations-want-to-build-modern-security-systems-with-open-source-software/) revealed that more than 80% of organizations are looking for modern security systems with open source software. Kyverno's goal is to help address and close this gap. Kyverno secures and automates Kubernetes configurations by providing a powerful but easy-to-use policy engine that allows developers, operators, and security engineers to leverage policies as contracts for collaboration. By making Kubernetes easier to use and secure, Kyverno's mission directly aligns with the Foundations mission of making cloud native ubiquitous.
 
 ## Comparison with Other CNCF Policy Management Projects
 

projects/litmuschaos/litmuschaos-incubation-proposal.md

@@ -51,9 +51,9 @@ LitmusChaos is predominantly used by the following persona:
 - Support for complex chaos workflows via Argo integration 
 - Steady-state hypothesis validation via Litmus Probes
 - Different modes (namespaced, admin/cluster)  of operation
-- Ability to source chaos artifacts from a Git backend & synchornize changes into the chaos-center
+- Ability to source chaos artifacts from a Git backend & synchronize changes into the chaos-center
 - Support for chaos on containerd, cri-o runtime 
-- Introduction of newer chaos types for both Kubernetes & cloud infratructure (AWS,GCP,Azure,VMware)
+- Introduction of newer chaos types for both Kubernetes & cloud infrastructure (AWS,GCP,Azure,VMware)
 - Improved suite of prometheus metrics for chaos experiments 
 
 #### Governance Summary: 
@@ -128,7 +128,7 @@ When we started the Litmus project, the goal of this project was to create a com
 Over time, the monthly cadence releases added the following features. 
 - Chaos experiments become building blocks of a ChaosWorkflow, to allow users to create a larger chaos scenarios. 
 - A portal to centrally visualize the chaos workflows, get chaos analytics, get the teaming in place for collaboration of chaos workflows.
-- Chaos GitOps for highly scalable automation of chaos workflows. Chaos can now be trigged as a result of a change to an application. This integrates with other CD tools like ArgoCD and FluxCD
+- Chaos GitOps for highly scalable automation of chaos workflows. Chaos can now be triggered as a result of a change to an application. This integrates with other CD tools like ArgoCD and FluxCD
 - Chaos Interleaved dashboards. A step toward open observability that is interleaved with chaos incident details
 
 With all these features, Litmus is a comprehensive platform for chaos engineering.

projects/litmuschaos/litmuschaos-sandbox-proposal.md

@@ -120,7 +120,7 @@ Litmus adheres to the “Cloud Native” principles (as explained in this blog [
 
 **Does the project align and actively collaborate with other CNCF projects?**
 
-Litmus provides full-featured chaos experiments for most of the Kubernetes resources. Currently, there are eleven different generic ways to introduce and manage chaos on Kubernetes cluster. Apart from this through chaos hub, we bring application level chaos experients for other eco system projects such as CoreDNS, Kafka, OpenEBS. 
+Litmus provides full-featured chaos experiments for most of the Kubernetes resources. Currently, there are eleven different generic ways to introduce and manage chaos on Kubernetes cluster. Apart from this through chaos hub, we bring application level chaos experiments for other eco system projects such as CoreDNS, Kafka, OpenEBS. 
 As part of its near-term roadmap, Litmus also is in the process of creating chaos charts for other sandbox/incubating/graduated CNCF projects. We are working with cncf-ci workgroup to include chaos stage in the CNCF projects. A PR is already in review for CoreDNS project.
 
 Litmus chaos experiments are being extensively used as part of CI pipelines of the OpenEBS, a CNCF sandbox project that provides containerized storage solution for Kubernetes. Reference: https://openebs.ci/
@@ -143,7 +143,7 @@ The project benefits other CNCF projects by helping harden their resiliency unde
 
 ### CI/CD:
 
-- Organizations can add "Kuberentes generic" and “application specific” chaos experiments as part of a “chaos stage” in their CI pipelines thereby enabling a left shift in improving fault tolerance and failure response. 
+- Organizations can add "Kubernetes generic" and “application specific” chaos experiments as part of a “chaos stage” in their CI pipelines thereby enabling a left shift in improving fault tolerance and failure response. 
 
 ### Kubernetes Upgrade Testing:
 
@@ -292,7 +292,7 @@ Orchestrated by Kubernetes natively. Litmus has a chaos-runner that runs in a co
 **How will the project benefit from acceptance into the CNCF?**
 
 - This project will have a vendor neutral home. The project will generate interest in many CNCF project members to contribute application level chaos experiments to the chaos hub when it is accepted into CNCF.
-- CNCF projects themselves may adopt Litmus more activly when accepted into CNCF.
+- CNCF projects themselves may adopt Litmus more actively when accepted into CNCF.
 
 **Has a security assessment by the security SIG been done? If not, what is the status/progress of the assessment?**
 

projects/longhorn/longhorn-incubation-proposal.md

@@ -90,7 +90,7 @@ Longhorn has joined the CNCF in October 2019. Since then, we've seen the tremend
 
 Longhorn has reached v1.0 GA this May, and we're planning to release v1.1 this November.
 
-### Community acivity
+### Community activity
 
 We're hosting community meeting and office hour every month. The community meeting recordings can be found at https://www.youtube.com/channel/UCGk1f-LCVmccf1pX4OvF1Ig .
 

projects/longhorn/longhorn-sandbox-proposal.md

@@ -6,7 +6,7 @@
 
 Longhorn is an open source distributed block storage software for Kubernetes. It is a lightweight and portable implementation of persistent storage that works for any Kubernetes cluster. The project implements distributed block device volumes that can be mounted as read-write by a single node (ReadWriteOnce).
 
-Longhorn is designed to leverage the existing Linux technologies as much as possible, rather than building a complex storage technology stack from scratch. The software takes advange of modern high-speed and high capacity SSD and NVMe storage, and proven Linux storage features like sparse files and cgroups.
+Longhorn is designed to leverage the existing Linux technologies as much as possible, rather than building a complex storage technology stack from scratch. The software takes advantage of modern high-speed and high capacity SSD and NVMe storage, and proven Linux storage features like sparse files and cgroups.
 
 The most distinct feature of Longhorn is to implement each volume as an independent microservice. By leveraging Kubernetes to orchestrate the volumes, it implements a highly feature-rich enterprise-grade distributed block storage system with about 30K line of Golang code.
 
@@ -26,7 +26,7 @@ Longhorn consists of the following major components:
 
 ***Engine and Replicas***
 
-The Longhorn engine is the microservice used to implement each volume. The engine implements the data plane of reading and writing the block devices. Each Longhorn volume is implemented using one engine and multiple replicas. The engine always runs on the same node as the pod consuming the volume, whereas Longhorn replicas reside on different nodes to ensure redundency.
+The Longhorn engine is the microservice used to implement each volume. The engine implements the data plane of reading and writing the block devices. Each Longhorn volume is implemented using one engine and multiple replicas. The engine always runs on the same node as the pod consuming the volume, whereas Longhorn replicas reside on different nodes to ensure redundancy.
 
 Longhorn delivers added resiliency because the data plane for each volume is separate. A software bug that causes one volume to malfunction does not impact other volumes in the system.
 

projects/meshery/2023-Meshery-annual.md

@@ -91,23 +91,23 @@ As a self-service engineering platform, Meshery enables collaborative design and
 
 Meshery has greatly expanded beyond it's initial service mesh-centric focus to support integrations (~220 currently) across the entire cloud native ecosystem. Meshery's configuration and orchestration abilities include a growing list of supported infrastructure.
 
-Meshery's [roadmap](https://github.com/meshery/meshery/blob/master/ROADMAP.md) has remained consistent over this past year. The community of contributors has been in execution mode, dialing now on it's final, planned architectural components to a v1.0. Signicant strides have been made with [Meshery's architecture](https://docs.meshery.io/concepts), including incorporation of WASM for OPA execution in it's UI client, a client-side user permissioning framework, delivery a [Docker Extension](https://docs.meshery.io/installation/platforms/docker-extension), the addition of support for Postgres, 6 new [extension points](https://docs.meshery.io/extensibility), self-documenting end-to-end test framework that includes a published [platform compability matrix](https://docs.meshery.io/installation/platforms), and a number of other features. Additionally, Meshery's community is blooming with Meshery LFX internship being the #1 most popular out of all of the LF.
+Meshery's [roadmap](https://github.com/meshery/meshery/blob/master/ROADMAP.md) has remained consistent over this past year. The community of contributors has been in execution mode, dialing now on it's final, planned architectural components to a v1.0. Signicant strides have been made with [Meshery's architecture](https://docs.meshery.io/concepts), including incorporation of WASM for OPA execution in it's UI client, a client-side user permissioning framework, delivery a [Docker Extension](https://docs.meshery.io/installation/platforms/docker-extension), the addition of support for Postgres, 6 new [extension points](https://docs.meshery.io/extensibility), self-documenting end-to-end test framework that includes a published [platform compatibility matrix](https://docs.meshery.io/installation/platforms), and a number of other features. Additionally, Meshery's community is blooming with Meshery LFX internship being the #1 most popular out of all of the LF.
 
 ## How can the CNCF help?
 
 ### Help promoting use of the [Cloud Native Playground](https://play.meshery.io)
 
-Under Meshery's mission to enable the ease by which and the collaborative nature by which cloud native infrastructure is managed, the Meshery project has created a cloud native playground - a CNCF playground -  in which all CNCF projects can be configured and deployed. This playground is being hosted in the CNCF labs. We could use the TOC's assistance in encouraging other CNCF projects to represent their deployment best practices in the [Meshery Catalog](https://meshery.io/catalog). Infrastructure designs available in the Meshery Catlaog represent patterns and templates that end users can quickly apply in their environments. Ideally, each CNCF project incoroprates their deployment models and suggested best practices into the catalog.
+Under Meshery's mission to enable the ease by which and the collaborative nature by which cloud native infrastructure is managed, the Meshery project has created a cloud native playground - a CNCF playground -  in which all CNCF projects can be configured and deployed. This playground is being hosted in the CNCF labs. We could use the TOC's assistance in encouraging other CNCF projects to represent their deployment best practices in the [Meshery Catalog](https://meshery.io/catalog). Infrastructure designs available in the Meshery Catalog represent patterns and templates that end users can quickly apply in their environments. Ideally, each CNCF project incorporates their deployment models and suggested best practices into the catalog.
 
 The Meshery Catalog is available in the cloud native playground and is an excellent resources for participating CNCF End User Organizations. It is of benefit to all projects and all end users.
 
 ### Uplifting of all Helm charts in Artifact Hub
 
-Meshery has the ability to visualize Helm charts and [screenshot the visualization](https://github.com/meshery/meshery/pull/8498#issuecomment-1681369650). We think this would be a valuable enhancement to users of Artifact Hub. Connecting the two projects for an exploratory discussion would be helfpul.
+Meshery has the ability to visualize Helm charts and [screenshot the visualization](https://github.com/meshery/meshery/pull/8498#issuecomment-1681369650). We think this would be a valuable enhancement to users of Artifact Hub. Connecting the two projects for an exploratory discussion would be helpful.
 
 ### Incubation Readiness Assessment and Project Sponsors
 
-The TOC can assist by highlighting any concerns in terms of Meshery's readyness for Incubation, identity Incubation sponsors, and to queue for due diligence, if appropriate.
+The TOC can assist by highlighting any concerns in terms of Meshery's readiness for Incubation, identity Incubation sponsors, and to queue for due diligence, if appropriate.
 
 ## Ready for Incubation?
 
@@ -126,7 +126,7 @@ Evidence of this can be seen under DevStats above.
 Meshery has had a clear versioning scheme (see [Build and Release](https://docs.meshery.io/project/contributing/build-and-release)) and a [regular release cadence](https://docs.meshery.io/project/releases).
 
 **Clearly documented security processes explaining how to report security issues**
-The [Security page](https://docs.meshery.io/project/security-vulnerabilities) in Meshery Docs page oulines the vulnerability reporting process, has a mailing list for reporting (security@meshery.dev), has a [published and resolved CVE](https://docs.meshery.io/project/security-vulnerabilities#list-of-announced-vulnerabilities).
+The [Security page](https://docs.meshery.io/project/security-vulnerabilities) in Meshery Docs page outlines the vulnerability reporting process, has a mailing list for reporting (security@meshery.dev), has a [published and resolved CVE](https://docs.meshery.io/project/security-vulnerabilities#list-of-announced-vulnerabilities).
 
 Meshery is at "[passing](https://bestpractices.coreinfrastructure.org/projects/3564)" level for Core Infrastructure Best Practices.
 

projects/metallb/2022-metallb-annual.md

@@ -52,7 +52,7 @@ There are three maintainers actively working on the project (alphabetically):
 ## Adoption
 
 MetalLB is probably the most popular solution for exposing services of type LoadBalancer in bare metal deployments. It is widely used by users running kubernetes in homelabs
-(an [issue opened](https://github.com/metallb/metallb/issues/1481#issuecomment-1176716132) agains MetalLB revealed a wide community of users in the k8s@home discord channel).
+(an [issue opened](https://github.com/metallb/metallb/issues/1481#issuecomment-1176716132) against MetalLB revealed a wide community of users in the k8s@home discord channel).
 MetalLB is part of [multiple tutorials and videos](https://www.google.com/search?q=metallb+kubernetes+tutorial) written by the community and suggested by multiple projects
 such as [kubespray](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/metallb.md), [kind](https://kind.sigs.k8s.io/docs/user/loadbalancer/) and [microk8s](https://microk8s.io/docs/addon-metallb) (to mention some).
 
@@ -91,7 +91,7 @@ adding support for loadbalancer class.
 
 <!-- What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation? -->
 
-MetalLB must continue to evolve with two goals in mind. On one hand it must keep being the (nearly) zero configuration load balancer that enables loadbalancers on Kubernetes clusters running on RaspberryPIs, on the other it must offer optional configuration knobs to accomodate the requirements of enterprise customers that are using MetalLB on more complex scenarios and topologies.
+MetalLB must continue to evolve with two goals in mind. On one hand it must keep being the (nearly) zero configuration load balancer that enables loadbalancers on Kubernetes clusters running on RaspberryPIs, on the other it must offer optional configuration knobs to accommodate the requirements of enterprise customers that are using MetalLB on more complex scenarios and topologies.
 
 On top of that, the project must keep being contributor friendly and open to discuss new feature requests and responsive to contributors willing to help.
 

projects/network-service-mesh/2020-Network Service Mesh-annual.md

@@ -47,7 +47,7 @@ Network Service Mesh does this without disturbing (and taking care not to break)
 by the runtime.  K8s Networking via CNI is untouched, and continues to work as expected.
 
 Network Service Mesh makes IP networking itself Cloud Native by loosely coupling with the existing 
-immutable infrastrcture in K8s to deliver whatever non-standard Networking needs a workload has with minimal toil.
+immutable infrastructure in K8s to deliver whatever non-standard Networking needs a workload has with minimal toil.
 
 NSM is a complement to higher level L7 Service Meshes (Linkerd), providing an additional 
 connectivity,security and observability at lower layers.

projects/network-service-mesh/2022-Network Service Mesh-annual.md

@@ -47,7 +47,7 @@ Network Service Mesh does this without disturbing (and taking care not to break)
 by the runtime.  K8s Networking via CNI is untouched, and continues to work as expected.
 
 Network Service Mesh makes IP networking itself Cloud Native by loosely coupling with the existing 
-immutable infrastrcture in K8s to deliver whatever non-standard Networking needs a workload has with minimal toil.
+immutable infrastructure in K8s to deliver whatever non-standard Networking needs a workload has with minimal toil.
 
 NSM is a complement to higher level L7 Service Meshes (Linkerd), providing an additional 
 connectivity,security and observability at lower layers.
@@ -106,7 +106,7 @@ Network Service Mesh had three release in the last year:
        *  Ericsson Software Technology
        *  Red Hat
     * [Commits](https://networkservicemesh.devstats.cncf.io/d/2/commits-repository-groups?orgId=1&from=now-1y&to=now&var-period=d7&var-repogroups=All)
-      have remainded strong in the last year.
+      have remained strong in the last year.
     
 2.  _How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)_
 
@@ -134,14 +134,14 @@ Network Service Mesh had three release in the last year:
 
 4. _How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)_
    Goals from last time:
-      - *v1.0.0 release.* - Done. The refactor of NSM took longer than expected, but NSM has now settled into a regular 60 day release candence.
+      - *v1.0.0 release.* - Done. The refactor of NSM took longer than expected, but NSM has now settled into a regular 60 day release cadence.
       - *Continue to expand and broaden the NSM community.* - NSM has increased the breath of maintainers overall, particularly in sub-maintainers for particular repos
       - *Grow adoption across: Service Provider* - “Ericsson is actively contributing to NSM to enable 5G specific use cases for cloud native network functions. We have multiple NSM based solutions in our roadmap, targeting live deployments by the end of 2022.”
       - *Grow adoption across: Edge/IoT* - "NSM is being considered in the Intel Smart Edge Open roadmap for Service Function Chaining (SFC) of FD.io VPP based Container Network Functions (CNFs)"
       - *Grow adoption across: Enterprise* - The NSM vL3 and Application Service Mesh over vL3 (see below) features need to be delivered to enable traction in Enterprise.
 
 5. _What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?_
-    1. Maintaining a regular (currently 60 day)  release candence.  Next scheduled release is [NSM v1.3.0](https://networkservicemesh.io/docs/roadmap/v1.3.0/)
+    1. Maintaining a regular (currently 60 day)  release cadence.  Next scheduled release is [NSM v1.3.0](https://networkservicemesh.io/docs/roadmap/v1.3.0/)
     2. Build out Enterprise Network Services:
       1. vL3 - Virtual L3 - a flat IP networking domain to which workloads from different clusters/clouds/etc can connect and over which they can communicate
       2. Application Service Mesh (L7) over vL3 (Note: This goal involves *running* an existing service mesh like Linkerd/Istio/OpenServiceMesh/Kuma over a Network Service Mesh provided vL3.  NSM will *not* be writing its own L7 functionality)

projects/open-policy-agent/opa-sandbox-proposal.md

@@ -157,7 +157,7 @@ allow {
 The first rule allows employees to GET their own salary. The rule shows how you can use variables in rules. In that rule, employee_id is
 a variable that will be bound to the same value across the last two expressions.
 
-The second rule allow employees to GET the salary of their reports. The rule shows how you can access arbirary context (e.g., JSON data)
+The second rule allow employees to GET the salary of their reports. The rule shows how you can access arbitrary context (e.g., JSON data)
 inside the policy. The data may loaded into the policy engine (and cached) or it may be external and fetched dynamically.
 
 

projects/open-telemetry/otel-incubation-proposal.md

@@ -25,7 +25,7 @@ OpenTelemetry is an integrated set of APIs and libraries that generate, collect,
 
 The project is made up of three major components:
 
-- [Specification](https://github.com/open-telemetry/opentelemetry-specification) with the [protos/defintions](https://github.com/open-telemetry/opentelemetry-proto) 
+- [Specification](https://github.com/open-telemetry/opentelemetry-specification) with the [protos/definitions](https://github.com/open-telemetry/opentelemetry-proto) 
 - Client libraries (APIs, SDKs, and instrumentation) -- language-specific. For example [Java](https://github.com/open-telemetry/opentelemetry-java) 
 - [Collector](https://github.com/open-telemetry/opentelemetry-collector/blob/master/docs/design.md)
 
@@ -167,7 +167,7 @@ Per signal, the roadmaps are:
 - Tracing: 1.0 specification, 1.0 DotNet, 1.0 Java, RC1 Python today; goal is 1.0 stability for all beta instrumentation libraries in next month. Collector tracing stability by mid-year.
 - Metrics: specification is expected to reach 1.0 around mid-year.
   - Prometheus & OpenMetrics data model & wire format compatibility will be reached by middle of 2021
-  - Full semantic, etc Prometheus compatibility including stalesness handling & up handling will be reached by end of 2021 will include full Prometheus & OpenMetrics compatibility. GA for instrumentation libraries is planned in 2H2021 for the languages with tracing GA support.
+  - Full semantic, etc Prometheus compatibility including staleness handling & up handling will be reached by end of 2021 will include full Prometheus & OpenMetrics compatibility. GA for instrumentation libraries is planned in 2H2021 for the languages with tracing GA support.
   - For more information, please refer to this published [roadmap](https://medium.com/opentelemetry/opentelemetry-metrics-roadmap-f4276fd070cf)
 - Logs are currently not a focus area, and not expected to be finished within 2021
   - For more information, please refer to the Logging section within this [document](https://docs.google.com/document/d/1vV3teqg9vmpaxgMS8JiQDghUcnpd3Qunq_tJu9sQaRE/edit?usp=sharing)

projects/opencost/2022-opencost-annual.md

@@ -101,4 +101,4 @@ We appreciate the support provided by the CNCF and look forward to participating
 
 ## Incubation
 
-We have submitted a [proposal for OpenCost Incubuation](https://github.com/cncf/toc/pull/1046/) and are working with our TOC Sponsor Ricardo Rocha. We are presenting to the TAG Observability September 19, 2023.
+We have submitted a [proposal for OpenCost Incubation](https://github.com/cncf/toc/pull/1046/) and are working with our TOC Sponsor Ricardo Rocha. We are presenting to the TAG Observability September 19, 2023.

projects/opencost/opencost-incubation.md

@@ -105,7 +105,7 @@ Since becoming a CNCF Sandbox project last year OpenCost has continued to releas
 The initial OpenCost [governance model](https://github.com/opencost/opencost/blob/develop/GOVERNANCE.md) has been released, aligning with the [CNCF best practices](https://www.cncf.io/blog/2019/08/30/cncf-technical-principles-and-open-governance-success/). There are 3 levels of membership:
 
 * Contributors to the project may be invited to join the OpenCost community as Members, which adds them to the GitHub OpenCost organization.   
-* [Members](https://github.com/orgs/opencost/teams/opencost-community) with sustained contributions may be invited to become Commiters and review and manage issues for the project.   
+* [Members](https://github.com/orgs/opencost/teams/opencost-community) with sustained contributions may be invited to become Committers and review and manage issues for the project.   
 * [Committers](https://github.com/orgs/opencost/teams/opencost-committers) with sustained involvement with the project may be invited to become Maintainers, granting them further repository privileges and decision-making authority over the direction of the project.
 
 Currently Kubecost’s technical team contributes most of the code submissions to OpenCost based on the inputs and feedback from Kubecost Product Management and issues and PRs raised from the OpenCost community. 
@@ -338,7 +338,7 @@ The security process for OpenCost is documented in the [SECURITY.md](https://git
 * February 27, 2023: OpenCost announced as a [FinOps Certified Solution](https://www.opencost.io/blog/finops-certified-solution).  
 * February 28, 2023: Kick-off for the [External Asset Costs Working Group](https://docs.google.com/document/d/1-d-Vvy1VGHW0sXKiTjTplIUEnrElIlnfMU8sUpEehlA/edit), which will bring support for services not directly managed by the Kubernetes infrastructure.  
 * March 9-12, 2023: OpenCost booth and [presentation](https://www.slideshare.net/mattray/scale-20x-kubernetes-cloud-cost-monitoring-with-opencost-optimization-strategies) at the Southern California Linux Expo.  
-* April 18, 2023: [Microsoft announces they have joined the OpenCost communit](http://aka.ms/aks/OpenCost-AKS)y with code and feature contributions and a new [Azure Billing Rate Card API](https://www.opencost.io/docs/azure-prices) supporting OpenCost.  
+* April 18, 2023: [Microsoft announces they have joined the OpenCost community](http://aka.ms/aks/OpenCost-AKS)y with code and feature contributions and a new [Azure Billing Rate Card API](https://www.opencost.io/docs/azure-prices) supporting OpenCost.  
 * April 18-21, 2023: OpenCost has a full-time staffed kiosk at KubeCon EU in the Project Pavilion.  
 * June 27, 2023: [Grafana Cloud announces their inclusion of OpenCost](https://www.opencost.io/blog/grafana-cloud) in their commercially supported Kubernetes Monitoring product.  
 * June 27, 2023: OpenCost announces participation in the [FinOps Open Cost and Usage Specification](https://www.opencost.io/blog/focus) (FOCUS) while attending the FinOps X conference.  

projects/openebs/2021-openebs-annual.md

@@ -24,7 +24,7 @@ OpenEBS was approved as a [CNCF Sandbox Project on May 14th, 2019](https://githu
 
 ## Develoment metrics
 
-Here are a few highligths from the project's [devstats page](https://openebs.devstats.cncf.io/), looking at the 1 year period after
+Here are a few highlights from the project's [devstats page](https://openebs.devstats.cncf.io/), looking at the 1 year period after
 2020 annual review (Jul 2020 - Jun 2021):
 
  - This year we welcomed [101 new contributors](https://openebs.devstats.cncf.io/d/52/new-contributors-table?orgId=1&from=1593455400000&to=1625077799000) across our repositories.
@@ -78,20 +78,20 @@ Our goals from last year annual review were:
   - Enhance Jiva to make use of OpenEBS Local Volumes instead of `hostpath` volumes
   - Enhance Jiva and cStor volumes to deal with Read-only mounts and multi-attach errors that happen due a abrupt node reboots 
   - Support for multi-arch images - with native support for AMD64 and ARM64
-  - Enhance Local PV volumes to be backed by LVM and Device partitions in addition to hospath and ZFS from earlier releases
+  - Enhance Local PV volumes to be backed by LVM and Device partitions in addition to hostpath and ZFS from earlier releases
   - Enhance OpenEBS velero plugin to perform ZFS Local PV incremental backups 
   - Enhance Mayastor to handle Kubernetes node failure scenarios. Working closely with the upstream SPDK community to push NVMe and other fixes 
   - Migrating all the CI pipelines to GitHub Actions
   - Refactor and modularize our system (e2e) tests so that they can be run against a data engine. Helps to release each engines independently
   - Refactor and modularize the helm charts to release each data engine independently to allow users to install only the required components
-  - Split most of the mono repos into functionality based repos for better managebility and contributor experience
+  - Split most of the mono repos into functionality based repos for better manageability and contributor experience
    
 **What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?**
 
 Our goals for the next year will be focused on:
   - Continue to progress on hitting the GA for all the data engines by listening to users and working on the [planned items](https://github.com/openebs/openebs/blob/master/ROADMAP.md) 
   - Focus more on community, reference architectures and solution documents that can increase the adoption of Kubernetes for running Stateful workloads. 
-  - Follow through with the feedback being recieved from the CNCF Storage TAG to help with Incubation of the project
+  - Follow through with the feedback being received from the CNCF Storage TAG to help with Incubation of the project
 
 
 ## CNCF membership
@@ -100,7 +100,7 @@ Our goals for the next year will be focused on:
 
 First off, thank you for all the help and support provided by CNCF team in the past year in the following areas for the OpenEBS project:
 * Guidance on the licensing related questions from CNCF legal and coaching from the CNCF Storage TAG on how to address some of the concerns. 
-* Providing venues during KubeCon for presening Project Office hours 
+* Providing venues during KubeCon for presenting Project Office hours 
 * CNCF Mentorship and Bugbash programs that have helped with increasing the contributions to the project. 
 * Helping on queries related to process and governance. 
 

projects/openelb/2022-OpenELB-annual.md

@@ -16,7 +16,7 @@ This is a Kubernetes ToC Annual Review for the [OpenELB](https://openelb.io/) pr
 
 OpenELB is an open-source load balancer implementation designed for exposing the LoadBalancer type of Kubernetes services in bare metal, edge, and virtualization environments.
 
-In cloud-based Kubernetes clusters, Services are usually exposed by using load balancers provided by cloud vendors. However, cloud-based load balancers are unavailable in bare-metal or on-premise environments. OpenELB allows users to create LoadBalancer Services in bare-metal, egde, and virtualization environments for external access, and provides the same user experience as cloud-based load balancers.
+In cloud-based Kubernetes clusters, Services are usually exposed by using load balancers provided by cloud vendors. However, cloud-based load balancers are unavailable in bare-metal or on-premise environments. OpenELB allows users to create LoadBalancer Services in bare-metal, edge, and virtualization environments for external access, and provides the same user experience as cloud-based load balancers.
 
 ## Development metrics
 

projects/openmetrics/openmetrics-sandbox-proposal.md

@@ -47,7 +47,7 @@ Given the CNCF's stated role in "fostering the growth and evolution of the ecosy
 
 OpenMetrics currently depends on no external software components.
 
-Once the test suite is released, it will depend on Go and Python and some libraries. Proper licence hygiene will be ensured.
+Once the test suite is released, it will depend on Go and Python and some libraries. Proper license hygiene will be ensured.
 
 *Lead:* * Richard Hartmann (SpaceNet)
 

projects/openyurt/2024-OpenYurt-incubation.md

@@ -11,7 +11,7 @@
 [Ricardo Rocha](https://github.com/rochaporto) conducted both due diligence and adopter interviews for Incubation. The project has completed the criteria that shows its maturity at the applied level.
 
 The TOC would like to highlight some areas from the project review:
-* OpenYurt has an active and diverse community, and adopters have highlighted this as one of its main strenghts
+* OpenYurt has an active and diverse community, and adopters have highlighted this as one of its main strengths
 * Its architecture extends instead of replacing existing core components in Kubernetes. This is an approach that differentiates it from other solutions in the ecosystem and that was also highlighted as a key strength by adopters
 * The governance and contributors guides are well defined but were last updated over 3 years ago. The TOC suggests a review together with TAG Contributor Strategy to consider if improvements can be made to the current member roles and contributor ladder
 
@@ -306,7 +306,7 @@ Interaction with the project happens mostly via GitHub issues, with TikTok and W
 
 ###### Strengths and Improvements
 
-Adopter 1 seeds the added networking stability to standard kubernetes as one of the main strenghs, particularly important for edge workloads. The additional primitive for managing `nodepools` is also a valuable addition to the standard `daemonset` and `deployment`.
+Adopter 1 seeds the added networking stability to standard kubernetes as one of the main strengths, particularly important for edge workloads. The additional primitive for managing `nodepools` is also a valuable addition to the standard `daemonset` and `deployment`.
 
 Adopter 1 sees installation as the main pain point and sees the same happening with other end users. No single installation method is ideal, leading to distinct methods depending on the use case.
 
@@ -336,13 +336,13 @@ Adopter 2 would like to see better multi-tenancy support, including tenant separ
 
 ##### Adopter 3 - Financial and Industrial Services
 
-Adotper 3 is an engineer working on Kubernetes for over 4 years and responsible for cloud edge products for over 2 years, in close contact with the OpenYurt project. Adopter 3 is responsible for financial and industrial products.
+Adopter 3 is an engineer working on Kubernetes for over 4 years and responsible for cloud edge products for over 2 years, in close contact with the OpenYurt project. Adopter 3 is responsible for financial and industrial products.
 
 ###### Usage
 
 Adopter 3 chose OpenYurt as it extends existing vanilla kubernetes deployments, allowing for an edge solution that is compatible with existing clusters. This gave a solution that is less intrusive than other projects such as KubeEdge.
 
-Adopter 3 runs OpenYurt for production workloads in multiple deployments, including a major electricity provider in China as well as smaller providers around the country. This includes the monitoring of 1000s of electicity sub-stations, with a setup where OpenYurt is deployed along KubeVirt. This solutions has been in place for almost 2 years.
+Adopter 3 runs OpenYurt for production workloads in multiple deployments, including a major electricity provider in China as well as smaller providers around the country. This includes the monitoring of 1000s of electricity sub-stations, with a setup where OpenYurt is deployed along KubeVirt. This solutions has been in place for almost 2 years.
 
 Adopter 3 follows the upstream releases closely.
 

projects/operator-framework/operator-framework-incubation-proposal.md

@@ -27,7 +27,7 @@ The Operator Framework expands the Kubernetes ecosystem to empower users with an
 
 *Unique identifier:* operator-framework
 
-*Prefered Maturity Level*: incubating
+*Preferred Maturity Level*: incubating
 
 *License*: Apache License v2.0
 

projects/oras/2022-oras-annual.md

@@ -68,7 +68,7 @@ ORAS 0.15 and future milestones will provide more capabilities to easily manage
 - Be able to manage repository, tag, manifest, and blob
 - Support and migrate to OCI reference types
 - Support push, discover, pull, copy artifacts from OCI Image Layout
-- Support all OCI-compatitable registries
+- Support all OCI-compatible registries
 - Add E2E testing to enhance the project quality and stability
 
 See the ORAS [Roadmap](https://github.com/oras-project/community/blob/main/Roadmap.md) for more details.

projects/parsec/2021-Parsec-annual.md

@@ -2,7 +2,7 @@
 
 ## Project Summary
 
-Parsec is the Platform Abstraction for Security. Parsec is creating convenient and portable interfaces to hardware security on any platform in any programming language. Parsec is deployed as a local software service (or daemon), which executes in user space on Linux systems. The software service contains back-end provider modules that offer compatibility with various hardware or firmware services for secure storage and cryptography, including Trusted Platform Modules (TPM), Hardware Security Modules (HSM), secure elemements or trusted firmware. Applications consume these services using a convenient and portable API. The Parsec API can be made available in any programming language, given the availability of a suitable client library. The end result is that applications are able to consume the best-available hardware security of their host platform, without being tightly coupled to the often complex and specialised APIs and software stacks that are otherwise needed.
+Parsec is the Platform Abstraction for Security. Parsec is creating convenient and portable interfaces to hardware security on any platform in any programming language. Parsec is deployed as a local software service (or daemon), which executes in user space on Linux systems. The software service contains back-end provider modules that offer compatibility with various hardware or firmware services for secure storage and cryptography, including Trusted Platform Modules (TPM), Hardware Security Modules (HSM), secure elements or trusted firmware. Applications consume these services using a convenient and portable API. The Parsec API can be made available in any programming language, given the availability of a suitable client library. The end result is that applications are able to consume the best-available hardware security of their host platform, without being tightly coupled to the often complex and specialised APIs and software stacks that are otherwise needed.
 
 The main Parsec repository can be found [here](https://github.com/parallaxsecond/parsec). There are several satellite repositories in the same organisation.
 
@@ -32,7 +32,7 @@ Across the individual repositories that make up the project, a contribution summ
 
 - The number of individual GitHub repositories has grown from 9 to 14 as new client libraries and back-end provider integrations have been contributed.
 - A total of [559 pull requests](https://github.com/pulls?page=1&q=is%3Amerged+is%3Apr+user%3Aparallaxsecond+archived%3Afalse+merged%3A%3E%3D2020-07-01) were successfully merged from 19 separate contributors.
-- The number of contributing organisations has grown from three to six. The project has also seen some indepedent contributions in the community.
+- The number of contributing organisations has grown from three to six. The project has also seen some independent contributions in the community.
 
 ## Maintainers
 

projects/piraeus-datastore/2022-Piraeus-Datastore-annual.md

@@ -52,7 +52,7 @@ as faster execution in comparison to userspace solutions, at the cost of some po
 
 Last year we saw the first major contributions from a community member:
 
-* Automatically setting up secured communications betweenc components with generated TLS certificates. [piraeus-operator#263](https://github.com/piraeusdatastore/piraeus-operator/pull/263)
+* Automatically setting up secured communications between components with generated TLS certificates. [piraeus-operator#263](https://github.com/piraeusdatastore/piraeus-operator/pull/263)
 * Making our scheduler plugin independent of the STORK project. [github project](https://github.com/piraeusdatastore/linstor-scheduler-extender/)
 
 ###  Releases

projects/rkt/rkt-archive-review.md

@@ -1,6 +1,6 @@
 # Rkt Archiving Review
 
 The rkt project has decreased in activity over time, with the number of [contributors decreasing](
-https://all.devstats.cncf.io/d/54/project-health-table?orgId=1&var-repogroup_name=rkt) steadidly over the last year with no issues being closed in the last three months. There have been [no new maintainers](https://github.com/rkt/rkt/commits/master/MAINTAINERS) added to the project in the last couple of years. The rkt project also has [unpatched](https://github.com/rkt/rkt/issues/3999) [CVEs](https://www.twistlock.com/labs-blog/breaking-out-of-coresos-rkt-3-new-cves).
+https://all.devstats.cncf.io/d/54/project-health-table?orgId=1&var-repogroup_name=rkt) steadily over the last year with no issues being closed in the last three months. There have been [no new maintainers](https://github.com/rkt/rkt/commits/master/MAINTAINERS) added to the project in the last couple of years. The rkt project also has [unpatched](https://github.com/rkt/rkt/issues/3999) [CVEs](https://www.twistlock.com/labs-blog/breaking-out-of-coresos-rkt-3-new-cves).
 
 The TOC is recommending the archival of the rkt project as a CNCF project, which means it will no longer be actively promoted or supported as a CNCF project.

projects/rkt/rkt-incubation-proposal.adoc

@@ -6,7 +6,7 @@
 
 rkt is an application container engine developed for modern production cloud-native environments. It features a pod-native approach, a pluggable execution architecture, and a well-defined surface area that makes it ideal for integration with other systems.
 
-The core execution unit of rkt is the _pod_, a collection of one or more applications executing in a shared context. (rkt's pods are synoymous with [the concept in the Kubernetes orchestration system](https://kubernetes.io/docs/user-guide/pods/#what-is-a-pod)). rkt allows users to apply different configurations (like isolation parameters) at both pod-level and at the more granular per-application level. rkt's architecture means that each pod executes directly in the classic Unix process model (i.e. there is no central daemon), in a self-contained, isolated environment.
+The core execution unit of rkt is the _pod_, a collection of one or more applications executing in a shared context. (rkt's pods are synonymous with [the concept in the Kubernetes orchestration system](https://kubernetes.io/docs/user-guide/pods/#what-is-a-pod)). rkt allows users to apply different configurations (like isolation parameters) at both pod-level and at the more granular per-application level. rkt's architecture means that each pod executes directly in the classic Unix process model (i.e. there is no central daemon), in a self-contained, isolated environment.
 
 rkt's daemonless model makes it highly suitable for integration with process managers like systemd, or for embedding in agents like the kubelet or Mesos agent. Its "staged" architecture - separating the user interface from its containerisation phase - allows it to support different isolation technologies: the mainstream rkt project includes implementations like QEMU and LKVM, as well as the default "classic" Linux containers implementation of cgroups and namespaces. Furthermore, while rkt development is currently targeted primarily at GNU/Linux distributions, the staged architecture makes it possible to extend support to other platforms without fundamentally changing rkt's external interfaces.
 

projects/rook/rook-sandbox-proposal.adoc

@@ -110,7 +110,7 @@ Statement from Quantum: In 2016 as part of ongoing product development work we i
 
 Existing approaches to running distributed storage systems like Ceph and Gluster focus primarily on packaging in containers, initial deployment, and bootstrapping. There is no central controller that is responsible for ongoing operations, dynamic management and maintenance of such storage systems. While some of these operations can be handled by the orchestration platform itself (for example, scaling through stateful-sets in Kubernetes) the approach only covers a small subset of the administration tasks and does not take into account the inherent constraints and guarantees of the backend storage system. For example, growing a cluster in Ceph not only requires scheduling more storage nodes but also updating the storage topology to optimize data access and improve durability all without breaking consistency guarantees. Rook's storage controller is responsible for ongoing and dynamic management of the storage system and it does so in a storage backend specific way.
 
-Rook introduces new abstractions for storage clusters, pools, volumes, volume-attachements, snapshots and others that are extension points of the cloud-native environment. This leads to a deeper integration into cloud-native environments. Other approaches like gluster-kubernetes and ceph-container rely on their own storage API for management and integrate primarily at the volume plugin level, and not the storage service level.
+Rook introduces new abstractions for storage clusters, pools, volumes, volume-attachments, snapshots and others that are extension points of the cloud-native environment. This leads to a deeper integration into cloud-native environments. Other approaches like gluster-kubernetes and ceph-container rely on their own storage API for management and integrate primarily at the volume plugin level, and not the storage service level.
 
 Finally Rook is designed to run primarily as an application of cloud-native systems minimizing (and eventually eliminating all dependencies) on the host platform. For example, Rook runs using the Kubernetes networking, whereas other approach like ceph-container require host networking.
 

projects/serverless-workflow/2022-ServerlessWorkflowSpecification-annual.md

@@ -47,7 +47,7 @@ This year was for stabilization and discussions around the upcoming 1.0 release.
 
 * Two new releases for the [sdk-java](https://github.com/serverlessworkflow/sdk-java/releases)
 * One new release for the [sdk-typescript](https://github.com/serverlessworkflow/sdk-typescript/releases)
-* Four new releses for the [sdk-go](https://github.com/serverlessworkflow/sdk-typescript/releases)
+* Four new releases for the [sdk-go](https://github.com/serverlessworkflow/sdk-typescript/releases)
 * Seven minor releases for the [sdk-net](https://github.com/serverlessworkflow/sdk-net/tags)
 * Four minor releases for the [Synapse](https://github.com/serverlessworkflow/synapse/releases) runtime
 * Added [sdk-python](https://github.com/serverlessworkflow/sdk-python), a Python SDK into our ecosystem
@@ -95,7 +95,7 @@ Most notable adoptions have been by:
 - [OpenShift Serverless Logic](https://developers.redhat.com/articles/2022/08/15/how-openshift-serverless-logic-evolved-improve-workflows), a Red Hat product under Tech Preview integrated with their flagship product, OpenShift
 - [Synapse](https://github.com/serverlessworkflow/synapse), a Kubernetes-based workflow runtime which has joined the Serverless Workflow ecosystem
 
-These are the companies that have adopeted the Serverless Workflow Specification:
+These are the companies that have adopted the Serverless Workflow Specification:
 
 <!-- Alphabetical order -->
 - [CAF](https://caf.io), Serverless Workflow is the core technology behind every KYC/KYB solution allowing them to customize it for their clients seamlessly.

projects/serverless-workflow/sw-sandbox-proposal.md

@@ -109,7 +109,7 @@ Apache License v2.0
 
 CNCF Serverless WG repository (workflow directory): https://github.com/cncf/wg-serverless/tree/master/workflow
 
-**External dependencie**:
+**External dependencies**:
 
 None
 

projects/spiffe-spire/spiffe-sandbox-proposal.adoc

@@ -68,7 +68,7 @@ SPIFFE has the following primary mailing lists, nearly all of which were used pr
 
 * [Discussions] Developers & Contributors (link:https://groups.google.com/a/spiffe.io/forum/#!forum/dev-discussion[website]): used by The purpose of this Google Group is for SPIFFE developers and contributors to discuss design and implementation issues.
 
-* [Discussions] Users (link:https://groups.google.com/a/spiffe.io/forum/#!forum/user-discussion[website]): The purpose of this Groogle Group is to give feedback, ask questions, and interact with the SPIFFE community. You can also check out SPIFFE on GitHub.
+* [Discussions] Users (link:https://groups.google.com/a/spiffe.io/forum/#!forum/user-discussion[website]): The purpose of this Google Group is to give feedback, ask questions, and interact with the SPIFFE community. You can also check out SPIFFE on GitHub.
 
 * [SIG] Components (link:https://groups.google.com/a/spiffe.io/forum/#!forum/sig-components[website]): The purpose of this Google Group is to discuss items related to the components and APIs tied to SPIFFE's reference implementation (SPIRE) and its architecture. Topics such as role of Node Agent vs. Cluster CA, API semantics, and others serve as good examples of what's to be discussed.
 

projects/spiffe-spire/spiffe-spire-graduation-proposal.md

@@ -53,7 +53,7 @@ The SPIFFE community holds regular meetups and community days, and runs an annua
 
   
 
-SPIRE has 5 committers from 3 different organizations. SPIFFE has 4 comitters from 3 different organizations. The steering committee has 5 members from 4 organizations.
+SPIRE has 5 committers from 3 different organizations. SPIFFE has 4 committers from 3 different organizations. The steering committee has 5 members from 4 organizations.
 
   
 

projects/spiffe-spire/spiffe-spire-incubation-proposal.md

@@ -2,7 +2,7 @@
 
 The SPIFFE and SPIRE projects were open-sourced in December 2017. The projects were accepted into the CNCF in March 2018. The projects have grown significantly over time.
 
-The following application links to the required information to become an incubation project. Additionally, a due diligence document has been prepared to assist in the proposal review is accesible at: https://docs.google.com/document/d/1tkN9YgBSLEUszOflWPHO72qedOaUb3iHfAye45dKJT8/
+The following application links to the required information to become an incubation project. Additionally, a due diligence document has been prepared to assist in the proposal review is accessible at: https://docs.google.com/document/d/1tkN9YgBSLEUszOflWPHO72qedOaUb3iHfAye45dKJT8/
 
 
 ## SPIFFE/SPIRE fulfills all the incubation criteria:

projects/strimzi/strimzi-sandbox-proposal.adoc

@@ -55,7 +55,7 @@ Apache Kafka is very popular as infrastructure technology for supporting cloud-n
 
 *Unique identifier:* strimzi
 
-*Prefered Maturity Level*: Sandbox
+*Preferred Maturity Level*: Sandbox
 
 *License*: Apache License v2.0
 

projects/superedge/2022-SuperEdge-annual.md

@@ -86,7 +86,7 @@ Belows are just the list of companies that we know have deployed SuperEdge in th
 Since joining the CNCF, SuperEdge has published key features:
 
 - NodeUnit and NodeGroup enhancement to use CRD to manipulate the Node Pools
-- Lite-apiserver enhancement to cache critical resources with the puropse of reducing network traffic
+- Lite-apiserver enhancement to cache critical resources with the purpose of reducing network traffic
 - Application-grid-wrapper support to watch `Ingress` resource to enable `nginx-ingress-controller` at NodeUnit
 - Reconstruct `Tunnel` architecture to support Cloud and Edge Level 7 communication
 - Originally release `Kins` feature to support whole lifecycle management of edge K*s cluster

projects/telepresence/2021-telepresence-annual.md

@@ -89,12 +89,12 @@ Throughout our development efforts, we have put an emphasis on improving the use
 ### Current Goals
 
 With the work done in the past year, we believe we have created a strong foundation for the Telepresence project. Our focus this year is to grow adoption of Telepresence by removing the friction and limitations users may experience. To do this our initial areas of focus include:
-* Developing a native Windows client and support Windows as a first-class operation system along with macOS and Lunux
+* Developing a native Windows client and support Windows as a first-class operation system along with macOS and Linux
 * Improve deployment in Restricted Environments
 * Enable running Telepresence in CI for integration testing
 * Improve performance and scalability of Telepresence
 
-Over the past year, we have significantly increased our contribution to Telepresence. The devastats metrics above highlight the increasing number of commits over the past six months. Some of that contribution has been directed towards improving community accessibility. With an improved pipeline in place we would like to increase the number of contributors to Telepresence to accelerate development on Telepresence even more:
+Over the past year, we have significantly increased our contribution to Telepresence. The devstats metrics above highlight the increasing number of commits over the past six months. Some of that contribution has been directed towards improving community accessibility. With an improved pipeline in place we would like to increase the number of contributors to Telepresence to accelerate development on Telepresence even more:
 * Add non-Ambassador Labs maintainers
 * Improve developer focused documentation to enable committers
 * Increase outreach to our community and recruit committers

projects/telepresence/2022-telepresence-annual.md

@@ -51,7 +51,7 @@ There have also been a number of integrations with other software stacks includi
 * Kelda (https://kelda.io/docs/tutorials/telepresence/)
 * Ambassador Cloud/Developer Control Pane (https://www.getambassador.io/)
 
-From a user standpoint, we have been engaging with the Telepresence community and growing the user base. The #telepresence slack channel has around 7700 members now and continues to be a great way for us to keep in touch with the community and receive feedback. We hold a live troubleshoting session through the channel weekly and usually work through 1-2 users issues. We also hold a monthly Maintainers meeting attended by our development team and open to anyone to ask questions, discuss features, etc.
+From a user standpoint, we have been engaging with the Telepresence community and growing the user base. The #telepresence slack channel has around 7700 members now and continues to be a great way for us to keep in touch with the community and receive feedback. We hold a live troubleshooting session through the channel weekly and usually work through 1-2 users issues. We also hold a monthly Maintainers meeting attended by our development team and open to anyone to ask questions, discuss features, etc.
 
 Some feedback we have received through these channels include:
 
@@ -68,7 +68,7 @@ Ao Chen "I'm excited to find such a wonderful tool as telepresence. Thanks and t
 
 Last year we stated that our primary goal was to grow our userbase by removing barriers to adoption, and presented the following goals:
 
-* Developing a native Windows client and support Windows as a first-class operation system along with macOS and Lunux
+* Developing a native Windows client and support Windows as a first-class operation system along with macOS and Linux
 * Improve deployment in Restricted Environments
 * Enable running Telepresence in CI for integration testing
 * Improve performance and scalability of Telepresence

projects/telepresence/2023-telepresence-annual.md

@@ -52,7 +52,7 @@ There have also been a number of integrations with other software stacks includi
 * Kelda (https://kelda.io/docs/tutorials/telepresence/)
 * Ambassador Cloud/Developer Control Pane (https://www.getambassador.io/)
 
-From a user standpoint, we have been engaging with the Telepresence community and growing the user base. The #telepresence slack channel has around 7700 members now and continues to be a great way for us to keep in touch with the community and receive feedback. We hold a live troubleshoting session through the channel weekly and usually work through 1-2 users issues. We also hold a monthly Maintainers meeting attended by our development team and open to anyone to ask questions, discuss features, etc.
+From a user standpoint, we have been engaging with the Telepresence community and growing the user base. The #telepresence slack channel has around 7700 members now and continues to be a great way for us to keep in touch with the community and receive feedback. We hold a live troubleshooting session through the channel weekly and usually work through 1-2 users issues. We also hold a monthly Maintainers meeting attended by our development team and open to anyone to ask questions, discuss features, etc.
 
 Some feedback we have received through these channels include:
 

projects/thanos/thanos-incubation-proposal.md

@@ -21,7 +21,7 @@ and were using the project on the production from the earliest days. [This blog
 describes the usage in detail here.
 * [Monzo](https://monzo.com/) is UK’s banking startup that was one of the earliest adopters and contributors to Thanos. 
 They described their success in detail [in this blog post](https://monzo.com/blog/2018/07/27/how-we-monitor-monzo).
-* [uSwitch](https://www.uswitch.com/) shared their expierience [on Medium](https://medium.com/uswitch-labs/making-prometheus-more-awesome-with-thanos-fbec8c6c28ad).
+* [uSwitch](https://www.uswitch.com/) shared their experience [on Medium](https://medium.com/uswitch-labs/making-prometheus-more-awesome-with-thanos-fbec8c6c28ad).
 * [Alibaba Cloud](https://us.alibabacloud.com/) presented their usage of Thanos during CNCF KubeCon China 2019. Video is available [here](https://www.youtube.com/watch?v=ZS6zMksfipc).
 * [Red Hat](https://www.redhat.com/) is using Thanos in production. One of the usages was described [here](https://blog.openshift.com/federated-prometheus-with-thanos-receive/). 
 * [HelloFresh](https://engineering.hellofresh.com/) and their blog post about the Thanos usage is available [here](https://engineering.hellofresh.com/monitoring-at-hellofresh-part-1-architecture-677b4bd6b728). 

projects/tikv/graduation-tikv.md

@@ -1,6 +1,6 @@
 **TiKV Graduation Proposal**
 
-TiKV is an open source distributed transactional key-value database. TiKV joined CNCF as a Sandbox project in [August 2018](https://www.cncf.io/blog/2018/08/28/cncf-to-host-tikv-in-the-sandbox/), and was voted by CNCF TOC as an incubation project in [May 2019](https://www.cncf.io/blog/2019/05/21/toc-votes-to-move-tikv-into-cncf-incubator/). The TiKV project has grown signifantly over time since joining CNCF, in terms both fostering a healthy ecosystem of maintainers and contributors and production adoptions.
+TiKV is an open source distributed transactional key-value database. TiKV joined CNCF as a Sandbox project in [August 2018](https://www.cncf.io/blog/2018/08/28/cncf-to-host-tikv-in-the-sandbox/), and was voted by CNCF TOC as an incubation project in [May 2019](https://www.cncf.io/blog/2019/05/21/toc-votes-to-move-tikv-into-cncf-incubator/). The TiKV project has grown significantly over time since joining CNCF, in terms both fostering a healthy ecosystem of maintainers and contributors and production adoptions.
 
 To highlight some of the achievements:
 
@@ -8,7 +8,7 @@ To highlight some of the achievements:
 - Contributors in the TiKV core repository: 239
 - Forks: 1100+
 - Releases: 86 releases
-- Adoptors: 1000+ (including commercial users and community users)
+- Adopters: 1000+ (including commercial users and community users)
 - 4.0 GA released in May, 2020
 
 On behalf of the maintainers team, we believe TiKV is ready for [graduation stage](https://github.com/cncf/toc/blob/master/process/graduation_criteria.md#graduation-stage).