Apply suggestions from code review

Co-Authored-By: Daniel Helfand <[email protected]>
Co-Authored-By: Napoleon Santana <[email protected]>

teps/0001-tekton-enhancement-proposal-process.md

@@ -51,7 +51,7 @@ A standardized development process for Tekton is proposed in order to
   adequately represented throughout the process
 
 This process is supported by a unit of work called a Tekton
-Enhancement Proposal or TEP.  A TEP attempts to combine aspects of a
+Enhancement Proposal (TEP). A TEP attempts to combine aspects of the following:
 
 - feature, and effort tracking document
 - a product requirements document
@@ -63,37 +63,37 @@ or more Working Groups (WGs).
 ## Motivation
 
 For cross project or new project proposal, an abstraction beyond a
-single GitHub Issue semms to be required, in order to understand and
-communicate upcoming changes to Tekton.
+single GitHub issue seems to be required in order to understand and
+communicate upcoming changes to the Tekton community.
 
 In a blog post describing the [road to Go 2][], Russ Cox explains
 
 > that it is difficult but essential to describe the significance of a
 > problem in a way that someone working in a different environment can
 > understand
 
-As a project it is vital to be able to track the chain of custody for
+As a project, it is vital to be able to track the chain of custody for
 a proposed enhancement from conception through implementation.
 
-Without a standardized mechanism for describing important enhancements
+Without a standardized mechanism for describing important enhancements,
 our talented technical writers and product managers struggle to weave
 a coherent narrative explaining why a particular release is
-important. Additionally for critical infrastructure such as Tekton
+important. Additionally, for critical infrastructure such as Tekton,
 adopters need a forward looking road map in order to plan their
 adoption strategy.
 
-Before this proposal, there is not definite standard way and template
-to create project enhancement or creation. We rely on different
-document hosted on Google docs, with not standard template explaining
-why the change. Once a proposal is done, via a design docs, it tends
-to be hard to follow what happens to it : updates on the proposal in
+Before this proposal, there is not a standard way or template
+to create project enhancements. We rely on
+documents hosted on Google docs, without a standard template explaining
+the change. Once a proposal is done, via a design docs, it tends
+to be hard to follow what happens with the proposal: updates on the proposal in
 reaction to comments, state of the proposal (when is it accepted, or
 rejected).
 
 The purpose of the TEP process is to reduce the amount of "tribal
 knowledge" in our community. By moving decisions from a smattering of
 mailing lists, video calls and hallway conversations into a well
-tracked artifact this process aims to enhance communication and
+tracked artifact, this process aims to enhance communication and
 discoverability.
 
 A TEP is broken into sections which can be merged into source control
@@ -103,10 +103,11 @@ submitting the content contained in [design proposals][] is both clear
 and efficient. The TEP process is intended to create high quality
 uniform design and implementation documents for WGs to deliberate.
 
-[road to Go 2]: https://blog.golang.org/toward-go2 [design proposals]: https://github.com/kubernetes/community/tree/master/contributors/design-proposals
+[road to Go 2]: https://blog.golang.org/toward-go2) 
+[design proposals]: https://github.com/kubernetes/community/tree/master/contributors/design-proposals
 
 ## Stewardship
-The following DACI model indentifies the responsible parties for TEPs.
+The following DACI model indentifies the responsible parties for TEPs:
 
 **Workstream** | **Driver** | **Approver** | **Contributor** |
 **Informed** --- | --- | --- | --- | ---
@@ -121,9 +122,9 @@ The following DACI model indentifies the responsible parties for TEPs.
 
 The definition of what constitutes an "enhancement" is a foundational
 concern for the Tekton project. Roughly any Tekton user or
-operator facing enhancement should follow the TEP process: if an
+operator facing enhancement should follow the TEP process. If an
 enhancement would be described in either written or verbal
-communication to anyone besides the TEP author or developer then
+communication to anyone besides the TEP author or developer, then
 consider creating a TEP.
 
 Similarly, any technical effort (refactoring, major architectural
@@ -133,51 +134,51 @@ even if it will have zero impact on the typical user or operator.
 
 As the local bodies of governance, WGs should have broad latitude in
 describing what constitutes an enhancement which should be tracked
-through the TEP process.  WGs may find that helpful to enumerate what
+through the TEP process. WGs may find it helpful to enumerate what
 _does not_ require a TEP rather than what does. WGs also have the
 freedom to customize the TEP template according to their WG specific
-concerns. For example the TEP template used to track API changes will
+concerns. For example, the TEP template used to track API changes will
 likely have different subsections than the template for proposing
 governance changes. However, as changes start impacting other WGs or
-the larger developer community outside of a WG, the TEP process
+the larger developer communities outside of a WG, the TEP process
 should be used to coordinate and communicate.
 
 Enhancements that have major impacts on multiple WGs should use the
-TEP process.  A single WG will own the TEP but it is expected that
-the set of approvers will span the impacted WGs.  The SEP process is
+TEP process. A single WG will own the TEP but it is expected that
+the set of approvers will span the impacted WGs. The SEP process is
 the way that WGs can negotiate and communicate changes that cross
 boundaries.
 
 TEPs will also be used to drive large changes that will cut across all
-parts of the project.  These TEPs will be owned by SIG-architecture
+parts of the project. These TEPs will be owned by SIG-architecture
 and should be seen as a way to communicate the most fundamental
-aspects of what Kubernetes is.
+aspects of what Tekton is.
 
 ### TEP Template
 
 The template for a TEP is precisely defined
-[here](YYYYMMDD-tep-template.md**
+[here](YYYYMMDD-tep-template.md)
 
 **TO-DO***
 
 ### TEP Metadata
 
 There is a place in each TEP for a YAML document that has standard
-metadata.  This will be used to support tooling around filtering and
-display.  It is also critical to clearly communicate the status of a
+metadata. This will be used to support tooling around filtering and
+display. It is also critical to clearly communicate the status of a
 TEP.
 
 Metadata items:
 * **title** Required
-  * The title of the TEP in plain language.  The title will also be
-    used in the TEP filename.  See the template for instructions and
+  * The title of the TEP in plain language. The title will also be
+    used in the TEP filename. See the template for instructions and
     details.
 * **status** Required
   * The current state of the TEP.
   * Must be one of `provisional`, `implementable`, `implemented`,
     `deferred`, `rejected`, `withdrawn`, or `replaced`.
 * **authors** Required
-  * A list of authors for the TEP.  This is simply the github ID.  In
+  * A list of authors for the TEP. This is simply the github ID. In
     the future we may enhance this to include other types of
     identification.
 * **reviewers** Required
@@ -209,7 +210,7 @@ Metadata items:
   * A list of other TEPs that are relevant to this TEP.
   * In the form `TEP-123`
 * **replaces** Optional
-  * A list of TEPs that this TEP replaces.  Those TEPs should list
+  * A list of TEPs that this TEP replaces. Those TEPs should list
     this TEP in their `superseded-by`.
   * In the form `TEP-123`
 * **superseded-by**
@@ -223,18 +224,18 @@ Metadata items:
 A TEP has the following states
 
 - `provisional`: The TEP has been proposed and is actively being
-  defined.  This is the starting state while the TEP is being fleshed
+  defined. This is the starting state while the TEP is being fleshed
   out and actively defined and discussed.
 - `implementable`: The approvers have approved this TEP for
   implementation.
 - `implemented`: The TEP has been implemented and is no longer
   actively changed.
 - `deferred`: The TEP is proposed but not actively being worked on.
 - `rejected`: The approvers and authors have decided that this TEP is
-  not moving forward.  The TEP is kept around as a historical
+  not moving forward. The TEP is kept around as a historical
   document.
 - `withdrawn`: The TEP has been withdrawn by the authors.
-- `replaced`: The TEP has been replaced by a new TEP.  The
+- `replaced`: The TEP has been replaced by a new TEP. The
   `superseded-by` metadata value should point to the new TEP.
 
 ### Git and GitHub Implementation
@@ -243,16 +244,16 @@ TEPs are checked into the community repo under the `/teps`
 directory.
 
 New TEPs can be checked in with a file name in the form of
-`draft-YYYYMMDD-my-title.md`.  As significant work is done on the TEP
-the authors can assign a TEP number.  No other changes should be put
+`draft-YYYYMMDD-my-title.md`. As significant work is done on the TEP,
+the authors can assign a TEP number. No other changes should be put
 in that PR so that it can be approved quickly and minimize merge
-conflicts.  The TEP number can also be done as part of the initial
+conflicts. The TEP number can also be done as part of the initial
 submission if the PR is likely to be uncontested and merged quickly.
 
 ### TEP Editor Role
 
 Taking a cue from the [Python PEP process][], we define the role of a
-TEP editor.  The job of an TEP editor is likely very similar to the
+TEP editor. The job of an TEP editor is likely very similar to the
 [TEP editor responsibilities][] and will hopefully provide another
 opportunity for people who do not write code daily to contribute to
 Tekton.
@@ -267,7 +268,7 @@ In keeping with the TEP editors which
 > 7).
 
 TEP editors should generally not pass judgement on a TEP beyond
-editorial corrections.  TEP editors can also help inform authors about
+editorial corrections. TEP editors can also help inform authors about
 the process and otherwise help things move smoothly.
 
 [Python PEP process]: https://www.python.org/dev/peps/pep-0001/ [PEP editor responsibilities]: https://www.python.org/dev/peps/pep-0001/#pep-editor-responsibilities-workflow
@@ -309,9 +310,9 @@ velocity.
 
 It certainly can be argued that the lack of a dedicated issue/defect
 tracker beyond GitHub issues contributes to our challenges in managing
-a project as large as Kubernetes, however, given that other large
+a project as large as Tekton, however, given that other large
 organizations, including GitHub itself, make effective use of GitHub
-issues perhaps the argument is overblown.
+issues, perhaps the argument is overblown.
 
 The centrality of Git and GitHub within the TEP process also may place
 too high a barrier to potential contributors, however, given that both
@@ -331,7 +332,7 @@ This TEP process is related to
 - the difference between an accepted design and a proposal
 - the organization of design proposals
 
-this proposal attempts to place these concerns within a general
+This proposal attempts to place these concerns within a general
 framework.
 
 ### GitHub issues vs. TEPs