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

rename sandbox to extensions (#1419) 

* renqme sandbox to extensions

* typo
This commit is contained in:
David Hadas 2023-08-16 23:30:41 +03:00 committed by GitHub
parent 65f8f39796
commit 9360770db1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
14 changed files with 24 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
.github/ISSUE_TEMPLATE/new-repo.md vendored
View File

@ -23,7 +23,7 @@ Sponsoring WG:
## Actions to fulfill
This area is used to track the [repo creation process](https://github.com/knative/community/blob/main/mechanics/CREATING-A-SANDBOX-REPO.md).
This area is used to track the [repo creation process](https://github.com/knative/community/blob/main/mechanics/CREATING-AN-EXTENSIONS-REPO.md).
The _requestor_ and _sponsoring WG lead_ should perform the steps listed below and cross out the checkmarks when done.
The TOC is involved only in the **TOC Gate** steps.
@ -59,7 +59,7 @@ _You may not be able to use the Projects quick menu on this page. In that case,
- [ ] [Set up](https://github.com/knative/test-infra/blob/main/guides/prow_knative_setup.md#setting-up-prow-for-a-new-repo-reviewers-assignment-and-auto-merge) prow for a new repo
- [ ] Bootstrap your CI jobs using [hack](https://github.com/knative/hack) project (look at other sandbox repos for reference)
- [ ] Bootstrap your CI jobs using [hack](https://github.com/knative/hack) project (look at other extensions repos for reference)
- [ ] Create a sample PR to verify Prow (e.g., edit the boilerplate README)

4
REPOSITORY-GUIDELINES.md
View File

@ -103,11 +103,11 @@ contributions which may be important to the project but which do not need the
level of governance of the core project.
Note that `knative-extensions` is **not** an incubation area for projects entering
the `knative` github org; in most cases, projects in the sandbox will remain
the `knative` github org; in most cases, projects in the extensions will remain
there for the entire duration. `knative-extensions` also provides a location for
implementations of core interfaces which do not themselves need to be part of
every knative installation, such as networking or eventing integrations. In the
event that a working group wants a project in sandbox to be considered for
event that a working group wants a project in extensions to be considered for
transfer to the `knative` org, the request will be considered on a case-by-case
basis by joint decision of the Steering Committee and the Technical Oversight
Committee.

2
STEERING-COMMITTEE.md
View File

@ -47,7 +47,7 @@ evolve as the community and project change.
promoting the community. This advice is non-binding on the Trademark
Committee.
1. Define and evolve the scope of the Knative community and extensions, and the
process for migration of sandbox projects into Knative Extensions.
process for migration of extensions projects into Knative Extensions.
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

2
elections/2021-SC/candidate-lball.md
View File

@ -5,7 +5,7 @@ info:
- affiliation: Red Hat
-------------------------------------------------------------
In my role as technical architect of the Boson Project - a project that brings a function-focused developer experience to Knative - I have been involved on the periphery of Knative since 2019. In the fall of 2021, the core of Boson Project's work was donated to Knative and now exists as a part of Knative Sandbox. I am the Function Task Force lead for this project, and guide the technical efforts towards achieving Functions as a first class citizen of Knative. To Knative core, I have over 200+ contributions primarily in documentation, samples and infrastructure. Outside of the Knative ecosystem, I have been active in the open source community for over a decade as a regular contributor to Node.js core and other widely used technologies.
In my role as technical architect of the Boson Project - a project that brings a function-focused developer experience to Knative - I have been involved on the periphery of Knative since 2019. In the fall of 2021, the core of Boson Project's work was donated to Knative and now exists as a part of Knative extensions. I am the Function Task Force lead for this project, and guide the technical efforts towards achieving Functions as a first class citizen of Knative. To Knative core, I have over 200+ contributions primarily in documentation, samples and infrastructure. Outside of the Knative ecosystem, I have been active in the open source community for over a decade as a regular contributor to Node.js core and other widely used technologies.
I believe that Knative has come a long way in the last two years, to become a solid platform for serverless, event driven applications. While continuing to evolve and improve the core Serving and Eventing components of Kative, I believe now is the time for a new focus on the developer experience. Kative is nothing if developers aren't writing applications that can run on it, and with Functions, I would like to make that as frictionless as possible. I believe developer UX is a crucial component for the Steering Committee's focus over the coming years, and know that I can bring a unique perspective to that effort.

2
elections/2021-TOC/candidate-evankanderson.md
View File

@ -5,6 +5,6 @@ info:
- affiliation: VMware
-------------------------------------------------------------
I've been a member of the Knative community since its inception, working on both the Serving and Eventing components. I worked on the initial serving spec and requirements for non-Istio ingresses and on the initial eventing documentation. Since then, I've worked on most areas of the project, including docs and the website, the operator, knative-sandbox, governance, automation, and working group organization.
I've been a member of the Knative community since its inception, working on both the Serving and Eventing components. I worked on the initial serving spec and requirements for non-Istio ingresses and on the initial eventing documentation. Since then, I've worked on most areas of the project, including docs and the website, the operator, knative-extensions, governance, automation, and working group organization.
I'm running for TOC because I'm happy with the community we've built here and I'm looking forward to making Knative even more successful over the next two years.

2
elections/2022-TOC/candidate-zroubalik.md
View File

@ -7,7 +7,7 @@ info:
-------------------------------------------------------------
Hi, I am Zbynek Roubalik (Zbyněk Roubalík if you fancy Czech diacritics). My main focus have been around Functions on Knative,
ie. some initial not so successful attempts, then Boson project, that later became Knative Sandbox project (`func` kn plugin)
ie. some initial not so successful attempts, then Boson project, that later became Knative extensions project (`func` kn plugin)
and is now on it's way to become a full-fledged Working Group, yay!
The other area of my interest is around KEDA & Knative integration, which initally enabled autoscaling of a few Eventing Sources
and has a great potential to be expanded even more. This really makes even the Knative infrastructure serverless.

2
elections/2023-TOC/candidate-davidhadas.md
View File

@ -18,7 +18,7 @@ My main focus in the area of Knative Security is two folded:
Knative creates uniformity between deployed services, I see such uniformity as a great opportunity to also secure such services "out-of-the-box".
I aim for Knative to be a secure-by-default system that deploys secure-by-default services. As part of this Security Agenda:
- I contributed Security-Guard to Knative (https://github.com/knative-sandbox/security-guard)
- I contributed Security-Guard to Knative (https://github.com/knative-extensions/security-guard)
- I now work with others in the community to expedite support for end-to-end TLS and mTLS that will assure service data is secured, even without a service mesh.
A Second important aspect of my work is in helping the Knative community grow by showing its value for the deployment of microservices (beyond serverless, and functions).

4
label_sync/labels.yaml
View File

@ -322,7 +322,7 @@ repos:
description: Issues or PRs related to testing docker images found at /images
target: issues
addedBy: anyone
knative-sandbox/eventing-kafka-broker:
knative-extensions/eventing-kafka-broker:
labels:
- color: 782b90
name: area/data-plane
@ -356,7 +356,7 @@ repos:
name: Install
target: both
addedBy: humans
knative-sandbox/net-istio:
knative-extensions/net-istio:
labels:
- color: 447cf6
name: area/mesh

4
mechanics/CREATING-A-SANDBOX-REPO.md → mechanics/CREATING-AN-EXTENSIONS-REPO.md
View File

@ -1,6 +1,6 @@
---
title: "Creating a sandbox repo"
linkTitle: "Sandbox repo process"
title: "Creating a extensions repo"
linkTitle: "extensions repo process"
weight: 30
type: "docs"
---

6
mechanics/MATURITY-LEVELS.md
View File

@ -11,7 +11,7 @@ API", "eventing delivery" and "eventing sources", each of which has artifacts in
multiple repositories).
Note that this document intentionally refers to the process of selecting
implemented interfaces from sandbox which should be part of core as
implemented interfaces from extensions which should be part of core as
"migration-to-core" rather than "incubation" or "promotion" – while it may be
personally satisfying to have a component be part of the core, components which
are not in the core may be equally valuable and production-worthy.
@ -24,11 +24,11 @@ In the initiating phase, a project is starting up, and may have minimal
additional artifacts around the code itself. The minimum bar for an initiating
project in the knative-extensions org is:
- [Adopted the CLA bot and OWNERS file / Tide merge process](https://github.com/knative/community/blob/master/mechanics/CREATING-A-SANDBOX-REPO.md#technical-requirements),
- [Adopted the CLA bot and OWNERS file / Tide merge process](https://github.com/knative/community/blob/master/mechanics/CREATING-AN-EXTENTIONS-REPO.md#technical-requirements),
to ensure IP ownership
- Adopt the
[Knative Code of Conduct](https://github.com/knative/community/blob/master/CODE-OF-CONDUCT.md)
- [Sponsored by a WG lead](https://github.com/knative/community/blob/master/mechanics/CREATING-A-SANDBOX-REPO.md#criteria)
- [Sponsored by a WG lead](https://github.com/knative/community/blob/master/mechanics/CREATING-AN-EXTENTIONS-REPO.md#criteria)
- Have a README.md that describes the repo(s)
Projects which do not declare otherwise are assumed to be in the "Initiating"

2
mechanics/ROADMAPS.md
View File

@ -2,7 +2,7 @@
## Overview
All [working groups](../working-groups/WORKING-GROUPS.md) should maintain a current and up-to-date roadmap in a GitHub Project. It's recommended that a _single org-level project_ in the `knative` org should be used; for linking to issues in `knative-extensions`, cards with the URL of the sandbox issue can be used.
All [working groups](../working-groups/WORKING-GROUPS.md) should maintain a current and up-to-date roadmap in a GitHub Project. It's recommended that a _single org-level project_ in the `knative` org should be used; for linking to issues in `knative-extensions`, cards with the URL of the extensions issue can be used.
Working Groups should link to their roadmaps in the Working Group documentation, and should work off the roadmap on a week-to-week or month-to-month basis.

2
mechanics/TOC.md
View File

@ -33,7 +33,7 @@ Current TOC members and
with at least 3 months tenure are eligible to stand for election. The approver
role may be held within either
[Knative](https://github.com/knative/community/blob/main/peribolos/knative.yaml) or
[Knative Sandbox](https://github.com/knative/community/blob/main/peribolos/knative-extensions.yaml).
[Knative Extensions](https://github.com/knative/community/blob/main/peribolos/knative-extensions.yaml).
Candidates may self-nominate or be nominated by another eligible member. The
approximate time commitment of a TOC member is around 8 hours per week.

8
working-groups/WORKING-GROUPS.md
View File

@ -84,7 +84,7 @@ Covers API [resources](https://github.com/knative/serving/tree/main/pkg/apis/ser
| Community Meeting Calendar | Wed 9:30am PST [Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) |
| Meeting Notes | [Notes](https://docs.google.com/document/d/1rpag5-zffHGxAT7V4Nv28C_xx5Ow6L4mZuHbe3ebOQ8/edit) |
| Document Folder | [API](https://drive.google.com/drive/folders/1eCSmaqJ4LYcuS3TlOqjW0xETnzLmo6Q9), [Scaling](https://drive.google.com/drive/folders/1IDDkJ3FD47xFSHY3iA9U2Q8th3Cwdo0K), [Networking](https://docs.google.com/document/d/1rpag5-zffHGxAT7V4Nv28C_xx5Ow6L4mZuHbe3ebOQ8/edit) |
| Repos | [`knative/serving`](https://github.com/knative/serving), [`knative/networking`](https://github.com/knative/networking), [`knative-sandbox/net-*`](https://github.com/knative-sandbox?q=net) |
| Repos | [`knative/serving`](https://github.com/knative/serving), [`knative/networking`](https://github.com/knative/networking), [`knative-extensions/net-*`](https://github.com/knative-extensions?q=net) |
| Slack Channel | [#knative-serving](https://cloud-native.slack.com/archives/C04LMU0AX60) (need to join [CNCF Slack](https://slack.cncf.io/) for the first time) |
| Github Team WG Leads | [@knative/serving-wg-leads](https://github.com/orgs/knative/teams/serving-wg-leads/members) |
@ -195,7 +195,7 @@ Event sources, bindings, FaaS framework, and orchestration
## Functions
Knative Functions [CLI](https://github.com/knative/func), API, and [language packs](https://github.com/knative-sandbox/func-tastic)
Knative Functions [CLI](https://github.com/knative/func), API, and [language packs](https://github.com/knative-extensions/func-tastic)
| Artifact | Link |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------|
@ -260,7 +260,7 @@ performance/scale/load testing infrastructure
| Meeting Notes | [Notes](https://docs.google.com/document/d/1aPRwYGD4XscRIqlBzbNsSB886PJ0G-vZYUAAUjoydko) |
| Document Folder | [Folder](https://drive.google.com/drive/folders/1_1oWL7skjVt2211T0aagpwzDEfWmEIQK) |
| Repo prefixes | `actions-*` |
| Repos | [`knative/hack`](https://github.com/knative/hack), [`knative/test-infra`](https://github.com/knative/test-infra), [`knative-sandbox/.github`](https://github.com/knative-sandbox/.github), [`knative-sandbox/kperf`](https://github.com/knative-sandbox/kperf), [`knative-sandbox/reconciler-test`](https://github.com/knative-sandbox/reconciler-test), [`knative-sandbox/knobots`](https://github.com/knative-sandbox/knobots) |
| Repos | [`knative/hack`](https://github.com/knative/hack), [`knative/test-infra`](https://github.com/knative/test-infra), [`knative-extensions/.github`](https://github.com/knative-extensions/.github), [`knative-extensions/kperf`](https://github.com/knative-extensions/kperf), [`knative-extensions/reconciler-test`](https://github.com/knative-extensions/reconciler-test), [`knative-extensions/knobots`](https://github.com/knative-extensions/knobots) |
| Slack Channel | [#knative-productivity](https://cloud-native.slack.com/archives/C04LY4M2G49) (need to join [CNCF Slack](https://slack.cncf.io/) for the first time) |
| Github Team WG leads | [@knative/productivity-wg-leads](https://github.com/orgs/knative/teams/productivity-wg-leads/members) |
@ -313,7 +313,7 @@ The Eventing Kafka was a dedicated working group for Kafka-based Knative Eventin
| Artifact | Link |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------|
| Charter / Mission | [Charter](/working-groups/kafka/CHARTER.md) |
| Roadmap | [Roadmap](https://github.com/orgs/knative-sandbox/projects/8) |
| Roadmap | [Roadmap](https://github.com/orgs/knative-extensions/projects/8) |
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
| Meeting Notes | [Notes](https://docs.google.com/document/d/1ykBVPtiosGoDjzBklMt9HxbinGrMod6itOvfe6DeVmA/edit) |
| Document Folder | [Folder](https://drive.google.com/drive/folders/1ra5czyKOaMsWuwWXzkhce6_g6rFBdCxg?usp=sharing) |

4
working-groups/kafka/CHARTER.md
View File

@ -2,7 +2,7 @@
# Motivation/Abstract
Within the knative-sandbox org, Kafka based eventing currently includes 2 channel implementations, 2 sources implementations, 1 broker and 1 sink with more than three vendors and multiple users for production workloads. With that, it is desired to have a dedicated forum for Kafka based Eventing which can be really beneficial both for exposure and focus.
Within the knative-extensions org, Kafka based eventing currently includes 2 channel implementations, 2 sources implementations, 1 broker and 1 sink with more than three vendors and multiple users for production workloads. With that, it is desired to have a dedicated forum for Kafka based Eventing which can be really beneficial both for exposure and focus.
# Mission Statement
@ -16,7 +16,7 @@ The Eventing Kafka working group is the innovation forum for Kafka experts, end
# In Scope
* Maintain a roadmap that covers all the Kafka based projects within knative-sandbox.
* Maintain a roadmap that covers all the Kafka based projects within knative-extensions.
* Funnel the feedback of Kafka eventing components and surface that to other working groups (e.g. to unblock a specific feature development or enhance the user experience of Kafka based Eventing components)
* Work with the Docs WG to maintain and enhance the Kafka components docs.
* Maintain a guide that helps Eventing users understand the differences between existing Kafka components and how to choose between them.