From 09e62752a04375a6caedf58c45283c62cd9faf49 Mon Sep 17 00:00:00 2001 From: Krishna Agarwal Date: Thu, 4 Aug 2022 00:03:13 +0530 Subject: [PATCH] fixes in docs (#1851) Co-authored-by: Geoff Romer --- docs/project/goals.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/project/goals.md b/docs/project/goals.md index 2fdb099b0db0..d5759fbf7329 100644 --- a/docs/project/goals.md +++ b/docs/project/goals.md @@ -80,7 +80,7 @@ set expectations for people joining, and to help remind and anchor us on consistent standards. It is also important that we hold ourselves accountable to these expectations and have real and meaningful mechanisms to moderate the community. When behavior steps outside of our expectations, we need tools, -process, and policy for how we will recognize and correct it. +processes, and policies for how we will recognize and correct it. **An open, inclusive process for Carbon changes.** The community needs to be able to effectively engage in the direction and evolution of the project and @@ -140,12 +140,12 @@ we expect to provide tooling to help automate and scale migrating existing Carbon code to the new version. The goal is to enable more rapid evolution of the language without the churn tax and version skew becoming unsustainable. -**Developer tooling.** We need developers to be productive reading and writing -Carbon code. We expect to provide a broad suite of development oriented tools -ranging from refactoring tools to [LSP](https://langserver.org/) implementations -and editor integrations. We also plan to provide machine readable forms of many -parts of the language, such as a grammar, to ensure consistency between tools -and enable the development of tools by others. +**Developer tooling.** We need developers to be productive while reading and +writing Carbon code. We expect to provide a broad suite of development oriented +tools ranging from refactoring tools to [LSP](https://langserver.org/) +implementations and editor integrations. We also plan to provide machine +readable forms of many parts of the language, such as a grammar, to ensure +consistency between tools and enable the development of tools by others. **Infrastructure to enable package management and other library ecosystem support.** The goal is to support what the ecosystem needs, regardless of the @@ -596,15 +596,15 @@ cost-benefit analysis. **Cost-benefit will drive many choices.** We expect to measure both cost, including complexity, and benefit using the impact on the project and language as a whole. Benefit accumulates over time, which means providing incremental -solutions earlier will typically increase total benefit. It is also reasonable -for the rationale of a decision to factor in both effort already invested, and -effort ready to commit to the feature. This should not overwhelm any fundamental -cost-benefit analysis. However, given two equally impactful features, we should -focus on the solution that is moving the fastest. +solutions earlier will typically increase the total benefit. It is also +reasonable for the rationale of a decision to factor in both effort already +invested, and effort ready to commit to the feature. This should not overwhelm +any fundamental cost-benefit analysis. However, given two equally impactful +features, we should focus on the solution that is moving the fastest. **Domain-motivated libraries and features are an example.** For these, the cost function will typically be the effort required to specify and implement the -feature. Benefit will stem from the number of users and how much utility the +feature. The benefit will stem from the number of users and how much utility the feature provides. We don't expect to have concrete numbers for these, but we expect prioritization decisions between features to be expressed using this framework.