removed 'we'

Author: fhennig

modules/contributor/pages/code-style-guide.adoc

@@ -425,20 +425,20 @@ enum Error {
 ==== Examples for "failed to ..." error messages
 
 . `failed to parse config file` to indicate the parsing of the config file failed, usually because the file doesn't conform to the configuration language.
-. `failed to construct http client` to indicate we wanted to construct a HTTP client to retrieve remote content.
+. `failed to construct http client` to indicate that the construction of a HTTP client to retrieve remote content failed.
 
 ==== Exampled for "unable to ..." error messages
 
-. `unable to read config file from ...` to indicate we could load the file (for example because the file doesn't exist).
-. `unable to parse value ...` to indicate we failed to parse a user provided value which didn't conform to the expected syntax.
+. `unable to read config file from ...` to indicate that the file could not be loaded (for example because the file doesn't exist).
+. `unable to parse value ...` to indicate that parsing a user provided value failed (for example because it  didn't conform to the expected syntax).
 
 == String formatting
 
 === Named versus unnamed format string identifiers
 
-For simple string formatting (up to two substitutions), we allow unnamed (and thus also uncaptured) identifiers.
+For simple string formatting (up to two substitutions), unnamed (and thus also uncaptured) identifiers are allowed.
 
-For more complex formatting (more than two substitutions), we require named identifiers to avoid ambiguity, and to decouple argument order from the text (which can lead to incorrect text when the wording is changed and `{}` are reordered while the arguments aren't).
+For more complex formatting (more than two substitutions), named identifiers are required to avoid ambiguity, and to decouple argument order from the text (which can lead to incorrect text when the wording is changed and `{}` are reordered while the arguments aren't).
 This rule needs to strike a balance between explicitness and concise `format!()` invocations.
 Long `format!()` expressions can lead to rustfmt breakage.
 It might be better to split up long formatting strings into multiple smaller ones.
@@ -488,7 +488,7 @@ format!(
 
 === Captured versus uncaptured format string identifiers
 
-We place no restriction on named format string identifiers.
+There are no restrictions on named format string identifiers.
 All options below are considered valid.
 
 [source,rust]
@@ -504,7 +504,7 @@ format!("Hello {name}, hello again {name}", name = greetee);
 
 == Specifying resources measured in bytes and CPU fractions
 
-We follow the Kubernetes convention described https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/[here].
+Follow the Kubernetes convention described https://kubernetes.io/docs/reference/kubernetes-api/common-definitions/quantity/[here].
 
 === Resources measured in bytes