diff --git a/contributing/README.md b/contributing/README.md index ea52e90ff..54204d1ed 100644 --- a/contributing/README.md +++ b/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 - 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 diff --git a/contributing/REPOSITORY-GUIDELINES.md b/contributing/REPOSITORY-GUIDELINES.md index 6f099699d..42c7db3b5 100644 --- a/contributing/REPOSITORY-GUIDELINES.md +++ b/contributing/REPOSITORY-GUIDELINES.md @@ -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. --- diff --git a/contributing/SLACK-GUIDELINES.md b/contributing/SLACK-GUIDELINES.md index a141a18c5..8c745705b 100644 --- a/contributing/SLACK-GUIDELINES.md +++ b/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 -[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 diff --git a/contributing/STEERING-COMMITTEE.md b/contributing/STEERING-COMMITTEE.md index c68d34e5c..acebd5649 100644 --- a/contributing/STEERING-COMMITTEE.md +++ b/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, - 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 | | -------------------------------------------------------- | -------------- | ------------ | ---------------------------------------- | @@ -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 | Pivotal | | -| | TBD | Red Hat | | +| | TBD | IBM | | +| | TBD | Pivotal | | +| | 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 -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. --- diff --git a/contributing/WORKING-GROUP-PROCESSES.md b/contributing/WORKING-GROUP-PROCESSES.md index be67f23bb..9e3e57ab9 100644 --- a/contributing/WORKING-GROUP-PROCESSES.md +++ b/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 -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. --- diff --git a/contributing/WORKING-GROUPS.md b/contributing/WORKING-GROUPS.md index 8cf497350..d18ddafff 100644 --- a/contributing/WORKING-GROUPS.md +++ b/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) | | | Leads | Company | Profile | | -------------------------------------------------------- | ---------- | ------- | --------------------------------------- | diff --git a/docs/eventing/README.md b/docs/eventing/README.md index 51aca3a0e..e320804d6 100644 --- a/docs/eventing/README.md +++ b/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, -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) diff --git a/docs/eventing/samples/gcp-pubsub-source/README.md b/docs/eventing/samples/gcp-pubsub-source/README.md index 478dedb9a..0cd671b04 100644 --- a/docs/eventing/samples/gcp-pubsub-source/README.md +++ b/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 - kubectl label namespace default knative-eventing-injection=enabled - ``` +```shell +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 diff --git a/docs/eventing/samples/iot-core/README.md b/docs/eventing/samples/iot-core/README.md index 041e89c09..155773e03 100644 --- a/docs/eventing/samples/iot-core/README.md +++ b/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 - kubectl label namespace default knative-eventing-injection=enabled - ``` + ```shell + 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 -`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`. @@ -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 ``` - diff --git a/docs/eventing/samples/kubernetes-event-source/README.md b/docs/eventing/samples/kubernetes-event-source/README.md index 1d7d5cc34..6c1070081 100644 --- a/docs/eventing/samples/kubernetes-event-source/README.md +++ b/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 - 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