Format markdown (#1156)

* Format markdown

Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)`

* revert bad diff

contributing/README.md

@@ -23,12 +23,13 @@ Other Documents
 - [Code of Conduct](./CODE-OF-CONDUCT.md) - all contributors must abide by the
   code of conduct
 - [Values](./VALUES.md) - shared goals and values for the community
-- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on becoming
+- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on
-  a contributor
+  becoming a contributor
 - [Working Groups](./WORKING-GROUPS.md) - describes our various working groups
-- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how working
+- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how
-  groups operate
+  working groups operate
-- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering committee
+- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering
+  committee
 - [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md) - describes our
   technical oversight committee
 - [Community Roles](./ROLES.md) - describes the roles individuals can assume

contributing/REPOSITORY-GUIDELINES.md

@@ -1,24 +1,26 @@
 # Knative Repository Guidelines
 
-This document outlines a structure for creating and associating code repositories
+This document outlines a structure for creating and associating code
-with the Knative project. It also describes how and when repositories are removed.
+repositories with the Knative project. It also describes how and when
+repositories are removed.
 
 ## Core Repositories
 
-Core repositories are considered core components of Knative. They are utilities, tools,
+Core repositories are considered core components of Knative. They are utilities,
-applications, or libraries that form or support the foundation of the project.
+tools, applications, or libraries that form or support the foundation of the
+project.
 
 Core repositories are all those located under the
 [github.com/knative organization](https://github.com/knative).
 
 ### Core Repository Requirements
 
-* Repository must live under github.com/knative/project-name
+- Repository must live under github.com/knative/project-name
-* Must adopt the Knative Code of Conduct
+- Must adopt the Knative Code of Conduct
-* All code projects must use the Apache License version 2.0.
+- All code projects must use the Apache License version 2.0.
-* Documentation repositories must use Creative Commons License version 4.0.
+- Documentation repositories must use Creative Commons License version 4.0.
-* All OWNERS must be members of the Knative community.
+- All OWNERS must be members of the Knative community.
-* Repository creation must be approved by the Technical Oversight Committee.
+- Repository creation must be approved by the Technical Oversight Committee.
 
 ## Removing Repositories
 
@@ -33,29 +35,35 @@ active, healthy, and aligned with the scope and mission of project.
 Core repositories may be removed from the project if they are deemed _inactive_.
 Inactive repositories are those that meet any of the following criteria:
 
-* There are no longer any active maintainers for the project, and no replacements can be found.
+- There are no longer any active maintainers for the project, and no
-* All PRs and issues have gone un-addressed for longer than six months.
+  replacements can be found.
-* There have been no new commits or other changes in more than a year.
+- All PRs and issues have gone un-addressed for longer than six months.
-* The contents have been folded into another actively maintained project.
+- There have been no new commits or other changes in more than a year.
+- The contents have been folded into another actively maintained project.
 
 ### Procedure for removal
 
-When a repository has been deemed eligible for removal, we take the following steps:
+When a repository has been deemed eligible for removal, we take the following
+steps:
 
-* A proposal to remove the repository is brought to the attention of the Technical Oversight Committee
+- A proposal to remove the repository is brought to the attention of the
-  through a GitHub issue posted in the [docs](https://github.com/knative/docs) repo.
+  Technical Oversight Committee through a GitHub issue posted in the
-  * Feedback is encouraged during a Technical Oversight Committee meeting before any action is taken.
+  [docs](https://github.com/knative/docs) repo.
-* Once the TOC has approved of the removal, if the repo is not moving to another actively maintained project:
+  - Feedback is encouraged during a Technical Oversight Committee meeting before
-  * The repo description is edited to start with the phrase "[EOL]"
+    any action is taken.
-  * All open issues and PRs are closed
+- Once the TOC has approved of the removal, if the repo is not moving to another
-  * All external collaborates are removed
+  actively maintained project:
-  * All webhooks, apps, integrations, or services are removed
+  - The repo description is edited to start with the phrase "[EOL]"
-  * GitHub pages are disabled
+  - All open issues and PRs are closed
-  * The repo is marked as archived using GitHub's archive feature
+  - All external collaborates are removed
-  * The removal is announced on the knative-dev mailing list
+  - All webhooks, apps, integrations, or services are removed
+  - GitHub pages are disabled
+  - The repo is marked as archived using GitHub's archive feature
+  - The removal is announced on the knative-dev mailing list
 
-This procedure maintains the complete record of issues, PRs, and other contributions. It leaves
+This procedure maintains the complete record of issues, PRs, and other
-the repository read-only and makes it clear that the repository is retired and no longer maintained.
+contributions. It leaves the repository read-only and makes it clear that the
+repository is retired and no longer maintained.
 
 ---
 

contributing/SLACK-GUIDELINES.md

@@ -27,15 +27,17 @@ project, and includes all communication mediums.
 
 ## Admins
 
-Members of the [Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and
+Members of the
-[Knative Steering Committee (KSC)](STEERING-COMMITTEE.md) are also the administrators for
+[Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and
-the Knative Slack instance.
+[Knative Steering Committee (KSC)](STEERING-COMMITTEE.md) are also the
+administrators for the Knative Slack instance.
 
 Slack admins should make sure to mention this in the “What I do” section of
 their Slack profile, as well as for which time zone.
 
 To connect: please reach out in the #slack-admins channel or DM (Direct Message)
-a member of the [KSC](STEERING-COMMITTEE.md) or [TOC](TECH-OVERSIGHT-COMMITTEE.md).
+a member of the [KSC](STEERING-COMMITTEE.md) or
+[TOC](TECH-OVERSIGHT-COMMITTEE.md).
 
 ### Admin Expectations and Guidelines
 

contributing/STEERING-COMMITTEE.md

@@ -24,23 +24,25 @@ the way we run this committee, based on feedback from the community.
 
 ## Charter
 
-1. Define, evolve, and promote the vision, values, mission, and scope of the project.
+1. Define, evolve, and promote the vision, values, mission, and scope of the
+   project.
 1. Define and evolve project governance structures and policies, including
-   project roles and how collaborators become members, approvers, leads,
+   project roles and how collaborators become members, approvers, leads, and/or
-   and/or administrators. This includes policy for the creation and
+   administrators. This includes policy for the creation and administration of
-   administration of [working groups](./WORKING-GROUPS.md) and committees.
+   [working groups](./WORKING-GROUPS.md) and committees.
-1. Steward, control access, delegate access, and establishes processes regarding,
+1. Steward, control access, delegate access, and establishes processes
-   all Knative project resources and has the final say in the disposition of
+   regarding, all Knative project resources and has the final say in the
-   those resources.
+   disposition of those resources.
 1. Manage the Knative brand and decide which things can be called "Knative" and
    how that mark can be used in relation to other efforts or vendors.
-1. Confirm/reject nominations to the KSC from organizations who are allocated seats.
+1. Confirm/reject nominations to the KSC from organizations who are allocated
+   seats.
 1. Confirm/reject nominations to the Technical Oversight Committee.
 1. Receive and handle reports about [code of conduct](./CODE-OF-CONDUCT.md)
    violations and maintain confidentiality.
-1. Receive security reports; work with the appropriate technical leads to
+1. Receive security reports; work with the appropriate technical leads to accept
-   accept or reject the report; maintain the private nature of such reports
+   or reject the report; maintain the private nature of such reports until
-   until disclosed to the broader community.
+   disclosed to the broader community.
 1. Act as the final escalation point and decider for any disputes, issues,
    clarifications, or escalations within the project scope.
 
@@ -49,7 +51,8 @@ the way we run this committee, based on feedback from the community.
 KSC may choose to delegate its authority to other committees as-needed. The
 committee currently recognizes this delegated authority for:
 
-- Technical guidance is delegated to the [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md).
+- Technical guidance is delegated to the
+  [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md).
 
 ## Committee Meetings
 
@@ -59,8 +62,8 @@ Given the private nature of many of these discussions (e.g. privacy, private
 emails to the committee, code of conduct violations, escalations, disputes
 between members, security reports, etc.) meetings are held in private.
 
-Meeting notes are available to members of the knative-dev mailing list
+Meeting notes are available to members of the knative-dev mailing list (link to
-(link to be added).
+be added).
 
 Questions and proposals for changes to governance are posted as issues in the
 [docs repo](https://github.com/knative/docs), and the KSC invites your feedback
@@ -71,14 +74,14 @@ there. See [Getting in touch](#getting-in-touch) for other options.
 Seats on the Steering Committee are held by an organization, not by the
 individual.
 
-The committee was created as the project was in its infancy, in order to
+The committee was created as the project was in its infancy, in order to tackle
-tackle governance and overall project strategy. Because of the nature of the
+governance and overall project strategy. Because of the nature of the project
-project and funding required, it was decided that strong corporate leadership
+and funding required, it was decided that strong corporate leadership was
-was necessary for the project to ensure velocity. As the project grows and
+necessary for the project to ensure velocity. As the project grows and matures
-matures the KSC will, from time to time, consider if this policy should be
+the KSC will, from time to time, consider if this policy should be changed.
-changed.
 
-The current membership of the committee is currently (listed alphabetically by first name):
+The current membership of the committee is currently (listed alphabetically by
+first name):
 
 |                                                     | Member         | Organization | Profile                                  |
 | -------------------------------------------------------- | -------------- | ------------ | ---------------------------------------- |
@@ -86,16 +89,16 @@ The current membership of the committee is currently (listed alphabetically by f
 | <img width="30px" src="https://github.com/mchmarny.png"> | Mark Chmarny   | Google       | [@mchmarny](https://github.com/mchmarny) |
 | <img width="30px" src="https://github.com/rgregg.png">   | Ryan Gregg     | Google       | [@rgregg](https://github.com/rgregg)     |
 | <img width="30px" src="https://github.com/isdal.png">    | Tomas Isdal    | Google       | [@isdal](https://github.com/isdal)       |
-|   | TBD | IBM      |        |
+|                                                          | TBD            | IBM          |                                          |
-|   | TBD | Pivotal  |        |
+|                                                          | TBD            | Pivotal      |                                          |
-|   | TBD | Red Hat  |        |
+|                                                          | TBD            | Red Hat      |                                          |
 
 There are currently three unfilled seats, as indicated by TBD.
 
 ### Allocation of seats
 
-Seats on the steering committee are allocated based upon contribution
+Seats on the steering committee are allocated based upon contribution to the
-to the project by an organization. No final decision has been made on the exact
+project by an organization. No final decision has been made on the exact
 formula.
 
 As the project continues to grow, we expect to add additional seats to the
@@ -132,8 +135,8 @@ pass with majority of the committee supporting it.
 
 Quorum is considered reached when at least half of the members are present.
 
-In case of extended absence, the organization of the absent member may appoint
+In case of extended absence, the organization of the absent member may appoint a
-a single delegate from the same company during the absence.
+single delegate from the same company during the absence.
 
 ## Changes to the charter
 
@@ -145,9 +148,10 @@ one week for comments and questions before a vote will occur.
 
 ## Getting in touch
 
-If you'd like to reach out to the committee, please drop a note
+If you'd like to reach out to the committee, please drop a note to
-to [knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com).
+[knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com).
-This is a private discussion list to which all members of the committee have access.
+This is a private discussion list to which all members of the committee have
+access.
 
 ---
 

contributing/WORKING-GROUP-PROCESSES.md

@@ -188,12 +188,12 @@ Leads from all affected working groups generally work together and come to an
 agreeable conclusion.
 
 In all cases, remaining blocking issues can be raised to the
-[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve the
+[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve
-situation. To trigger an escalation, create an issue in the project's
+the situation. To trigger an escalation, create an issue in the project's repo
-repo and assign it to the **@knative/tech-oversight-committee** team.
+and assign it to the **@knative/tech-oversight-committee** team.
 
-The Steering Committee, as a last resort, provides the final escalation path
+The Steering Committee, as a last resort, provides the final escalation path for
-for any repository or working group issue that cannot be resolved by the TOC.
+any repository or working group issue that cannot be resolved by the TOC.
 
 ---
 

contributing/WORKING-GROUPS.md

@@ -58,7 +58,7 @@ API
 | Community Meeting Calendar | Wednesdays 10:30a-11:00a PST <br>[Calendar](https://calendar.google.com/calendar/embed?src=google.com_18un4fuh6rokqf8hmfftm5oqq4%40group.calendar.google.com) |
 | Meeting Notes              | [Notes](https://docs.google.com/document/d/1NC4klOdNaU-N-PsKLyXBqDKgNSHtxCDep29Ta2b5FK0/edit)                                                                 |
 | Document Folder            | [Folder](https://drive.google.com/corp/drive/folders/1fpBW7VyiBISsKuVdgn1MrgFdtx_JGoC5)                                                                       |
-| Slack Channel              | [#serving-api](https://knative.slack.com/messages/serving-api)                                                                                                                |
+| Slack Channel              | [#serving-api](https://knative.slack.com/messages/serving-api)                                                                                                |
 
 | &nbsp;                                                   | Leads      | Company | Profile                                 |
 | -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |

docs/eventing/README.md

@@ -55,8 +55,8 @@ Addressable. You can create as many Triggers as necessary.
 
 ### Event channels and subscriptions
 
-Knative Eventing also defines an event forwarding and persistence layer,
+Knative Eventing also defines an event forwarding and persistence layer, called
-called a
+a
 [**Channel**](https://github.com/knative/eventing/blob/master/pkg/apis/eventing/v1alpha1/channel_types.go#L36).
 Messaging implementations may provide implementations of Channels via the
 [ClusterChannelProvisioner](https://github.com/knative/eventing/blob/master/pkg/apis/eventing/v1alpha1/cluster_channel_provisioner_types.go#L35)

docs/eventing/samples/gcp-pubsub-source/README.md

@@ -72,11 +72,13 @@ source is most useful as a bridge from other GCP services, such as
 
 ## Deployment
 
-1. Create the `default` Broker in your namespace. These instructions assume the namespace `default`, feel free to change to any other namespace you would like to use instead:
+1. Create the `default` Broker in your namespace. These instructions assume the
+   namespace `default`, feel free to change to any other namespace you would
+   like to use instead:
 
-  ```shell
+```shell
-  kubectl label namespace default knative-eventing-injection=enabled
+kubectl label namespace default knative-eventing-injection=enabled
-  ```
+```
 
 1. Create a GCP PubSub Topic. If you change its name (`testing`), you also need
    to update the `topic` in the
@@ -105,7 +107,8 @@ source is most useful as a bridge from other GCP services, such as
    kubectl apply --filename gcp-pubsub-source.yaml
    ```
 
-1. Create a function and create a Trigger that will send all events from the Broker to the function:
+1. Create a function and create a Trigger that will send all events from the
+   Broker to the function:
 
    ```shell
    kubectl apply --filename trigger.yaml

docs/eventing/samples/iot-core/README.md

@@ -89,9 +89,9 @@ export IOTCORE_TOPIC_DEVICE="iot-demo-device-pubsub-topic"
 
 1. Install the default `Broker`.
 
-    ```shell
+   ```shell
-    kubectl label namespace default knative-eventing-injection=enabled
+   kubectl label namespace default knative-eventing-injection=enabled
-    ```
+   ```
 
 #### GCP PubSub Source
 
@@ -106,8 +106,8 @@ export IOTCORE_TOPIC_DEVICE="iot-demo-device-pubsub-topic"
 
 #### Trigger
 
-Even though the `Source` isn't completely ready yet, we can setup the
+Even though the `Source` isn't completely ready yet, we can setup the `Trigger`
-`Trigger` for all events coming out of it.
+for all events coming out of it.
 
 1.  Deploy `trigger.yaml`.
 
@@ -173,16 +173,17 @@ see them in the subscriber.
         -events 10
     ```
 
-1. Inspect the logs of the subscriber:
+1.  Inspect the logs of the subscriber:
 
     ```shell
     kubectl logs --selector serving.knative.dev/service=event-display -c user-container
     ```
 
     You should see something along the similar to:
-    
+
     ```shell
     {"ID":"481014114648052","Data":"eyJzb3VyY2VfaWQiOiJpb3QtY29yZSBkZW1vIiwiZXZlbnRfaWQiOiJlaWQtMzI3MjJiMzItZWU5Mi00YzZlLWEzOTgtNDlmYjRkYWYyNGE1IiwiZXZlbnRfdHMiOjE1NTM3MTczOTYsIm1ldHJpYyI6MC4xMzY1MjI5OH0=","Attributes":{"deviceId":"iot-demo-client","deviceNumId":"2754785852315736","deviceRegistryId":"iot-demo","deviceRegistryLocation":"us-central1","projectId":"s9-demo","subFolder":""},"PublishTime":"2019-03-27T20:09:56.685Z"}
+    ```
 
 ### Cleanup
 
@@ -196,7 +197,7 @@ To cleanup the knative resources:
         docs/eventing/samples/iot-core/gcp-pubsub-source.yaml |
     kubectl delete --filename -
     ```
-    
+
 1.  Remove the Trigger:
 
     ```shell
@@ -208,4 +209,3 @@ To cleanup the knative resources:
     ```shell
     kubectl delete --filename https://github.com/knative/eventing-sources/releases/download/v0.5.0/gcppubsub.yaml
     ```
-

docs/eventing/samples/kubernetes-event-source/README.md

@@ -10,7 +10,10 @@ consumption by a function that has been implemented as a Knative Service.
 
 ### Broker
 
-1. Create the `default` Broker in your namespace. These instructions assume the namespace `default`, feel free to change to any other namespace you would like to use instead. If you use a different namespace, you will need to modify all the YAML files deployed in this sample to point at that namespace.
+1. Create the `default` Broker in your namespace. These instructions assume the
+   namespace `default`, feel free to change to any other namespace you would
+   like to use instead. If you use a different namespace, you will need to
+   modify all the YAML files deployed in this sample to point at that namespace.
 
 ```shell
 kubectl label namespace default knative-eventing-injection=enabled
@@ -31,9 +34,9 @@ kubectl apply --filename serviceaccount.yaml
 ### Create Event Source for Kubernetes Events
 
 1. In order to receive events, you have to create a concrete Event Source for a
-   specific namespace. If you want to consume events from a different
+   specific namespace. If you want to consume events from a different namespace
-   namespace or use a different `Service Account`, you need to modify
+   or use a different `Service Account`, you need to modify `k8s-events.yaml`
-   `k8s-events.yaml` accordingly.
+   accordingly.
 
 ```shell
 kubectl apply --filename k8s-events.yaml
@@ -46,7 +49,8 @@ simple Knative Service that dumps incoming messages to its log and creates a
 `Trigger` from the `Broker` to that Knative Service.
 
 1. If the deployed `KubernetesEventSource` is pointing at a `Broker` other than
-   `default`, modify `trigger.yaml` by adding `spec.broker` with the `Broker`'s name.
+   `default`, modify `trigger.yaml` by adding `spec.broker` with the `Broker`'s
+   name.
 
 1. Deploy `trigger.yaml`.
 
@@ -68,8 +72,8 @@ kubectl delete pod busybox
 
 We will verify that the Kubernetes events were sent into the Knative eventing
 system by looking at our message dumper function logs. If you deployed the
-[Trigger](#trigger), then continue using this section. If not, then you
+[Trigger](#trigger), then continue using this section. If not, then you will
-will need to look downstream yourself.
+need to look downstream yourself.
 
 ```shell
 kubectl get pods
@@ -87,8 +91,7 @@ Ce-Source: /apis/v1/namespaces/default/pods/busybox
 
 ### Cleanup
 
-You can remove the `Service Account`, `Event Sources`, and
+You can remove the `Service Account`, `Event Sources`, and `Trigger` via:
-`Trigger` via:
 
 ```shell
 kubectl --namespace default delete --filename serviceaccount.yaml