Update main Markdown files to kbind and initialize moving the website

.github/ISSUE_TEMPLATE/adopters.yaml

@@ -1,5 +1,5 @@
 name: Register as adopter
-description: If your organization is using kube-bind, we would be delighted to add you to our list of adopters. Please report how you use kube-bind and we will take care of adding it to our adopters list.
+description: If your organization is using kbind, we would be delighted to add you to our list of adopters. Please report how you use kbind and we will take care of adding it to our adopters list.
 title: "adopter: COMPANY_NAME"
 labels:
   - kind/documentation
@@ -25,15 +25,15 @@ body:
     id: description
     attributes:
       label: Description
-      description: What are you using kube-bind for at your organization? Are you using it for a specific product or project?
+      description: What are you using kbind for at your organization? Are you using it for a specific product or project?
     validations:
       required: true
 
   - type: dropdown
     id: maturity
     attributes:
       label: Maturity Stage
-      description: What stage are you at in your adoption of kube-bind?
+      description: What stage are you at in your adoption of kbind?
       multiple: false
       options:
         - Production

.github/ISSUE_TEMPLATE/bug_report.yaml

@@ -69,7 +69,7 @@ body:
   - type: input
     id: kube_bind_version
     attributes:
-      label: kube-bind version
+      label: kbind version
       description: Version of kubectl-bind plugin or konnector/backend
       placeholder: e.g., v0.0.7
     validations:

.gitignore

@@ -8,6 +8,7 @@ coverage.*
 *.kubeconfig
 .kcp
 .kube-bind
+.kbind
 /dist
 /hack/tools
 /build

ADOPTERS.md

@@ -1,11 +1,11 @@
-# kube-bind Adopters
+# kbind Adopters
 
-This file lists organizations and projects that have adopted kube-bind in
+This file lists organizations and projects that have adopted kbind in
 production or as a core part of their platform.
 
-If you are using kube-bind and would like to be listed here, please open a
+If you are using kbind and would like to be listed here, please open a
 pull request.
 
 | Organization | Type | Use Case | Link |
 |---|---|---|---|
-| Platform Mesh | OSS Project | Uses kube-bind as the cross-cluster service binding layer, enabling users to add kube-bind as a provider and automatically create bindings between workload clusters and managed services within their platform. | <https://platform-mesh.io> |
+| Platform Mesh | OSS Project | Uses kbind as the cross-cluster service binding layer, enabling users to add kbind as a provider and automatically create bindings between workload clusters and managed services within their platform. | <https://platform-mesh.io> |

CHANGELOG.md

@@ -22,11 +22,11 @@ Major improvements to `PermissionClaims` in APIServiceExportSpec:
 ### Provider-side Namespace Management
 Enhanced namespace management on the provider side:
 - **APIServiceNamespace Controller**: Automatically creates Roles and RoleBindings
-- **Namespace Isolation**: Each consumer gets isolated provider-side namespaces  
+- **Namespace Isolation**: Each consumer gets isolated provider-side namespaces
 - **RBAC Automation**: Proper permissions created based on scope (namespaced vs cluster-scoped)
 - **Namespace Pre-provisioning**: Providers can pre-create namespaces for better UX
 
-**Important**: When `ClusterScope` mode is used, cluster-wide permissions are created instead of namespaced ones. 
+**Important**: When `ClusterScope` mode is used, cluster-wide permissions are created instead of namespaced ones.
 
 ## API Changes in v0.5.0 release
 

CONTRIBUTING.md

@@ -1,9 +1,9 @@
-# Contributing to kube-bind
+# Contributing to kbind
 
-kube-bind is [Apache 2.0 licensed](LICENSE) and we accept contributions via
+kbind is [Apache 2.0 licensed](LICENSE) and we accept contributions via
 GitHub pull requests.
 
-Please read the following guide if you're interested in contributing to kube-bind.
+Please read the following guide if you're interested in contributing to kbind.
 
 ## Certificate of Origin
 
@@ -31,14 +31,14 @@ bin/kubectl-bind
 
 Starting to participate in a new project can sometimes be overwhelming, and you may not know where to begin. Fortunately, we are here to help! We track all of our tasks here in GitHub, and we label our issues to categorize them. Here are a couple of handy links to check out:
 
-* [Good first issue](https://github.com/kube-bind/kube-bind/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) issues
-* [Help wanted](https://github.com/kube-bind/kube-bind/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) issues
+* [Good first issue](https://github.com/kbind-dev/kbind/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) issues
+* [Help wanted](https://github.com/kbind-dev/kbind/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) issues
 
 You're certainly not limited to only these kinds of issues, though! If you're comfortable, please feel free to try working on anything that is open.
 
 We do use the assignee feature in GitHub for issues. If you find an unassigned issue, comment asking if you can be assigned, and ideally wait for a maintainer to respond. If you find an assigned issue and you want to work on it or help out, please reach out to the assignee first.
 
-Sometimes you might get an amazing idea and start working on a huge amount of code. We love and encourage excitement like this, but we do ask that before you embarking on a giant pull request, please reach out to the community first for an initial discussion. You could [file an issue](https://github.com/kube-bind/kube-bind/issues/new/choose).
+Sometimes you might get an amazing idea and start working on a huge amount of code. We love and encourage excitement like this, but we do ask that before you embarking on a giant pull request, please reach out to the community first for an initial discussion. You could [file an issue](https://github.com/kbind-dev/kbind/issues/new/choose).
 
 Finally, we welcome and value all types of contributions, beyond "just code"! Other types include triaging bugs, tracking down and fixing flaky tests, improving our documentation, helping answer community questions, proposing and reviewing designs, etc.
 
@@ -76,7 +76,7 @@ Finally, we welcome and value all types of contributions, beyond "just code"! Ot
 
 ### Using Kubebuilder CRD Validation Annotations
 
-All of the API resources for `kube-bind` are `CustomResourceDefinitions`, and we generate YAML spec for them from our Go types using [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder).
+All of the API resources for `kbind` are `CustomResourceDefinitions`, and we generate YAML spec for them from our Go types using [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder).
 
 When adding a field that requires validation, custom annotations are used to translate this logic into the generated OpenAPI spec. [This doc](https://book.kubebuilder.io/reference/markers/crd-validation.html) gives an overview of possible validations. These annotations map directly to concepts in the [OpenAPI Spec](https://swagger.io/specification/#data-type-format) so, for instance, the `format` of strings is defined there, not in kubebuilder. Furthermore, Kubernetes has forked the OpenAPI project [here](https://github.com/kubernetes/kube-openapi/tree/master/pkg/validation) and extends more formats in the extensions-apiserver [here](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1/types_jsonschema.go#L27).
 

GOVERNANCE.md

@@ -1,6 +1,6 @@
-# kube-bind Project Governance
+# kbind Project Governance
 
-The kube-bind project is dedicated to build a vendor-neutral mechanism to bind 
+The kbind project is dedicated to build a vendor-neutral mechanism to bind
 services of different kinds into Kubernetes clusters using Kubernetes-native APIs.
 This governance explains how the project is run.
 
@@ -13,31 +13,31 @@ This governance explains how the project is run.
 
 ## Values
 
-The kube-bind and its leadership embrace the following values:
+The kbind and its leadership embrace the following values:
 
- * *Openness*: Communication and decision-making happens in the open and is 
-   discoverable for future reference. As much as possible, all discussions and 
+ * *Openness*: Communication and decision-making happens in the open and is
+   discoverable for future reference. As much as possible, all discussions and
    work take place in public forums and open repositories.
- * *Fairness*: All stakeholders have the opportunity to provide feedback and 
+ * *Fairness*: All stakeholders have the opportunity to provide feedback and
    submit contributions, which will be considered on their merits.
- * *Community over Product or Company*: Sustaining and growing our community 
-   takes priority over shipping code or sponsors' organizational goals. Each 
+ * *Community over Product or Company*: Sustaining and growing our community
+   takes priority over shipping code or sponsors' organizational goals. Each
    contributor participates in the project as an individual.
- * *Inclusivity*: We innovate through different perspectives and skill sets, 
+ * *Inclusivity*: We innovate through different perspectives and skill sets,
    which can only be accomplished in a welcoming and respectful environment.
- * *Participation*: Responsibilities within the project are earned through 
-   participation, and there is a clear path up the contributor ladder into 
+ * *Participation*: Responsibilities within the project are earned through
+   participation, and there is a clear path up the contributor ladder into
    leadership positions.
 
 ## Maintainers
 
-kube-bind Maintainers have write access to the [project GitHub repository](https://github.com/kube-bind/kube-bind).
+kbind Maintainers have write access to the [project GitHub repository](https://github.com/kbind-dev/kbind).
 They can merge their own patches or patches from others. The current maintainers
-can be found as top-level approvers in [OWNERS](./OWNERS).  Maintainers collectively 
+can be found as top-level approvers in [OWNERS](./OWNERS).  Maintainers collectively
 manage the project's resources and contributors.
 
 This privilege is granted with some expectation of responsibility: maintainers
-are people who care about the kube-bind project and want to help it grow and
+are people who care about the kbind project and want to help it grow and
 improve. A maintainer is not just someone who can make changes, but someone who
 has demonstrated their ability to collaborate with the team, get the most
 knowledgeable people to review code and docs, contribute high-quality code, and
@@ -46,7 +46,7 @@ follow through to fix issues (in code or tests).
 A maintainer is a contributor to the project's success and a citizen helping
 the project succeed.
 
-The collective team of all Maintainers is known as the Maintainer Council, which 
+The collective team of all Maintainers is known as the Maintainer Council, which
 is the governing body for the project.
 
 ## Becoming a Maintainer
@@ -69,34 +69,34 @@ To become a Maintainer you need to demonstrate the following:
   <!-- add any additional Maintainer requirements here -->
 
 A new Maintainer must be proposed by an existing maintainer by sending a message to the
-[developer mailing list](https://groups.google.com/g/kube-bind-dev). A simple majority 
+[developer mailing list](https://groups.google.com/g/kube-bind-dev). A simple majority
 vote of existing Maintainers approves the application.
 
 Maintainers who are selected will be granted the necessary GitHub rights,
 and invited to the [private maintainer mailing list](https://groups.google.com/g/kube-bind-dev-private).
 
 ### Bootstrapping Maintainers
 
-To bootstrap the process, 3 maintainers are defined (in the initial PR adding 
-this to the repository) that do not necessarily follow the above rules. When a 
-new maintainer is added following the above rules, the existing maintainers 
-define one not following the rules to step down, until all of them follow the 
+To bootstrap the process, 3 maintainers are defined (in the initial PR adding
+this to the repository) that do not necessarily follow the above rules. When a
+new maintainer is added following the above rules, the existing maintainers
+define one not following the rules to step down, until all of them follow the
 rules.
 
 ### Removing a Maintainer
 
-Maintainers may resign at any time if they feel that they will not be able to 
+Maintainers may resign at any time if they feel that they will not be able to
 continue fulfilling their project duties.
 
-Maintainers may also be removed after being inactive, failure to fulfill their 
-Maintainer responsibilities, violating the Code of Conduct, or other reasons. 
-Inactivity is defined as a period of very low or no activity in the project for 
+Maintainers may also be removed after being inactive, failure to fulfill their
+Maintainer responsibilities, violating the Code of Conduct, or other reasons.
+Inactivity is defined as a period of very low or no activity in the project for
 a year or more, with no definite schedule to return to full Maintainer activity.
 
 A Maintainer may be removed at any time by a 2/3 vote of the remaining maintainers.
 
-Depending on the reason for removal, a Maintainer may be converted to Emeritus 
-status. Emeritus Maintainers will still be consulted on some project matters, 
+Depending on the reason for removal, a Maintainer may be converted to Emeritus
+status. Emeritus Maintainers will still be consulted on some project matters,
 and can be rapidly returned to Maintainer status if their availability changes.
 
 ## Code of Conduct
@@ -112,21 +112,21 @@ on the [private Maintainer mailing list](https://groups.google.com/g/kube-bind-d
 ## Security Response Team
 
 The Maintainers will appoint a Security Response Team to handle security reports.
-This committee may simply consist of the Maintainer Council themselves. If this 
-responsibility is delegated, the Maintainers will appoint a team of at least two 
-contributors to handle it. The Maintainers will review who is assigned to this 
+This committee may simply consist of the Maintainer Council themselves. If this
+responsibility is delegated, the Maintainers will appoint a team of at least two
+contributors to handle it. The Maintainers will review who is assigned to this
 at least once a year.
 
-The Security Response Team is responsible for handling all reports of security 
+The Security Response Team is responsible for handling all reports of security
 holes and breaches according to the [security policy](./SECURITY.md).
 
 ## Voting
 
-While most business in kube-bind is conducted by "lazy consensus", periodically
+While most business in kbind is conducted by "lazy consensus", periodically
 the Maintainers may need to vote on specific actions or changes.
 A vote can be taken on [the developer mailing list](https://groups.google.com/g/kube-bind-dev) or
 [the private Maintainer mailing list](https://groups.google.com/g/kube-bind-dev-private)
-for security or conduct matters.  Votes may also be taken at the community call 
+for security or conduct matters.  Votes may also be taken at the community call
 meeting. Any Maintainer may demand a vote be taken.
 
 Most votes require a simple majority of all Maintainers to succeed. Maintainers
@@ -135,5 +135,5 @@ Governance require a 2/3 vote of all Maintainers.
 
 ## Modifying this Charter
 
-Changes to this Governance and its supporting documents may be approved by a 
-2/3 vote of the Maintainers.
+Changes to this Governance and its supporting documents may be approved by a
+2/3 vote of the Maintainers.

README.md

@@ -1,16 +1,16 @@
 <img alt="Logo" width="196px" style="margin-right: 30px;" align="left" src="./docs/images/logo.png"></img>
 
-[![Go Report Card](https://goreportcard.com/badge/github.com/kube-bind/kube-bind)](https://goreportcard.com/report/github.com/kube-bind/kube-bind)
-[![GitHub](https://img.shields.io/github/license/kube-bind/kube-bind)](https://github.com/kube-bind/kube-bind/blob/main/LICENSE)
-[![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/kube-bind/kube-bind?sort=semver)](https://github.com/kube-bind/kube-bind/releases/latest)
+[![Go Report Card](https://goreportcard.com/badge/github.com/kbind-dev/kbind)](https://goreportcard.com/report/github.com/kbind-dev/kbind)
+[![GitHub](https://img.shields.io/github/license/kbind-dev/kbind)](https://github.com/kbind-dev/kbind/blob/main/LICENSE)
+[![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/kbind-dev/kbind?sort=semver)](https://github.com/kbind-dev/kbind/releases/latest)
 
-# kube-bind
+# kbind
 
 You are invited to [contribute](#contributing)!
 
 ## What is it?
 
-kube-bind provides better support for service providers and consumers that reside in distinct Kubernetes clusters.
+kbind (formerly known as kube-bind) provides better support for service providers and consumers that reside in distinct Kubernetes clusters.
 
 - A service provider defines its API in terms of CRDs and associated permission claims/limitations, and exports it for use from other clusters.
 - Service consumers identify the services they want to consume.
@@ -36,17 +36,17 @@ $ kubectl get mangodbs
 
 ## For more information
 
-For more information go to https://kube-bind.io or watch the [ContainerDays talk](https://www.youtube.com/watch?v=dg0g15Qv5Fo&t=1s)
+For more information go to https://kbind.dev or watch the [ContainerDays talk](https://www.youtube.com/watch?v=dg0g15Qv5Fo&t=1s)
 or the [KubeCon talk](https://www.youtube.com/watch?v=Uv0ivz5xej4).
 
-kube-bind is following this manifesto from the linked talk:
+kbind is following this manifesto from the linked talk:
 
-![kube-bind manifesto](docs/images/manifesto.png)
+![kbind manifesto](docs/images/manifesto.png)
 
 ## Contributing
 
 We ❤️ our contributors! If you're interested in helping us out, please check out
-[Contributing to kube-bind](./CONTRIBUTING.md) and [kube-bind Project Governance](./GOVERNANCE.md).
+[Contributing to kbind](./CONTRIBUTING.md) and [kbind Project Governance](./GOVERNANCE.md).
 
 ## Getting in touch
 
@@ -62,7 +62,7 @@ There are several ways to communicate with us:
     <!-- TODO(community-call-advertise): once a YouTube channel is set up, add: -->
     <!--   - See recordings of past community meetings on [YouTube](TODO-youtube-url). -->
 
-See the [community page](https://docs.kube-bind.io/main/community) for more details.
+See the [community page](https://docs.kbind.dev/main/community) for more details.
 
 ## Technical Overview
 
@@ -72,7 +72,7 @@ All the actions shown between the clusters are done by the konnector, except: th
 
 ## Usage
 
-To get familiar with setting up the environment, please check out docs at [kube-bind.io](https://docs.kube-bind.io/main/setup).
+To get familiar with setting up the environment, please check out docs at [kbind.dev](https://docs.kbind.dev/main/setup).
 
 ### Limitations