fixes in docs (#1851)

Co-authored-by: Geoff Romer <gromer@google.com>
This commit is contained in:
Krishna Agarwal
2022-08-03 11:33:13 -07:00
committed by GitHub
co-authored by Geoff Romer
parent 79df59b1dd
commit 09e62752a0
+13 -13
View File
@@ -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.