rename k8dash to skooner

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to K8dash
+# Contributing to Skooner
 We welcome any kinds of contribution and want to make contributing to this project as easy and transparent as
 possible.
 

PATH_TO_MAINTAINER.md

@@ -1,8 +1,8 @@
-# k8dash’s Maintainership Criteria 
+# Skooner’s Maintainership Criteria 
 
 Editor’s note: We adapted this content from [HDFS's Critera for Committership Document](https://hadoop.apache.org/committer_criteria.html)
 
-Maintainers are responsible for the growth and forward projection of the project. They review and merge code changes, complete roadmap planning, help cultivate and maintain a healthy community, and more. There are many meaningful ways to contribute to k8dash, which can lead to becoming a maintainer. 
+Maintainers are responsible for the growth and forward projection of the project. They review and merge code changes, complete roadmap planning, help cultivate and maintain a healthy community, and more. There are many meaningful ways to contribute to Skooner, which can lead to becoming a maintainer. 
 
 Here are few criteria that current maintainers look for from potential new maintainers:
 A history of sustained contribution to the project. This is a way for a contributor to demonstrate their expertise in an area, and thus their ability to help review and commit contributions by others in that same area. Sustained contribution also demonstrates commitment to the project by showing that an individual will continue contributing even after they become a committer.
@@ -18,11 +18,11 @@ Here are few criteria that current maintainers look for from potential new maint
 
 There are multiple paths to becoming an maintainer. Here are a few hypothetical example paths:
 
-- *Kamala* works at a large company that has many different Kubernetes clusters. While integrating and installing k8dash, she realizes that there are a number of issues and holes in the documentation. She opens new issues for each bug. She’s able to fix some of the bugs, but leans on the community to help patch the other issues, while doing extensive debugging/refactoring to see what works. Kamala then works with Nancy, the release manager, to make sure that these changes are incorporated into the next monthly versioned release.
-- *Bill* works at a small- to medium-sized company that has k8dash deployed. He also is a web developer. Bill finds accessibility issues on the website. He files the issues and submits patches. Bill then joins the community calls and Slack channel to chat about website improvements, from internal search to mapping. Through these calls and messages, he then starts to assign different tasks based on the skills of other contributors. He wants to get the ball rolling on a full scale overhaul of the website. Bill creates his own fork to collaborate on. Bill continues to project manage the website overhaul, reviewing and merging code from other contributors into his fork. Once the project is “complete,” he submits his fork to merge into main. At this point Bill is invited to become a maintainer. Once Bill is a maintainer, he continues to push website improvements, while cultivating community and coaching newer contributors.
-- *Sue* is a technical writer interested in Kubernetes and k8dash. She has an in-depth knowledge of k8dash but notices there are holes and errors in the documentation. Sue starts with fixing outdated information from previous versions and updates incorrect examples by finding and reaching out to the subject matter experts/maintainers. She is able to update and add to the documentation and comes to have a deep understanding of k8dash. Sue is then knowledgeable enough to start answering questions that come through the Slack channel and mailing list, doing this autonomously and without additional guidance. This demonstrates her deep knowledge of the project, attention to detail, independence, and focus on community. At this point Sue is invited to become a maintainer.  
-- *Samson* is a developer advocate at his company. He is focused on connecting users to the correct projects. Samson is able to organize (virtual) events, is immersed in the larger open source community, is a connector. In short, Samson cultivates community. He takes the initiative to join the monthly open community calls and Slack channels. Samson works with subject matter experts and current maintainers to understand what kind of events they want to become involved in and speak at. He then creates an event playbook that outlines how to get involved with those targeted communities and how a representative from k8dash can host an event. Samson also collaborates with Marie, a maintainer and the lead designer for the project, to create slide templates - complete with a standard set of talking points. At this point Samson is invited to become a maintainer. However, his work doesn’t stop there. In addition to the events he oversees, he also has an ongoing collaboration with Sue to create blog articles to evangelize k8dash’s new features. 
-- *Marie* is a designer. She is also passionate about open source. She finds k8dash during Hacktoberfest when she sees an open issue for a new logo. Marie talks to the current maintainers, sends out a survey on Slack. She incorporates feedback and creates three iterations of a logo. Marie presents it to the community and perfects the logo that the community chooses. Once she submits the logo, she notices that the project doesn’t have a design guide or color palette. Marie carves out time in the next open community call to discuss these items. After she gets feedback on both items, Marie creates and submits both the color palette and design guide. She also makes it known that she wants to be the lead designer for k8dash, providing a list of assets that need to be created that she believes will help make k8dash more recognizable. Marie then starts to recruit other designers to help create assets. She manages and triages tickets and has a steady flow of iterations from contributors being submitted. At this point she is invited to become a maintainer. 
+- *Kamala* works at a large company that has many different Kubernetes clusters. While integrating and installing Skooner, she realizes that there are a number of issues and holes in the documentation. She opens new issues for each bug. She’s able to fix some of the bugs, but leans on the community to help patch the other issues, while doing extensive debugging/refactoring to see what works. Kamala then works with Nancy, the release manager, to make sure that these changes are incorporated into the next monthly versioned release.
+- *Bill* works at a small- to medium-sized company that has Skooner deployed. He also is a web developer. Bill finds accessibility issues on the website. He files the issues and submits patches. Bill then joins the community calls and Slack channel to chat about website improvements, from internal search to mapping. Through these calls and messages, he then starts to assign different tasks based on the skills of other contributors. He wants to get the ball rolling on a full scale overhaul of the website. Bill creates his own fork to collaborate on. Bill continues to project manage the website overhaul, reviewing and merging code from other contributors into his fork. Once the project is “complete,” he submits his fork to merge into main. At this point Bill is invited to become a maintainer. Once Bill is a maintainer, he continues to push website improvements, while cultivating community and coaching newer contributors.
+- *Sue* is a technical writer interested in Kubernetes and Skooner. She has an in-depth knowledge of Skooner but notices there are holes and errors in the documentation. Sue starts with fixing outdated information from previous versions and updates incorrect examples by finding and reaching out to the subject matter experts/maintainers. She is able to update and add to the documentation and comes to have a deep understanding of Skooner. Sue is then knowledgeable enough to start answering questions that come through the Slack channel and mailing list, doing this autonomously and without additional guidance. This demonstrates her deep knowledge of the project, attention to detail, independence, and focus on community. At this point Sue is invited to become a maintainer.  
+- *Samson* is a developer advocate at his company. He is focused on connecting users to the correct projects. Samson is able to organize (virtual) events, is immersed in the larger open source community, is a connector. In short, Samson cultivates community. He takes the initiative to join the monthly open community calls and Slack channels. Samson works with subject matter experts and current maintainers to understand what kind of events they want to become involved in and speak at. He then creates an event playbook that outlines how to get involved with those targeted communities and how a representative from Skooner can host an event. Samson also collaborates with Marie, a maintainer and the lead designer for the project, to create slide templates - complete with a standard set of talking points. At this point Samson is invited to become a maintainer. However, his work doesn’t stop there. In addition to the events he oversees, he also has an ongoing collaboration with Sue to create blog articles to evangelize Skooner’s new features. 
+- *Marie* is a designer. She is also passionate about open source. She finds Skooner during Hacktoberfest when she sees an open issue for a new logo. Marie talks to the current maintainers, sends out a survey on Slack. She incorporates feedback and creates three iterations of a logo. Marie presents it to the community and perfects the logo that the community chooses. Once she submits the logo, she notices that the project doesn’t have a design guide or color palette. Marie carves out time in the next open community call to discuss these items. After she gets feedback on both items, Marie creates and submits both the color palette and design guide. She also makes it known that she wants to be the lead designer for Skooner, providing a list of assets that need to be created that she believes will help make Skooner more recognizable. Marie then starts to recruit other designers to help create assets. She manages and triages tickets and has a steady flow of iterations from contributors being submitted. At this point she is invited to become a maintainer. 
 
 ### Maintainer Responsibilities and Recognition
 

VERSIONING_AND_RELEASE_STRATEGY.md

@@ -6,7 +6,7 @@
 - **[Breaking Changes Guide](#breaking-changes-guide)**<br>
 
 ## Versioning Strategy
-Once k8dash version v1.0.0 is released, subsequent releases will follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html).  
+Once Skooner version v1.0.0 is released, subsequent releases will follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html).  
 Until then, breaking changes may occur without an uptick to the Major version.  
 
 Versions will use the `v<semantic version>` tag pattern.
@@ -26,7 +26,7 @@ Versions will use the `v<semantic version>` tag pattern.
 **Method**: Release Stable branch as a Minor/Patch release
 
 ### Strategy Reasoning
-- To support agile feature additions at a monthly pace, users of k8dash can expect 6 months of Stable updates on each Major version before 
+- To support agile feature additions at a monthly pace, users of Skooner can expect 6 months of Stable updates on each Major version before 
 needing to review any breaking changes. Users can simply subscribe to a particular Major version and pull the latest 
 changes for that version without worry.
 - If users want to be on the cutting edge, they have the option of subscribing to the latest changes on the Main branch.
@@ -46,7 +46,7 @@ changes for that version without worry.
 
 ## Breaking Changes Guide
 ### In General, removing/changing any particular interface in a non-additive way
-In general, if logic exists that interfaces with anything outside of k8dash (including user interfaces), removing that logic or changing the contract is likely
+In general, if logic exists that interfaces with anything outside of Skooner (including user interfaces), removing that logic or changing the contract is likely
 considered a breaking change.  Adding content/features to a user interface is additive and not a breaking change, unless it results
 in a major negative performance impact.
 
@@ -82,7 +82,7 @@ Changes in the minimum resource requirements for the deployment, due to a featur
 but ideally is considered in obvious cases.
 
 A new feature might be more CPU intensive or require caching that increases memory requirements.  Without this new
-minimum, k8dash might crash. Consider the following:
+minimum, Skooner might crash. Consider the following:
 
 - How might the requested change impact the performance of pulling or presenting a list of N items on large and active clusters?
    - Pulling a large dataset (even for a few items), depending on the auto-refresh frequency and use frequency, 

client/public/index.html

@@ -17,7 +17,7 @@
     <link rel="manifest" href="./manifest.json" />
     <link rel="apple-touch-icon" sizes="512x512 192x192 144x144 64x64 32x32 24x24 16x16" href="./logo.png">
     <link rel="apple-touch-startup-image" href="./logo.png">
-    <title>K8Dash</title>
+    <title>Skooner</title>
   </head>
   <body>
     <noscript>You need to enable JavaScript to run this app.</noscript>

client/public/manifest.json

@@ -1,6 +1,6 @@
 {
-  "short_name": "K8Dash",
-  "name": "K8Dash - Kubernetes Dashboard",
+  "short_name": "Skooner",
+  "name": "Skooner - Kubernetes Dashboard",
   "icons": [
     {
       "src": "logo.png",

client/src/app.tsx

@@ -5,7 +5,7 @@ import Error from './components/error';
 import {initRouter} from './router';
 import log from './utils/log';
 import Button from './components/button';
-import LogoSvg from './art/k8dashSvg';
+import LogoSvg from './art/skoonerSvg';
 import HamburgerSvg from './art/hamburgerSvg';
 
 type State = {

docs/helm/index.yaml

@@ -4,7 +4,7 @@ entries:
   - apiVersion: v1
     appVersion: 0.0.1
     created: 2019-04-25T11:53:15.386073-05:00
-    description: A Helm chart for Kubernetes K8Dash
+    description: A Helm chart for Kubernetes Skooner
     digest: 7a84cff8455803b1a5610987e054cebbe52b14878a2db6b22ae7b455a6105e09
     maintainers:
     - email: kiryanov.i@gmail.com