knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Format markdown (#1156) 

* Format markdown

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

* revert bad diff
This commit is contained in:
mattmoor-sockpuppet 2019-04-10 07:01:00 -07:00 committed by Knative Prow Robot
parent f62c8d0a67
commit 541df1a173
10 changed files with 120 additions and 99 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
contributing/README.md
View File

@ -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
a contributor
- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on
becoming a contributor
- [Working Groups](./WORKING-GROUPS.md) - describes our various working groups
- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how working
groups operate
- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering committee
- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how
working groups operate
- [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

64
contributing/REPOSITORY-GUIDELINES.md
View File

@ -1,24 +1,26 @@
# Knative Repository Guidelines
This document outlines a structure for creating and associating code repositories
with the Knative project. It also describes how and when repositories are removed.
This document outlines a structure for creating and associating code
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,
applications, or libraries that form or support the foundation of the project.
Core repositories are considered core components of Knative. They are utilities,
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
* Must adopt the Knative Code of Conduct
* All code projects must use the Apache License version 2.0.
* Documentation repositories must use Creative Commons License version 4.0.
* All OWNERS must be members of the Knative community.
* Repository creation must be approved by the Technical Oversight Committee.
- Repository must live under github.com/knative/project-name
- Must adopt the Knative Code of Conduct
- All code projects must use the Apache License version 2.0.
- Documentation repositories must use Creative Commons License version 4.0.
- All OWNERS must be members of the Knative community.
- 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.
* All PRs and issues have gone un-addressed for longer than six months.
* There have been no new commits or other changes in more than a year.
* The contents have been folded into another actively maintained project.
- There are no longer any active maintainers for the project, and no
replacements can be found.
- All PRs and issues have gone un-addressed for longer than six months.
- 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
through a GitHub issue posted in the [docs](https://github.com/knative/docs) repo.
* Feedback is encouraged during a Technical Oversight Committee meeting before any action is taken.
* Once the TOC has approved of the removal, if the repo is not moving to another actively maintained project:
* The repo description is edited to start with the phrase "[EOL]"
* All open issues and PRs are closed
* All external collaborates are removed
* 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
- A proposal to remove the repository is brought to the attention of the
Technical Oversight Committee through a GitHub issue posted in the
[docs](https://github.com/knative/docs) repo.
- Feedback is encouraged during a Technical Oversight Committee meeting before
any action is taken.
- Once the TOC has approved of the removal, if the repo is not moving to another
actively maintained project:
- The repo description is edited to start with the phrase "[EOL]"
- All open issues and PRs are closed
- All external collaborates are removed
- 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
the repository read-only and makes it clear that the repository is retired and no longer maintained.
This procedure maintains the complete record of issues, PRs, and other
contributions. It leaves the repository read-only and makes it clear that the
repository is retired and no longer maintained.
---

10
contributing/SLACK-GUIDELINES.md
View File

@ -27,15 +27,17 @@ project, and includes all communication mediums.
## Admins
Members of the [Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and
[Knative Steering Committee (KSC)](STEERING-COMMITTEE.md) are also the administrators for
the Knative Slack instance.
Members of the
[Technical Oversight Committee (TOC)](TECH-OVERSIGHT-COMMITTEE.md) and
[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

60
contributing/STEERING-COMMITTEE.md
View File

@ -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,
and/or administrators. This includes policy for the creation and
administration of [working groups](./WORKING-GROUPS.md) and committees.
1. Steward, control access, delegate access, and establishes processes regarding,
all Knative project resources and has the final say in the disposition of
those resources.
project roles and how collaborators become members, approvers, leads, and/or
administrators. This includes policy for the creation and administration of
[working groups](./WORKING-GROUPS.md) and committees.
1. Steward, control access, delegate access, and establishes processes
regarding, all Knative project resources and has the final say in the
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
accept or reject the report; maintain the private nature of such reports
until disclosed to the broader community.
1. Receive security reports; work with the appropriate technical leads to accept
or reject the report; maintain the private nature of such reports until
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
(link to be added).
Meeting notes are available to members of the knative-dev mailing list (link to
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
tackle governance and overall project strategy. Because of the nature of the
project and funding required, it was decided that strong corporate leadership
was necessary for the project to ensure velocity. As the project grows and
matures the KSC will, from time to time, consider if this policy should be
changed.
The committee was created as the project was in its infancy, in order to tackle
governance and overall project strategy. Because of the nature of the project
and funding required, it was decided that strong corporate leadership was
necessary for the project to ensure velocity. As the project grows and matures
the KSC will, from time to time, consider if this policy should be 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 |
| -------------------------------------------------------- | -------------- | ------------ | ---------------------------------------- |
@ -94,8 +97,8 @@ There are currently three unfilled seats, as indicated by TBD.
### Allocation of seats
Seats on the steering committee are allocated based upon contribution
to the project by an organization. No final decision has been made on the exact
Seats on the steering committee are allocated based upon contribution to the
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
a single delegate from the same company during the absence.
In case of extended absence, the organization of the absent member may appoint a
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
to [knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com).
This is a private discussion list to which all members of the committee have access.
If you'd like to reach out to the committee, please drop a note to
[knative-steering@googlegroups.com](mailto:knative-steering@googlegroups.com).
This is a private discussion list to which all members of the committee have
access.
---

10
contributing/WORKING-GROUP-PROCESSES.md
View File

@ -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
situation. To trigger an escalation, create an issue in the project's
repo and assign it to the **@knative/tech-oversight-committee** team.
[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve
the situation. To trigger an escalation, create an issue in the project's repo
and assign it to the **@knative/tech-oversight-committee** team.
The Steering Committee, as a last resort, provides the final escalation path
for any repository or working group issue that cannot be resolved by the TOC.
The Steering Committee, as a last resort, provides the final escalation path for
any repository or working group issue that cannot be resolved by the TOC.
---

4
docs/eventing/README.md
View File

@ -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,
called a
Knative Eventing also defines an event forwarding and persistence layer, called
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)

7
docs/eventing/samples/gcp-pubsub-source/README.md
View File

@ -72,7 +72,9 @@ 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
kubectl label namespace default knative-eventing-injection=enabled
@ -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

6
docs/eventing/samples/iot-core/README.md
View File

@ -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
`Trigger` for all events coming out of it.
Even though the `Source` isn't completely ready yet, we can setup the `Trigger`
for all events coming out of it.
1. Deploy `trigger.yaml`.
@ -183,6 +183,7 @@ see them in the subscriber.
```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
@ -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
```

21
docs/eventing/samples/kubernetes-event-source/README.md
View File

@ -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
namespace or use a different `Service Account`, you need to modify
`k8s-events.yaml` accordingly.
specific namespace. If you want to consume events from a different namespace
or use a different `Service Account`, you need to modify `k8s-events.yaml`
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
will need to look downstream yourself.
[Trigger](#trigger), then continue using this section. If not, then you will
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
`Trigger` via:
You can remove the `Service Account`, `Event Sources`, and `Trigger` via:
```shell
kubectl --namespace default delete --filename serviceaccount.yaml