├── designs ├── website │ ├── Website_V0.png │ ├── Website_V1.png │ └── Website_V1.md └── sample-app │ ├── sample4-kamel.png │ ├── sample3-trigger.png │ ├── sample2-run-nodejs.png │ ├── sample5-extra-challenge.png │ └── sample1-how-to-use-kn-k8s.png ├── OWNERS ├── user-research ├── contributor-research │ ├── assets │ │ ├── motivations.png │ │ ├── recommendations.png │ │ ├── exp-levels-chart.png │ │ ├── additional-insights.png │ │ ├── community-engagement.png │ │ ├── education-work-chart.png │ │ ├── contributor-challenges.png │ │ ├── maintainer-challenges.png │ │ ├── reasons-for-disengagement.png │ │ ├── contributor-category-chart.png │ │ └── duration-of-involvement-chart.png │ ├── Introduction.md │ ├── README.md │ ├── Key-Findings.md │ └── Recommendations.md └── eventing-onboarding-research │ └── assets │ └── Survey-Design.md ├── CODE-OF-CONDUCT.md ├── SECURITY.md ├── .github └── workflows │ ├── weekly-UX-working-session-reminder.yaml │ └── bi-weekly-UX-WG-meeting-reminder.yaml ├── OWNERS_ALIASES ├── README.md └── CONTRIBUTING.md /designs/website/Website_V0.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/website/Website_V0.png -------------------------------------------------------------------------------- /designs/website/Website_V1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/website/Website_V1.png -------------------------------------------------------------------------------- /OWNERS: -------------------------------------------------------------------------------- 1 | # The OWNERS file is used by prow to automatically merge approved PRs. 2 | 3 | approvers: 4 | - ux-wg-leads -------------------------------------------------------------------------------- /designs/sample-app/sample4-kamel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/sample-app/sample4-kamel.png -------------------------------------------------------------------------------- /designs/sample-app/sample3-trigger.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/sample-app/sample3-trigger.png -------------------------------------------------------------------------------- /designs/sample-app/sample2-run-nodejs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/sample-app/sample2-run-nodejs.png -------------------------------------------------------------------------------- /designs/sample-app/sample5-extra-challenge.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/sample-app/sample5-extra-challenge.png -------------------------------------------------------------------------------- /designs/sample-app/sample1-how-to-use-kn-k8s.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/designs/sample-app/sample1-how-to-use-kn-k8s.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/motivations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/motivations.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/recommendations.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/recommendations.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/exp-levels-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/exp-levels-chart.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/additional-insights.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/additional-insights.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/community-engagement.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/community-engagement.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/education-work-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/education-work-chart.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/contributor-challenges.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/contributor-challenges.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/maintainer-challenges.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/maintainer-challenges.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/reasons-for-disengagement.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/reasons-for-disengagement.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/contributor-category-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/contributor-category-chart.png -------------------------------------------------------------------------------- /user-research/contributor-research/assets/duration-of-involvement-chart.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/knative/ux/HEAD/user-research/contributor-research/assets/duration-of-involvement-chart.png -------------------------------------------------------------------------------- /CODE-OF-CONDUCT.md: -------------------------------------------------------------------------------- 1 | ## Knative Community Code of Conduct 2 | 3 | The [Knative Community Code of Conduct](https://github.com/knative/community/blob/main/CODE-OF-CONDUCT.md) is defined in the [Knative community repository](https://github.com/knative/community). 4 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | # Knative Security Policy 2 | 3 | We're extremely grateful for security researchers and users that report vulnerabilities to the Knative Open Source Community. All reports are thoroughly investigated by a set of community volunteers. 4 | 5 | To make a report, please email the private security@knative.team list with the security details and the details expected for all Knative bug reports. 6 | 7 | See [Knative Security and Disclosure Information](https://knative.dev/docs/reference/security/) for more details. 8 | -------------------------------------------------------------------------------- /designs/website/Website_V1.md: -------------------------------------------------------------------------------- 1 | # List of first re-design fixes: 2 | 3 | Aesthetic/usability changes: 4 | - Swapping website colours to be in line with logo and to meet WCAG AAA (only non compliant one is the diagram which would be considered a graphical element) 5 | - Adding consistent corner rounding 6 | - Small layout improvements including margins, closeness of two main cta buttons 7 | - Hover colour adjustment for buttons. This is originally a purpleish colour that does not match the rest of the website. It changes to a darker blue 8 | - Indicate case studies are clickeable through adding white boxes with small hover css animation 9 | 10 | Content changes- 11 | - Changed the second block of information (the one in the blue background) need to "Know more" button to "Knative Concepts" that will take you to the concepts page 12 | 13 | ## Current design: 14 | 15 | ![](Website_V0.png) 16 | 17 | ## Proposed design: 18 | 19 | ![](Website_V1.png) 20 | -------------------------------------------------------------------------------- /user-research/eventing-onboarding-research/assets/Survey-Design.md: -------------------------------------------------------------------------------- 1 | ![Image](https://github.com/user-attachments/assets/2079bf7e-7bdf-4850-a8b4-558da364ea59) 2 | ![Image](https://github.com/user-attachments/assets/40c5fbe4-6c7c-4d19-b276-c996e6e5ec4d) 3 | ![Image](https://github.com/user-attachments/assets/17e129e8-c562-4274-ae49-c9fe886e7a12) 4 | ![Image](https://github.com/user-attachments/assets/d1945401-a291-4a3a-8250-dc9910a65672) 5 | ![Image](https://github.com/user-attachments/assets/7a86d229-a32e-4740-9b61-9fc96d8a5352) 6 | ![Image](https://github.com/user-attachments/assets/749ded77-5a11-49bf-a0cd-391d0d2c2788) 7 | ![Image](https://github.com/user-attachments/assets/7cfaa0f7-696a-47f5-9a87-126271afc2fa) 8 | ![Image](https://github.com/user-attachments/assets/a9adc971-9bd4-4845-9b55-6b205d6b4f5d) 9 | ![Image](https://github.com/user-attachments/assets/3dae9af3-3401-41db-8dc1-91d2ff4cf119) 10 | ![Image](https://github.com/user-attachments/assets/224e541a-6b2b-4238-9be3-67f534c6787a) 11 | ![Image](https://github.com/user-attachments/assets/9c59bbbf-875c-4d7a-972a-f078127d7adc) 12 | ![Image](https://github.com/user-attachments/assets/2f19a454-0247-479b-b81c-955d7bc663c8) 13 | ![Image](https://github.com/user-attachments/assets/98dfcb8b-b117-4cd8-8b58-018048252eae) 14 | ![Image](https://github.com/user-attachments/assets/6877c37a-77ae-44aa-ab79-c4d3311cb2c7) 15 | ![Image](https://github.com/user-attachments/assets/1c5a84ca-0043-4148-89ed-dd62e317d5d0) 16 | ![Image](https://github.com/user-attachments/assets/bdffb68e-952b-43da-bb3a-8e730c111ff0) 17 | ![Image](https://github.com/user-attachments/assets/df24ebeb-1f7c-4d0d-9e90-0da4caca358d) -------------------------------------------------------------------------------- /.github/workflows/weekly-UX-working-session-reminder.yaml: -------------------------------------------------------------------------------- 1 | # Copyright 2024 The Knative Authors. 2 | # 3 | # Licensed under the Apache License, Version 2.0 (the "License"); 4 | # you may not use this file except in compliance with the License. 5 | # You may obtain a copy of the License at 6 | # 7 | # http://www.apache.org/licenses/LICENSE-2.0 8 | # 9 | # Unless required by applicable law or agreed to in writing, software 10 | # distributed under the License is distributed on an "AS IS" BASIS, 11 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | # See the License for the specific language governing permissions and 13 | # limitations under the License. 14 | 15 | name: 'Weekly UX working session reminder' 16 | 17 | on: 18 | workflow_dispatch: 19 | schedule: # At 2:00 PM UTC on every Sunday (1 day before the meeting time, which is 2:00 PM UTC on every Monday) 20 | - cron: 0 14 * * 0 21 | 22 | jobs: 23 | remind: 24 | name: weekly-ux-working-session-reminder 25 | runs-on: 'ubuntu-latest' 26 | 27 | steps: 28 | - name: Post reminder to Slack 29 | uses: rtCamp/action-slack-notify@v2.2.1 30 | env: 31 | SLACK_ICON: http://github.com/knative.png?size=48 32 | SLACK_USERNAME: github-actions 33 | SLACK_TITLE: Weekly UX working session reminder 34 | SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} 35 | MSG_MINIMAL: 'true' 36 | SLACK_CHANNEL: 'knative-ux' 37 | SLACK_MESSAGE: The weekly UX working session will be happening tomorrow at this time (in 24 hours). Please join the [zoom meeting](https://zoom.us/j/98769530546), and add your agenda items to the [meeting notes](https://docs.google.com/document/d/1VCObP1IQFPDGzGG5KIgytQwX7RrU0tyeB7FGjkY0pPk/edit#heading=h.j4qyv6ihneq3) 38 | -------------------------------------------------------------------------------- /OWNERS_ALIASES: -------------------------------------------------------------------------------- 1 | # This file is auto-generated from peribolos. 2 | # Do not modify this file, instead modify peribolos/knative.yaml 3 | 4 | aliases: 5 | client-reviewers: [] 6 | client-wg-leads: 7 | - dsimansk 8 | client-writers: 9 | - dsimansk 10 | docs-reviewers: 11 | - nainaz 12 | - skonto 13 | docs-writers: 14 | - skonto 15 | eventing-reviewers: 16 | - Leo6Leo 17 | - aslom 18 | - cali0707 19 | - creydr 20 | eventing-wg-leads: 21 | - creydr 22 | - pierDipi 23 | eventing-writers: 24 | - Leo6Leo 25 | - aliok 26 | - cali0707 27 | - creydr 28 | - matzew 29 | - pierDipi 30 | func-reviewers: 31 | - jrangelramos 32 | func-writers: 33 | - gauron99 34 | - jrangelramos 35 | - lkingland 36 | - matejvasek 37 | - matzew 38 | - salaboy 39 | functions-wg-leads: 40 | - lkingland 41 | - salaboy 42 | knative-admin: 43 | - aliok 44 | - arsenetar 45 | - cardil 46 | - dprotaso 47 | - dsimansk 48 | - evankanderson 49 | - knative-automation 50 | - knative-prow-releaser-robot 51 | - knative-prow-robot 52 | - knative-prow-updater-robot 53 | - knative-test-reporter-robot 54 | - matzew 55 | - upodroid 56 | knative-release-leads: 57 | - dprotaso 58 | - dsimansk 59 | knative-robots: 60 | - knative-automation 61 | - knative-prow-releaser-robot 62 | - knative-prow-robot 63 | - knative-prow-updater-robot 64 | - knative-test-reporter-robot 65 | operations-reviewers: 66 | - aliok 67 | - houshengbo 68 | - matzew 69 | operations-wg-leads: 70 | - houshengbo 71 | operations-writers: 72 | - aliok 73 | - houshengbo 74 | - matzew 75 | productivity-leads: 76 | - cardil 77 | - upodroid 78 | productivity-reviewers: 79 | - evankanderson 80 | - mgencur 81 | productivity-wg-leads: 82 | - cardil 83 | - upodroid 84 | productivity-writers: 85 | - cardil 86 | - upodroid 87 | security-wg-leads: 88 | - davidhadas 89 | - evankanderson 90 | security-writers: 91 | - davidhadas 92 | - evankanderson 93 | serving-approvers: 94 | - dsimansk 95 | - skonto 96 | serving-reviewers: 97 | - skonto 98 | serving-triage: 99 | - skonto 100 | serving-wg-leads: 101 | - dprotaso 102 | serving-writers: 103 | - dprotaso 104 | - dsimansk 105 | - skonto 106 | steering-committee: 107 | - aliok 108 | - arsenetar 109 | - dprotaso 110 | - evankanderson 111 | - matzew 112 | ux-approvers: 113 | - prajjwalyd 114 | ux-wg-leads: 115 | - Leo6Leo 116 | - cali0707 117 | - mmejia02 118 | - zainabhusain227 119 | ux-writers: 120 | - Leo6Leo 121 | - cali0707 122 | - mmejia02 123 | - prajjwalyd 124 | - zainabhusain227 125 | -------------------------------------------------------------------------------- /.github/workflows/bi-weekly-UX-WG-meeting-reminder.yaml: -------------------------------------------------------------------------------- 1 | # Copyright 2024 The Knative Authors. 2 | # 3 | # Licensed under the Apache License, Version 2.0 (the "License"); 4 | # you may not use this file except in compliance with the License. 5 | # You may obtain a copy of the License at 6 | # 7 | # http://www.apache.org/licenses/LICENSE-2.0 8 | # 9 | # Unless required by applicable law or agreed to in writing, software 10 | # distributed under the License is distributed on an "AS IS" BASIS, 11 | # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 12 | # See the License for the specific language governing permissions and 13 | # limitations under the License. 14 | 15 | name: "Bi-weekly UX WG meeting reminder" 16 | 17 | env: 18 | # The date of the first run of the action. It has to be set to a date that is on the same weekday as the cron. 19 | # Every second week of the bi-weekly cycle, the action is going to be skipped. 20 | # The cron time can be set to any time of the day. 21 | FIRST_RUN_DATE: 2025-01-14 22 | 23 | on: 24 | workflow_dispatch: 25 | schedule: ## At 2PM UTC on every other Tuesday (1 day before the meeting time, which is 2 PM UTC on every other Wednesday) 26 | - cron: 0 14 * * 2 27 | 28 | jobs: 29 | weekindex: 30 | runs-on: ubuntu-latest 31 | outputs: 32 | weekindex: ${{ steps.calculate.outputs.weekindex }} 33 | steps: 34 | - name: Calculate weekdiff 35 | id: calculate 36 | run: | 37 | current_date=$(date +%Y-%m-%d) 38 | start=$(date -d ${{ env.FIRST_RUN_DATE }} +%s) 39 | end=$(date -d $current_date +%s) 40 | weekdiff=$(((end-start) / 60 / 60 / 24 / 7)) 41 | weekindex=$((weekdiff % 2)) 42 | echo "weekindex=$weekindex" >> "$GITHUB_OUTPUT" 43 | echo "FIRST_RUN_DATE: ${{ env.FIRST_RUN_DATE }}" >> $GITHUB_STEP_SUMMARY 44 | echo "current_date: $current_date" >> $GITHUB_STEP_SUMMARY 45 | echo "weekdiff: $weekdiff" >> $GITHUB_STEP_SUMMARY 46 | echo "weekindex: $weekindex" >> $GITHUB_STEP_SUMMARY 47 | if [ $weekindex -eq 0 ]; then 48 | echo "🟢 It's the first week of the bi-weekly cycle. The action is going to run." >> $GITHUB_STEP_SUMMARY 49 | else 50 | echo "🔴 It's the second week of the bi-weekly cycle. The action is going to be skipped." >> $GITHUB_STEP_SUMMARY 51 | fi 52 | remind: 53 | name: biweekly-ux-wg-meeting-reminder 54 | needs: weekindex 55 | if: ${{ needs.weekindex.outputs.weekindex == 0 }} 56 | runs-on: "ubuntu-latest" 57 | steps: 58 | - name: Post reminder to Slack 59 | uses: rtCamp/action-slack-notify@v2.2.1 60 | env: 61 | SLACK_ICON: http://github.com/knative.png?size=48 62 | SLACK_USERNAME: github-actions 63 | SLACK_TITLE: Bi-weekly UX WG meeting reminder 64 | SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} 65 | MSG_MINIMAL: "true" 66 | SLACK_CHANNEL: "knative-ux" 67 | SLACK_MESSAGE: The bi-weekly UX WG meeting will be happening tomorrow at this time (in 24 hours). You can join the [zoom meeting](https://zoom.us/j/98769530546), and add your agenda items to the [meeting notes](https://docs.google.com/document/d/1VCObP1IQFPDGzGG5KIgytQwX7RrU0tyeB7FGjkY0pPk/edit#heading=h.j4qyv6ihneq3) 68 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## User Experience (UX) 2 | 3 | User Experience concerns across Knative components 4 | 5 | Note: we are currently starting a new collaborative initiative to make designers feel more welcome in Knative! If you are interested in learning more or in participating, we would 6 | love to talk to you in [#knative-ux](https://cloud-native.slack.com/messages/knative-ux). 7 | 8 | | Artifact | Link | 9 | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | 10 | | Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) | 11 | | Community Meeting VC | See the top of the [Meeting notes](https://docs.google.com/document/d/1VCObP1IQFPDGzGG5KIgytQwX7RrU0tyeB7FGjkY0pPk/edit) | 12 | | Community Meeting Calendar | Every other Thursday from 9:00-10:00am ET
[Calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com) | 13 | | Meeting Notes | [Notes](https://docs.google.com/document/d/1VCObP1IQFPDGzGG5KIgytQwX7RrU0tyeB7FGjkY0pPk/edit) | 14 | | Roadmap | [Roadmap](https://github.com/orgs/knative/projects/71) | 15 | | Document Folder | [Folder](https://drive.google.com/drive/folders/1XzZGqV7yHo38d_l7rH1uSIrbQp3JlbBP?usp=sharing) | 16 | | Slack Channel | [#knative-ux](https://cloud-native.slack.com/messages/knative-ux) (need to join [CNCF Slack](https://communityinviter.com/apps/cloud-native/cncf) for the first time) | 17 | | Github Repository | [/ux](https://github.com/knative/ux) | | 18 | | Github Team WG leads | [@knative/ux-wg-leads](https://github.com/orgs/knative/teams/ux-wg-leads/members) | 19 | 20 | |   | Leads | Company | Profile | Role | 21 | | -------------------------------------------------------------------- | ---------------- | ---------------- | -------------------------------------------------------- | --------------- | 22 | | | Calum Murray | Red Hat | [cali0707](https://github.com/cali0707) | Product Lead | 23 | | | Zainab Husain | OCAD University | [zainabhusain227](https://github.com/zainabhusain227) | Design Lead | 24 | | | Mariana Mejia | OCAD University | [mmejia02](https://github.com/mmejia02) | Design Lead | 25 | | | Leo Li | Red Hat | [Leo6Leo](https://github.com/Leo6Leo) | Tech Lead | 26 | 27 | ## Contributing 28 | 29 | If you are interested in contributing to Knative generally, take a look at [CLOTRIBUTOR](https://clotributor.dev/search?project=knative&page=1) 30 | for a list of help wanted issues across the project. If you are more specifically interested in UX contributions, please 31 | come to our next meeting or talk to us on slack! 32 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing guidelines 2 | 3 | Welcome to the Knative UX Working Group (WG)! If you're interested in contributing the User Experience of Knative, you're in the right place! This document 4 | holds information about some of the types of contributions you can make, as well as how to make them. 5 | 6 | For more general Knative contributing guidelines, please refer to Knative's overall 7 | [contribution guidelines](https://www.knative.dev/docs/community/contributing/) to 8 | find out how you can help. 9 | 10 | ## Meetings 11 | 12 | Perhaps the best way to get started with the UX WG is to start attending our bi-weekly meetings. The meetings are every other week from 9Am to 10AM ET on Thursday. The 13 | specific weeks they occur on can be seen on the [Knative community calendar](https://calendar.google.com/calendar/embed?src=knative.team_9q83bg07qs5b9rrslp5jor4l6s%40group.calendar.google.com). 14 | The meeting notes (past, as well as the agenda for the next meeting) can be found [in this google doc](https://docs.google.com/document/d/1VCObP1IQFPDGzGG5KIgytQwX7RrU0tyeB7FGjkY0pPk/edit?usp=sharing). 15 | The zoom link and password are also at the top of this document. We hope to see you at the next meeting! 16 | 17 | There are occasionally other "work session" meetings where some of the designers in the group will hop on a call and work together on an issue. These are arranged in a more ad-hoc manner, 18 | but you can find out all the details about them in [#knative-ux](https://cloud-native.slack.com/archives/C05MW1AT1T8) on the CNCF slack. You will need to [join CNCF slack](https://communityinviter.com/apps/cloud-native/cncf). 19 | 20 | ## Finding something to work on 21 | 22 | In open source, pieces of work are generally termed "issues", so to remain consistent with the rest of Knative and other OSS projects, we use that term as well. 23 | You can find all of the open issues for Knative UX in the [issues tab in the UX repository](https://github.com/knative/ux/issues). These issues are labelled by kind, for example 24 | issues labelled `kind/website` have to do with the design of the website. 25 | 26 | When you find an issue which you are interested in, comment `/assign` and a bot will assign the issue to you! Feel free to ask any questions you have either on the GitHub issue or 27 | in the [#knative-ux](https://cloud-native.slack.com/archives/C05MW1AT1T8) slack channel. We are here to help you! 28 | 29 | Examples of current issues being worked on include: website color scheme redesign, user survey design and analysis, and other user research methods such as card sorting. 30 | 31 | ## Designer - developer handoff 32 | 33 | Often, the issues being worked on will need a developer to actually program the changes. In these cases, it is up to you to open an issue on the appropriate GitHub repository 34 | detailing the change that needs to be made, after the designs you made have been approved. To understand this process better, let's walk through what your workflow would look 35 | like if you wanted to work on an issue titled "re-design website buttons". 36 | 1. First, you would assign the issue to yourself by commenting `/assign` on the issue 37 | 2. Next, you would work on an initial draft of the design. 38 | 3. Once you have a design you are happy with or that you want feedback on, you will open a Pull Request to this repository with the artifacts included. 39 | 4. The design leads or other contributors in the working group will leave feedback on the design, and possible ask you to make some changes. 40 | 5. At the bi-weekly working group meeting, everyone at the meeting will work together to make a final decision on the design. If the group agrees on the changes, it will be merged into the repo. 41 | 6. Now, you can go to the repository for the website (knative/docs), and open an issue with the final design asking someone to update the buttons accordingly. If your 42 | change is not for the website and you are not sure which repository it should go to, please ask the WG tech lead for help. 43 | -------------------------------------------------------------------------------- /user-research/contributor-research/Introduction.md: -------------------------------------------------------------------------------- 1 | ## Abstract: 2 | Knative is a vital tool in the open-source and cloud-native ecosystem, enabling the development of enterprise-level serverless and event-driven applications. However, understanding why some individuals sustain active involvement in Knative while others contribute sporadically or disengage entirely remains a challenge. This research seeks to address this gap by investigating factors influencing contributor retention within the Knative community. By exploring contributors' motivations, experiences, and challenges, the aim is to identify areas for improvement in the contributor experience. Through actionable recommendations, we aspire to enhance contributor retention and foster a more sustainable ecosystem within Knative. This research has the potential to significantly impact the Knative community by providing practical insights and strategies to strengthen community engagement and collaboration. 3 | 4 | ## Goals: 5 | - Understand the current contributor journey within Knative. 6 | - Identify factors that contribute to contributors staying or leaving the Knative community. 7 | - Highlight areas of the contributor experience that can be improved to increase contributor retention and propose ways to improve those areas. 8 | 9 | ## Objectives: 10 | - Gather insights into the onboarding process for new contributors to Knative. 11 | - Explore the experiences of both retained and departed contributors. 12 | - Identify pain points and areas of dissatisfaction throughout the contributor journey. 13 | - Investigate the effectiveness of existing resources and documentation for contributors. 14 | - Determine potential interventions or improvements to enhance the contributor experience and retention rate. 15 | 16 | ## Key Questions: 17 | - What motivated contributors to join the Knative community initially and what were their expectations regarding their involvement in the projects? 18 | - What were the primary challenges they encountered during the onboarding process? (e.g. selecting the right project and right issues to contribute to as per one’s technical expertise) 19 | - How did contributors interact with the Knative community, and what were their experiences regarding communication and collaboration within the community 20 | - At what stage did certain contributors typically begin to disengage from the community? 21 | - What factors lead contributors to discontinue their engagement with Knative, and what practical recommendations do they offer to enhance the contributor experience, fostering a more sustainable and active ecosystem? 22 | - Are there any differences in experiences between contributors with varying levels of technical expertise or backgrounds? 23 | - What is missing in the current contributor experience of Knative as compared to some other well-established open-source projects? 24 | 25 | ## Hypotheses: 26 | - Contributors who have a positive onboarding experience, are proactive, and receive clear guidance and support, are more likely to stay engaged with the Knative community. 27 | - Factors such as perceived value of contributions, prospective future opportunities, and alignment with personal or professional goals influence contributors' decisions to remain active in the project. 28 | - Contributors may disengage due to challenges like unclear contribution processes, technical knowledge/expertise barriers, insufficient/delayed feedback, lack of recognition, community integration issues, etc. Additionally, heavy workloads, limited free time, personal commitments, or simply a change of plans may also contribute to disengagement. 29 | 30 | ## Methods: 31 | - Data-driven Sampling 32 | - Surveys 33 | - 1 on 1 interviews 34 | - Focus Groups 35 | - Comparative Analysis 36 | 37 | **Additional Methods:** 38 | - Conducting a thorough literature review to extract valuable insights from prior open-source research works. 39 | - Reviewing the onboarding processes and documentation based on findings from survey & interview results to identify areas for enhancement. 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /user-research/contributor-research/README.md: -------------------------------------------------------------------------------- 1 | # Knative Contributor Research 2024 2 | 3 | This directory contains the files and resources related to the project - [Knative: Contributor Journey Research](https://mentorship.lfx.linuxfoundation.org/project/54afaf17-4dc9-4783-9641-a95b5a33af9e). This project was undertaken by [Prajjwal Yadav](https://github.com/prajjwalyd) as an LFX mentee during the Spring 2024 term under the guidance of [Mariana Mejía](https://github.com/mmejia02) and [Calum Murray](https://github.com/Cali0707). 4 | 5 | The project aims to identify challenges in the current contributor journey and understand the reasons behind sustained engagement and disengagement within the Knative community. The main goal is to suggest actionable recommendations to improve the overall developer experience in Knative, encouraging long-term engagement. 6 | 7 | **For more information about this project, please read [Introduction.md](Introduction.md). 8 | The key findings of this research can be found [here](Key-Findings.md). 9 | The suggested actionable recommendations based on the key findings can be found [here](Recommendations.md).** 10 | 11 | ## Table of Contents 12 | 13 | 1. [Methods Used](#methods-used) 14 | 2. [Demographics](#demographics) 15 | 3. [Limitations and Future Work](#limitations-and-future-work) 16 | 4. [Research Resources](#research-resources) 17 | 5. [Bibliography](#bibliography) 18 | 6. [Closing Thoughts](#closing-thoughts) 19 | 20 | 21 | 22 | ## Methods Used 23 | 24 | To generate this report, we employed a variety of methodologies, most of which were successful. 25 | 26 | The main methods used were: 27 | 28 | - **Data-driven Sampling**: We employed a data-driven approach to identify a potential user sample based on Knative's contribution data. The primary data source was the [contributors.json](https://github.com/aliok/knative-contrib-report/blob/main/250-build-contributor-list/contributors.json) file. From this file, we extracted the study sample and performed further classifications. 29 | - **1-on-1 Interviews**: A total of 12 individual interviews, each approximately 30 minutes long, were conducted with current and past members of the Knative community. These interviews included active contributors, new contributors, maintainers, and inactive contributors. The qualitative data from these interviews was analyzed using the affinity mapping technique to identify common themes and insights. Additionally, some tree diagrams were utilized for root cause analysis to further understand the underlying issues. 30 | - **Comparative Analysis**: We identified some successful strategies employed by other open-source projects to improve developer experience and contributor retention. Specific examples are included in the [Recommendations.md](Recommendations.md) file. 31 | - **Onboarding Review**: Contributor onboarding and its associated challenges were a central focus of this research. We effectively identified key areas of concern ([Onboarding Difficulties](Key-Findings.md#onboarding-difficulties)) within the current contributor journey through interviews and provided actionable recommendations based on these findings ([Improving the Onboarding Process](Recommendations.md#improving-the-onboarding-process)). 32 | - **Literature Review**: Although not the primary method, we did read some existing literature on open-source community engagement and participation. The goal was to learn from these studies to better plan our research. 33 | - **Surveys**: A developer survey was designed for the Knative community to explore motivations, engagement, challenges, and potential improvements. However, this methodology was not very successful or statistically significant, with only four individual responses (as of May 28, 2024). This survey can still serve as a reference for future efforts in the community. 34 | - **Focus Groups**: This methodology was initially planned but could not be implemented due to time constraints. 35 | 36 | 37 | ## Demographics 38 | 39 | The primary data source of this research was the 12 interviews that were conducted within the Knative community. These interviews included active contributors, new contributors, maintainers, and inactive contributors. We analyzed contributor data from January 1, 2023, to February 29, 2024, and categorized each contributor based on their frequency of contributions: 40 | 41 | - **New Contributors**: Contributors who made their first contribution in the last couple of months. 42 | - **Active Contributors**: Contributors with at least one contribution each month. 43 | - **Inactive Contributors**: Contributors with no contributions in the last couple of months. 44 | - **Maintainers**: Individuals responsible for maintaining code in the Knative repositories. 45 | 46 | This categorization was based on analyzing the GitHub contribution graphs of each individual contributor. 47 | 48 | From this contributor data (from January 1, 2024, to February 29, 2024), we identified prospective participants from each of the four categories and approached them on Slack to schedule one-on-one interviews. 49 | 50 | > When examining data from January 1, 2023, to December 31, 2023, we found that a total of 120 contributors made their first commit in 2023, of whom 8 are still contributing actively. Although we do not have an exact retention rate to compare against, it is evident that there is room for improvement in contributor retention. 51 | 52 | Since the Participants varied in their experience levels, current roles, and levels of engagement with the project, here is some rough demographic data presented in table form: 53 | 54 | | **Category** | **Number of Participants** (out of 12) | 55 | |--------------------------------------|---------------------------------------| 56 | | **Experience Levels** | | 57 | | Students/Entry Level | 4 | 58 | | Junior Professionals | 5 | 59 | | Senior Professionals | 3 | 60 | | **Education and Work Status** | | 61 | | Full-Time Students* | 7 | 62 | | Full-Time/Part-Time on Knative | 4 | 63 | | Full-Time/Part-Time 'Not' on Knative | 1 | 64 | | **Contributor Categories** | | 65 | | Maintainers | 4 | 66 | | Active Contributors | 3 | 67 | | New Contributors | 2 | 68 | | Inactive Contributors | 3 | 69 | | **Duration of current (or past) involvement in Knative****| | 70 | | Less than 6 months | 5 | 71 | | 6 to 12 months | 5 | 72 | | More than 12 months | 2 | 73 | 74 | `*` Some full-time students indicated that they were also working while studying. 75 | 76 | `**` Duration of involvement at time of the interview. 77 | 78 | ![A pie chart showing the distribution of experience levels within the 12 participants. The largest segment, representing Early-Career individuals, comprises 41.7% of the group. The next largest segment, Student/Entry-Level, makes up 33.3%, followed by Senior Professionals at 25.0%.](assets/exp-levels-chart.png) 79 | ![A bar graph showing the education and work status of 12 participants reveals that the majority, 7 out of 12, are full-time students. The remaining participants are divided among those working full-time or part-time on Knative (4 participants) and those working full-time or part-time not on Knative (1 participant).](assets/education-work-chart.png) 80 | ![A pie chart showing the distribution of contributor categories within the 12 participants, with Maintainers being the largest group (33.3%), followed by Inactive Contributors and Active Contributors (both 25.0%), and lastly New Contributors (16.7%).](assets/contributor-category-chart.png) 81 | ![A line graph showing the duration of involvement in Knative for the 12 participants. The graph shows that 5 participants have been involved for less than 6 months, another 5 for 6-12 months, and 2 for more than 12 months.](assets/duration-of-involvement-chart.png) 82 | 83 | 84 | 85 | ## Limitations and Future Work 86 | 87 | This work was completed within the 12-week timeframe of the LFX mentorship program, which imposed obvious time constraints. Additionally, there was a lack of participation in the developer survey, which limited the breadth of quantitative data. Despite these challenges, we successfully conducted 12 interviews with a diverse group of candidates, forming the backbone of this research. 88 | 89 | ### Limitations 90 | 91 | - **Time Constraints**: The 12-week period was insufficient to explore all potential methodologies and data sources fully. 92 | - **Survey Participation**: The developer survey had very low participation, which limited its statistical significance. 93 | - **Contributor Categorization**: Our categorization of contributors was based solely on quantitative data (number of GitHub contributions). This approach did not account for other types of participation, such as interactions on Slack, attending meetings, providing feedback, and more. However, our interview questions did cover aspects of community involvement and interactions. 94 | - **Data Analysis**: The qualitative interview data was analyzed using affinity mapping and root cause analysis. While these methods were effective, we believe that some further analysis of the extensive interview data could potentially yield additional insights and recommendations. 95 | 96 | 97 | > The key findings of this research emerged from the themes identified during our analysis. For each theme, we crafted specific, actionable recommendations that are practical and feasible within our organizational context. These recommendations are prioritized in descending order of implementation priority based on our findings. 98 | 99 | ### Future Work 100 | 101 | - **Implementation and Evaluation**: The next step is to implement the actionable recommendations and evaluate their effectiveness. This iterative process may involve trials and errors to determine what works best. 102 | - **Further Research**: Conduct follow-up research after a sufficient time interval post-implementation of the recommendations to evaluate their effectiveness and impact on the overall developer experience. 103 | - **Data Collection**: Future efforts should aim to gather data from diverse sources, including increased survey participation, focus groups, and more. 104 | 105 | > Despite the mentioned limitations, the data collected from the interviews was substantial and diverse. Notably, connecting with three inactive contributors provided valuable insights. The next phase will focus on implementing the recommendations and assessing their success in improving the developer experience within the Knative community! 106 | 107 | 108 | ## Research Resources 109 | - [contributors.json](https://github.com/aliok/knative-contrib-report/blob/main/250-build-contributor-list/contributors.json) 110 | - [Interview Questions](https://docs.google.com/document/d/16uqV_zltMGxsveRPMImqM4oeBREW87ZeRU3Jz1zveto/edit?usp=sharing) 111 | - [Interview Data Analysis](https://www.figma.com/board/hSn9w3RyxMzuG8207WEiKY/Untitled?t=n5Ui1Ycw0zvm9riO-1) 112 | - [Knative Developer Survey](https://forms.gle/JHPhbYtWBWoLwmHs6) 113 | 114 | ## Bibliography 115 | *Note: The literature review was not the primary methodology but provided valuable context and background to inform the research design.* 116 | 117 | - **What brings you to open source?** *Author: Sophia Vargas, Researcher, Open Source Programs Office Google* 118 | - **Why do People Give Up FLOSSing? A Study of 119 | Contributor Disengagement in Open Source.** *Author: Courtney Miller (New College of Florida, USA), David Widder (Carnegie Mellon University, USA), Christian Kastner (Carnegie Mellon University, USA), and Bogdan Vasilescu (Carnegie Mellon University, USA)* 120 | - **Are You Still Working on This? An Empirical Study on Pull Request Abandonment** 121 | *Author: Zhixing Li, Yue Yu, Tao Wang, Gang Yin, ShanShan Li, and Huaimin Wang* 122 | - **Beyond the Repository** *Author: AMANDA CASARI, JULIA FERRAIOLI, AND JUNIPER LOVATO* 123 | 124 | ## Closing Thoughts 125 | 126 | 127 | This research successfully identified key challenges in the current Knative contributor experience, along with some maintainer-specific challenges. The recommendations provided aim to simplify and enhance the experience for everyone involved in the Knative community, with the hope of fostering significant improvements. 128 | 129 | We started this project with the **goals** of understanding the current contributor journey (please refer [Introduction.md](Introduction.md)), identifying factors that influence contributors' decisions to stay or leave, and highlighting areas for improvement. Through our research, we achieved these goals by studying the existing journey, pinpointing key disengagement factors, and proposing actionable recommendations to enhance retention. 130 | 131 | Additionally, our **objectives**—gathering insights into the onboarding process, exploring the experiences of both retained and departed contributors, identifying pain points, investigating the effectiveness of existing resources, and determining potential interventions—were all met. The key questions driving this research were answered through the key findings, each mapped to specific questions. 132 | 133 | #### Regarding the hypotheses: 134 | 135 | 1. **Positive Onboarding Experience**: 136 | - **Hypothesis**: Contributors who have a positive onboarding experience, are proactive, and receive clear guidance and support are more likely to stay engaged with the Knative community. 137 | - **Findings**: Evidence from interviews showed that proactive contributors who asked questions and received prompt support had better onboarding experiences. For example, one active contributor mentioned how a maintainer's helpfulness and clear explanations greatly supported their early contributions. Another contributor emphasized their persistence and use of some specific documentation sent by a maintainer to overcome initial challenges, highlighting the importance of proactive engagement. 138 | 139 | 2. **Perceived Value and Future Opportunities**: 140 | - **Hypothesis**: Factors such as perceived value of contributions, prospective future opportunities, and alignment with personal or professional goals influence contributors' decisions to remain active in the project. 141 | - **Findings**: Contributors expressed that their continued engagement depended on seeing tangible benefits and alignment with their goals. One past contributor mentioned that knowing about potential opportunities for advancement, such as becoming a maintainer, would have encouraged them to stay longer. Another past contributor noted that they would remain active if their work in Knative aligned with their professional needs or personal benefits. 142 | 143 | 3. **Challenges Leading to Disengagement**: 144 | - **Hypothesis**: Contributors may disengage due to challenges like unclear contribution processes, technical knowledge barriers, insufficient or delayed feedback, lack of recognition, community integration issues, and personal factors such as heavy workloads or limited free time. 145 | - **Findings**: The primary reasons for disengagement included time constraints due to jobs or studies and the complexity of navigating Knative's contribution processes. Interviews revealed that some contributors struggled with the technical complexity and found initial contributions challenging. Concerns about insufficient recognition and the unpaid nature of open-source contributions were also highlighted. For instance, one felt that beyond a 'thank you' from maintainers, there were few tangible rewards for contributors' efforts, affecting their motivation to stay engaged. *However, issues related to insufficient feedback and community integration were not mentioned in the interviews.* 146 | 147 | In conclusion, as we embark on the journey to enhance the Knative developer experience, I am reminded of the words of Helen Keller: "Alone we can do so little; together we can do so much..." During my time working on this project, I realized that each contributor, whether new, active, or inactive, forms a vital part of the Knative ecosystem, and every individual’s contributions and experiences are valuable, no matter how big or small they are. Each person's unique input adds to the richness of the community and helps drive the project forward! 148 | Therefore, I truly believe that by addressing the challenges identified in this research and implementing the actionable recommendations, we can not only improve the developer experience for all but also strengthen the bonds that tie us together as a community! 149 | 150 | Thank you to all who have contributed to this research and to my mentors who supported me throughout and played an important role in this effort. -------------------------------------------------------------------------------- /user-research/contributor-research/Key-Findings.md: -------------------------------------------------------------------------------- 1 | # Key Findings 2 | 3 | In our investigation of the Knative contributor experience, we explored the motivations behind contributions and the factors influencing sustained participation. 4 | We found that individuals are drawn to Knative to learn, collaborate, and gain hands-on experience with cutting-edge technologies, enhancing their skills and knowledge. However, challenges such as the initial learning curve, assumptions of background knowledge, and a scarcity of beginner-friendly tasks and documentation can hinder sustained contributions. While the Knative community is known for its welcoming and supportive nature, some contributors discontinue their involvement due to various personal and specific reasons (discussed below). 5 | These findings should help us understand how to make contributing to Knative better for everyone involved! 6 | 7 | ## Table of Contents 8 | 9 | 1. [Primary Challenges Faced by Contributors](#primary-challenges-faced-by-contributors) 10 | 2. [Motivations Behind Contributing to Knative](#motivations-behind-contributing-to-knative) 11 | 3. [Primary Challenges Faced by Maintainers](#primary-challenges-faced-by-maintainers) 12 | 4. [Community Engagement and Interactions](#community-engagement-and-interactions) 13 | 5. [Reasons for Disengagement](#reasons-for-disengagement) 14 | 6. [Some Additional Insights](#some-additional-insights) 15 | 16 | 17 | 18 | ## Primary Challenges Faced by Contributors 19 | 20 | ![A diagram summarizing the challenges faced by contributors, categorized into three main areas: issues and task selection, onboarding difficulties, and additional challenges like demotivation and lack of engagement.](assets/contributor-challenges.png) 21 | 22 | - ### Onboarding Difficulties 23 | - **Complexity of Tools:** Many contributors struggle with understanding and using Docker and Kubernetes. One noted, *"Understanding how Docker works and why Docker is necessary. And also what Kubernetes is, I think those would be really helpful when someone's trying to set it up and start contributing."* 24 | - **Lack of Clear Starting Points**: Many contributors find it difficult to know where to begin. One mentioned, *"When I first assigned myself to a ticket, I just didn't have any idea about how to proceed with it."* 25 | - **Specific Documentation**: Some existing documentation is not very detailed, and some contributors specifically pointed out the absence of clear setup instructions for Mac M1 and WSL. Also, some expressed a strong need for more comprehensive resources, such as tutorials and clearer documentation, to assist them in navigating the project setup process and becoming familiar with its various components and workflows. 26 | - **Intimidation**: The sheer size and complexity of the codebase can be intimidating. One contributor stated, *"Knative is like a super huge project... So I was really overwhelmed at the beginning when I started contributing."* 27 | - **Assumed Background Knowledge**: Onboarding materials often assume a high level of prior technological knowledge. As one maintainer pointed out, *"It assumes that you have a lot of background in technology."* 28 | - **Difficulty Finding Information**: Contributors struggle to find relevant information, especially regarding specific repositories and topics. One said, *"Narrowing down which part should I focus on... is the most difficult part."* 29 | - **Complex Terminologies**: The language used in Knative documentation can be challenging to understand. A contributor mentioned, *"The language was kind of complex for me to understand what these particular terms are referring to."* 30 | 31 | 32 | - ### Issue & Task Selection 33 | - **Seeking Guidance for Issue Selection**: Contributors often have to seek advice from experienced members to find suitable issues: *"I ask for advice. So I would ask Calum and Leo for advice about what issues are more suitable for first issues or for new contributors."* 34 | - **Scarcity of Good First Issues**: Many contributors find that the issues labeled as "good first issue" are very less and quickly claimed, leaving them with fewer options: *"But when I was picking the tickets, all the ones that were labeled as first issue were all taken."* 35 | - **Complexity of Multi-repository Issues**: Some issues labeled as "good first issue" require knowledge of multiple repositories, which can be challenging for beginners: *"One single issue that is even marked as good first, it requires you to know how those repos work together."* 36 | 37 | - ### Some Other Challenges 38 | - **Demotivation:** The initial complexity and lack of understanding can lead to demotivation. One contributor expressed, *"I felt the most demotivated to keep doing this when I didn't know where to start or where to get help."* 39 | - **Lack of Direct Engagement**: Contributors express a desire for direct interaction with maintainers. They suggested something like Office Hours or One-on-One Mentorship opportunities that could provide them valuable guidance and support, helping them overcome barriers to entry and navigate the project more effectively. 40 | - **Balancing Commitments:** Contributors who are students or have full-time jobs find it challenging to balance their commitments with contributing to Knative. One contributor mentioned, *"I'm also balancing full-time university undergraduate at the same time, so I can't commit too many hours per week to Knative."* 41 | 42 | This section specifically addresses the second Key Question of the research, which is centered around the challenges encountered during the onboarding process. 43 | 44 | 45 | ## Motivations Behind Contributing to Knative 46 | 47 | We identified contributor motivations to understand why individuals remain interested in contributing to Knative despite the above outlined challenges. These insights are pivotal for crafting recommendations aimed at enhancing the contributor experience, as they furnish us with a foundational understanding of the prevailing motivations. 48 | 49 | ![A diagram outlining the motivations behind contributing, including learning and skill development, networking and collaboration, immediate needs, GSoC and LFX mentorship, and interest in advanced technology.](assets/motivations.png) 50 | 51 | - ### **Learning and Skill Development** 52 | - **Real-World Experience**: Many contributors are driven by the desire to learn new cloud-native technologies and many seek real-world application of their programming skills. One contributor noted, *"I feel like the main motivation is skill development because I never had much experience in software development."* 53 | - **Upskilling and Competitive Advantage** A maintainer said, *“One (contributor motivation) is, of course, just learning new technologies, people like to just check it out, see if it's something that can give them a competitive advantage either in their company or on their resume.”* 54 | 55 | - ### **Networking and Collaboration** 56 | - Contributing to Knative provides a platform to interact with professionals from prominent companies. A contributor highlighted this by saying, *"These opportunities to talk to Red Hat full-timers would never present itself outside of, you know, open source development."* 57 | 58 | - ### **Interest in Advanced Technology** 59 | - **Technological Appeal**: Contributors are drawn to Knative's modern technologies like serverless computing and event-driven architecture. 60 | - **Specific Interests**: Some contributors are intrigued by certain technical aspects based on their prior experience. For example, a contributor expressed, *"When I started, there was one issue about adding more tests in Knative. Since I was slightly familiar with how it works, I thought it might be a good idea to just add tests."* 61 | 62 | - ### **Immediate Needs** 63 | - **Company Needs**: Some contributors are driven by the immediate needs of their employers. One explained, *"Maybe the company is using Knative, and they want to get that feature in faster without waiting on the maintainer capacity."* 64 | - **Short-term Engagement**: Contributors with some specific goals (such as the one mentioned above) might only stay involved until their objectives are met. A maintainer shared, *"Their involvement is limited to that feature. After that, they disappear."* 65 | 66 | - ### **GSoC and LFX Mentorship:** 67 | - Several contributors discover Knative through programs like Google Summer of Code (GSoC) or the Linux Foundation Mentorship (LFX). 68 | 69 | - However, most of them disengage either after not being selected or once their project terms conclude. 70 | 71 | This section also provides an answer to the first Key Question of this research. 72 | 73 | ## Primary Challenges Faced by Maintainers 74 | 75 | Although it may seem slightly tangential, the primary purpose behind identifying the challenges encountered by maintainers is to acknowledge that they, too, operate as contributors at a fundamental level. Understanding their challenges allows us to enhance their experience, which, in turn, can positively impact contributor interactions. By addressing maintainers' challenges, they become better equipped to tackle issues faced by contributors. 76 | 77 | ![A diagram summarizing the challenges faced by maintainers, including contributor engagement and management, onboarding new contributors, identifying suitable tasks, and handling pull requests, while balancing their other responsibilities.](assets/maintainer-challenges.png) 78 | 79 | - ### **Contributor Engagement and Management** 80 | - Maintainers often struggle with inconsistent participation from contributors. Contributors may take on issues but then become unresponsive, leaving work incomplete. This stalls progress (especially if there is a timeline associated with a ticket) and creates uncertainty about how to proceed. One maintainer expressed this dilemma: *"Should I like make a PR to override their work … I don't want to do that... Or should I just do that myself? Or should I just wait forever?"* 81 | - Additionally, maintaining engagement over time is difficult. Contributors might resolve initial questions and then disappear, leading to a cycle where maintainers constantly invest time in onboarding new contributors without long-term returns. 82 | 83 | - ### **Onboarding New Contributors** 84 | - The onboarding process for new contributors is often challenging for maintainers due to the complexity of Knative and its technological stack. Contributors frequently struggle with setting up their development environments, understanding the codebase, and debugging their work: *"With enough like energy, like willingness to do that, you can kind of get some local setup that kind of works. But then like, learning about the all components and how all work is or working is complicated."* 85 | 86 | - ### **Pull Request (PR) Challenges** 87 | - Maintainers spend significant time helping contributors get their PRs merged, especially when these contributors lack sufficient understanding or have not thoroughly tested their code. This can be frustrating and time-consuming: *"Sometimes they'll open a pull request that doesn't really resolve it at all or doesn't compile, and then you have to help them figure out how to get their code to compile."* 88 | - Long-standing PRs can become problematic as they may require rebasing or run into conflicts, further delaying progress. 89 | 90 | - ### **Identifying, Creating, and Labelling Suitable Issues** 91 | - Maintainers acknowledge the difficulty in consistently identifying what makes a "good first issue": *"We don't really know what's a good first issue. Okay, in a sense that, as I said, different contributors are coming from different backgrounds."* 92 | - Creating and maintaining good first issues can be time-consuming for maintainers, making it difficult to keep a steady supply: *"It might take me five hours to flip that up with a whole bunch of small good first issues, and then it'll take me over 20 or 30 hours to coach people through pull requests for all those."* 93 | 94 | - ### **Balancing Responsibilities** 95 | - Maintainers face the challenge of balancing their own work with the needs of contributors. The frequent need to switch contexts between different tasks and issues adds to their workload: *"One user facing some challenges while like using eventing or like Knative as a whole, and one contributor is trying to get their PR merged or reviewed. And that is, that's the main challenge, ton of context switch."* 96 | 97 | This section contains insights aligned with the third and sixth Key Questions of this research. 98 | 99 | ## Community Engagement and Interactions 100 | 101 | ![A diagram outlining the community engagement and interactions: a welcoming and supportive environment, responsiveness and accessibility, and highlighting a preference for communication via Slack, DMs, and GitHub over meetings.](assets/community-engagement.png) 102 | 103 | - ### **Welcoming and Supportive Community** 104 | - Many contributors feel welcomed and supported by the Knative community. The maintainers and other community members are responsive and patient, creating an encouraging environment for both new and experienced contributors: *"I don't know how to say that, but like, I feel welcome."* 105 | - This sense of community is often cited as one of the most rewarding aspects of contributing: *"I think the most rewarding thing is the community that I'm able to join as part of my contribution journey."* 106 | 107 | - ### **Responsiveness and Accessibility** 108 | - Maintainers are generally quick to respond to queries, whether on Slack or through GitHub, which enhances the engagement and fosters a positive experience: *"One thing that I noted is that all of the maintainers that I contacted response really quickly, which is really convenient."* 109 | 110 | - ### **Preferred Mode of Communication** 111 | - Community meetings are less attended by contributors, particularly newer ones, who prefer to interact through Slack or GitHub. They feel hesitant to engage in meetings due to a lack of confidence or familiarity with the project: *"I still feel a little not confident enough to join that (meeting) maybe I because I didn't know that much about the work."* 112 | - One-on-one interactions are preferred by some as they find it less intimidating: *"Meeting one on one will be a little bit more helpful instead of having a lot of people talking to me."* 113 | 114 | Overall, the Knative community is rated very highly by contributors, who appreciate the quick and helpful responses from maintainers and the collaborative atmosphere: *"If I have to rate it 1 to 10, I would probably rate it 9"* 115 | 116 | This section addresses the third Key Question of this research. 117 | 118 | ## Reasons for Disengagement 119 | 120 | ![A diagram summarizing the reasons for disengagement, which include personal and professional priorities, technical challenges, lack of immediate rewards, need for mentorship and ongoing support, and challenges in sustaining long-term engagement and burnout.](assets/reasons-for-disengagement.png) 121 | 122 | - ### **Personal and Professional Priorities** 123 | 124 | - **Individual Needs:** Contributors often engage based on personal or professional needs. If Knative aligns with their daily workflow or company projects, they are more likely to contribute: 125 | *"I will contribute to Knative if I need Knative, like if I use Knative stuff in my daily workflow, or in my company."* 126 | - **Time Commitment:** As students, contributors often face time constraints due to academic and professional responsibilities, which can lead to reduced engagement. 127 | *"During the school time, a lot of contributors are students... And, you know, like in the university, people are really busy, especially during the exam time or assignment due date." 128 | "I have to manage my college as well as the internship that I'm doing and Knative as well."* 129 | 130 | - **Transition to Work:** After graduating, contributors might prioritize their jobs over open source contributions unless their job involves using Knative. 131 | *"After the student phase, when we start working, it's mostly about individual needs."* 132 | 133 | 134 | - ### **Technical Challenges** 135 | 136 | - **Understanding the Codebase:** Many contributors struggle with the technical complexity of the issues, particularly if they lack sufficient knowledge of the codebase or have difficulty setting it up locally. 137 | *"After they take on the issue and they cannot understand what they're asking to do, or they cannot understand the code base, they feel discouraged."* 138 | *"How do I implement that feature, ... and where I modify the code, that's the part that is not super clear."* 139 | 140 | - **Multi-repository Knowledge:** Some issues require understanding multiple repositories, which can be overwhelming for new contributors. 141 | 142 | 143 | - ### **Lack of Immediate Rewards** 144 | 145 | - **Recognition and Rewards:** Contributors might feel unappreciated or insufficiently rewarded for their efforts, leading to disengagement. 146 | 147 | - **Financial Incentives:** The lack of financial compensation can deter long-term commitment, especially when setting up the development environment and understanding the system can be time-consuming. 148 | *"You're not getting paid... So most people do not have the luxury of being able to sit down for the multiple days that it takes."* 149 | 150 | 151 | - ### **Mentorship and Ongoing Support** 152 | 153 | - **Post-Mentorship Drop-off:** Many contributors who join through programs like LFX mentorship do not continue contributing after the mentorship ends due to changing priorities and commitments. 154 | - **Need for Continued Support:** Contributors, including mentees, often require ongoing guidance to sustain their involvement beyond their initial engagement or project completion. 155 | Without continued guidance, contributors feel that their task completion marks the end of their contribution journey, leading to disengagement. 156 | *"There is no clear follow-up to maybe their PR merged."* 157 | *"They finish merging their pull request and they stop contributing more. They probably think, okay, I have already finished one task. And they're probably where there's no point to continue to contributing"* 158 | 159 | 160 | - ### **Long-Term Engagement and Burnout** 161 | 162 | - **Challenges in Sustaining Engagement:** Contributors struggle to find motivation to continue after completing initial tasks, especially if subsequent tasks are more challenging. Sometimes, this also result in a **'good first issue loop'** where contributors only work on tasks marked as such. 163 | One maintainer mentioned, *"Some people never really take that next step to go beyond just a good first issue."* 164 | 165 | - **Maintainer Burnout:** Maintainers might feel overburdened by the need to continuously keep up their individual work, provide extensive guidance to contributors facing challenges, create and manage issues, review pull requests, etc. 166 | 167 | This section addresses the fourth and fifth Key Questions of this research. 168 | 169 | ## Some Additional Insights 170 | 171 | These insights and findings are grouped separately because they didn't neatly fit into the existing categories. They sparked our interest during the analysis and could potentially provide valuable additional perspectives or recommendations. 172 | 173 | ![A diagram outlining additional insights related to contributing to Knative, focusing on its perceived value and reputation, the impact of community and contributor retention, and the contribution types and expectations.](assets/additional-insights.png) 174 | 175 | - ### **Perceived Value and Reputation of Knative** 176 | 177 | - **Associations with Reputable Organizations:** Contributors appreciate Knative’s structured environment and its association with reputable organizations like Red Hat, Google, and CNCF: *"Knative is kind of a growing repository, growing project... previously owned by Google and then go to CNCF."* 178 | - **Engineering Excellence:** The project’s reputation for high-quality engineering attracts contributors who want to learn and grow in their careers: *"It has a good reputation in terms of engineering."* 179 | 180 | - ### **Community Impact and Contributor Retention** 181 | - **Confidence Building:** Contributors gain confidence through successful participation in programs like GSoC and LFX: *"The most important thing that I have gained is the confidence... you don't need to know many things or a lot of things to work in an organization that you can start from a very small thing and, you know, expand your knowledge from that. "* 182 | 183 | - **Positive Experiences:** Contributors who receive timely and helpful responses from the community are more likely to stay engaged: *"The maintainers are very supportive … if you have maintainers like that, then that's a really lucky thing to have."* 184 | 185 | - Poor experiences with other projects, such as lack of feedback or community engagement, can drive contributors to Knative, where they look to find a more responsive environment: *"I tried to contribute to ____ (_name removed_)… I even participated in their community meetings, but they just ignored me … So I gave up on them…"* 186 | 187 | 188 | - ### **Contribution Types and Expectations** 189 | 190 | - **Diverse Contribution Opportunities:** Encouraging diverse types of contributions, such as code reviews or documentation improvements, can keep contributors engaged: *"People might not realize the other types of contributions that would be very welcome... like helping review a pull request…"* 191 | 192 | - **Setting Realistic Expectations:** It's crucial to help contributors understand the time and effort required for meaningful contributions to prevent disengagement. Some face challenges with processes like EasyCLA, while others feel overwhelmed by the numerous comments they receive on their first pull request. Providing clear guidance and support in such similar areas initially can significantly improve their experience and retention. -------------------------------------------------------------------------------- /user-research/contributor-research/Recommendations.md: -------------------------------------------------------------------------------- 1 | # Recommendations 2 | 3 | Based on what we've learned from our research, we strongly suggest putting these recommendations into action. These recommendations aim to make things better for people who contribute to the Knative community. The main goal is to create a dynamic and participatory environment that encourages sustained engagement over time. 4 | The recommendations are based on the key findings and suggestions collected through the interviews. 5 | 6 | ![A diagram outlining various recommendations, including scheduled office hours, improving the onboarding process, enhancing issue labeling practices, personalized one-on-one meetings, monthly community hangout calls, revamping social media presence, implementing survey-style feedback mechanisms, and establishing clear growth paths in the community.](assets/recommendations.png) 7 | 8 | ## Table of Contents 9 | - [Improving the Onboarding Process](#improving-the-onboarding-process) 10 | - [Improving Issue Labeling Practices](#improving-issue-labeling-practices) 11 | - [Scheduled Office Hours](#scheduled-office-hours) 12 | - [Revamped Social Media Presence](#revamped-social-media-presence) 13 | - [Monthly Community Hangout Calls](#monthly-community-hangout-calls) 14 | - [Establishing Clear Growth Paths in the Community](#establishing-clear-growth-paths-in-the-community) 15 | - [Personalized One-on-One Meetings for New Contributors](#personalized-one-on-one-meetings-for-new-contributors) 16 | - [Anonymous Feedback Mechanism](#anonymous-feedback-mechanism) 17 | 18 | 19 | ## Improving the Onboarding Process 20 | 21 | - ### Establishing a Structured Onboarding Plan 22 | - This plan should include comprehensive introductory documentation, guides, tutorials, and links to all other necessary resources. This approach allows new contributors to seamlessly integrate themselves into the project with minimal friction. 23 | - Consolidating this plan into a centralized hub, such as a digital book or repository, would provide immense value for new contributors. Perhaps we can include this 'centralized resource' in the issue templates to make it easier to find, especially for newcomers. 24 | 25 | - ### Video tutorials & Visual Guides 26 | - Creating detailed video tutorials for setting up Knative projects on popular operating systems like Linux/WSL and macOS is essential for new contributors. 27 | - These tutorials would provide step-by-step instructions for installation and configuration, along with an overview of different components and directories. 28 | - Visual guides (diagrams, flowcharts, etc.) to simplify understanding and empower contributors to overcome initial hurdles more effectively. 29 | 30 | - ### Clear Communication of Expectations 31 | - PR Guidelines: Clearly communicate expectations for pull requests (PRs). This includes providing a detailed guide on the PR process, common review criteria, and typical feedback cycles. 32 | - By setting clear expectations upfront, new contributors will be better prepared for the collaborative nature of open-source contributions, reducing the likelihood of feeling overwhelmed by feedback on their initial submissions. 33 | 34 | 35 | #### Why is it needed? 36 | 37 | - **Reducing Initial Setup Frustration:** Many new contributors face significant challenges during the initial setup phase, which can lead to frustration and potentially abandoning the project. Comprehensive onboarding resources, including video tutorials and visual guides, provide a guided approach to help them navigate this phase confidently. 38 | 39 | - **Empowering New Contributors:** Beginner-friendly resources and documentation are particularly crucial for those new to Knative and cloud-native technologies like Docker and Kubernetes. Structured and accessible onboarding materials help these individuals to understand the project and make meaningful contributions without facing significant challenges. 40 | 41 | - **Sustaining Engagement:** Clear communication of PR expectations helps maintain contributor engagement by preparing them for the iterative feedback process, reducing frustration and encouraging continuous involvement. 42 | 43 | #### Implementation: 44 | 1. Establishing a Structured Onboarding Plan: 45 | - Content Creation: Create comprehensive documentation, guides, and tutorials covering all important aspects of the project. Review and update the existing material for each Knative component. 46 | - Centralized Hub: Develop a centralized accessible resource or digital book (something similar to the [Layer5 Community Handbook](https://layer5.io/community/handbook)) to consolidate all important community and onboarding materials. 47 | - Integration: Include links to the centralized resource in issue templates for easy access. Also, showcase this on knative.dev to increase visibility. 48 | - Quality Testing and Improvements: Regularly evaluate the onboarding plan with experienced community members and gather feedback from new contributors, using their insights and suggestions to enhance the process. 49 | 2. Comprehensive Video Tutorials: 50 | - Video Production: Produce detailed video tutorials for setting up Knative projects on popular operating systems. 51 | - Content Coverage: Ensure the tutorials cover installation, configuration, and an overview of project directories and components. 52 | - Distribution: Upload the videos to YouTube and embed them in relevant documentation. 53 | 3. Clear Communication of Expectations: 54 | - Guideline Creation: Develop clear guidelines for pull requests (PRs), including expectations, timeline, and iterative review processes. 55 | - Documentation: Document the PR process and expectations in the contributing guidelines. 56 | 57 | 58 | ## Improving Issue Labeling Practices 59 | 60 | - Actively identify and label more issues as 'good first issue' and 'help wanted'. This involves breaking down larger tasks into smaller, manageable chunks that are suitable for newcomers. 61 | - Enhance the clarity and descriptiveness of issue labels to provide more context about the issue's nature, priority, specific area of consideration, and complexity. 62 | - Develop a standardized process for labeling issues. This process should include guidelines on when and how to use each label. Maintainers and regular contributors are expected to follow this process to ensure consistency. 63 | 64 | #### **Why is it needed?** 65 | 66 | - **Ease of Entry for New Contributors:** Currently, new contributors often struggle to find appropriate entry-level issues, which can delay their engagement and lead to frustration. More 'good first issue' and 'help wanted' labels will provide a clear starting point, reducing the need for them to seek guidance from maintainers. 67 | - **Encouraging Independent Exploration:** By having more clearly labeled issues, new contributors can independently identify tasks they are comfortable working on, fostering a sense of autonomy and confidence. 68 | - **Attracting and Retaining Contributors:** An organized and beginner-friendly issue tracker can attract more contributors to the Knative community. It signals that the project is welcoming to newcomers and provides a supportive environment for learning and contributing. 69 | - **Efficiency for Maintainers:** Improved labeling practices help maintainers by reducing the number of inquiries from new contributors about where to start. Combined with organized onboarding, this enables maintainers to concentrate more on reviewing contributions and offering guidance on more complex issues. 70 | 71 | #### Implementation: 72 | - Label Identification: Identify and label more issues as 'good first issue' and 'help wanted'. This may include breaking down of bigger tasks into smaller manageable chunks suitable for beginners. 73 | - Label Description: Enhance the clarity and descriptiveness of issue labels to provide more context so that contributors get an idea of what they are dealing with. 74 | - Standardized Process: Develop a standardized process for labeling issues and train maintainers and contributors on its usage. Encourage every maintainer to create more beginner-friendly issues regularly to ensure a continuous supply. 75 | 76 | 77 | 78 | ## Scheduled Office Hours 79 | 80 | - Regular Sessions: Schedule weekly office hours at consistent times to provide a reliable opportunity for contributors to seek help. Ensure that these sessions are well-publicized and open to all contributors, seeking guidance and mentorship or facing challenges while contributing. 81 | - Diverse Mentorship: Rotate the hosts for these sessions among different maintainers and experienced contributors to provide diverse perspectives and expertise. This also helps distribute the mentoring load and gives attendees the chance to interact with various members of the community. 82 | 83 | #### **Why is it needed?** 84 | 85 | - **Comfortable Environment:** Some contributors may feel uncomfortable asking questions in public forums or Slack channels due to fear of judgment or just lack of confidence. Office hours provide a more supportive environment where they can seek help without hesitation. 86 | - **Immediate Support:** Real-time interaction during office hours allows contributors to get immediate feedback and solutions to their problems, reducing delays and enhancing productivity. 87 | - **Community Building:** Regular interactions through office hours foster a stronger sense of community and collaboration. Contributors get to know each other and build relationships, which can lead to more effective teamwork and knowledge sharing. 88 | - **Adoption by Other Projects:** Many successful open-source projects have adopted office hours as a best practice to enhance collaboration and support. 89 | 90 | #### Implementation: 91 | - Scheduling: Establish a regular schedule for weekly office hours at convenient times for contributors. 92 | - Duration: Start with a 30-minute weekly call and increase it over time if demand requires. 93 | - Promotion: Publicize the office hours through various channels such as Slack and social media. 94 | - Session Host: Have 1 or 2 maintainers present in a single session, rotating the hosting responsibilities every week to prevent anyone from feeling burdened. 95 | 96 | 97 | ## Revamped Social Media Presence 98 | - A more assertive social media strategy amplifies Knative's visibility and attracts a wider audience of potential contributors. 99 | - Focus on showcasing success stories, case studies, technical achievements, and upcoming events to capture the interest of developers and technologists who may not be familiar with the project. 100 | - Platforms to target: LinkedIn, YouTube, and X (Twitter) 101 | - ### Few More Suggestions: 102 | - Project Kick-off Meetings: Host live streams or recorded meetings for each major feature or release. These sessions can serve as both informative and promotional content, allowing the community to stay updated and engaged with ongoing developments. 103 | - Gamification of Contributions: Introduce gamification elements such as rankings, badges, certificates and even an ambassador program to recognize and reward active contributors. These elements can incentivize engagement and provide tangible acknowledgments of contributors' efforts, enhancing their professional profiles. Share these achievements across all social media platforms to reach potential new contributors (For example, we could use a system like [Nirmata Badges](https://www.credly.com/organizations/nirmata/badges) and include specific badges such as 'Knative Eventing Contributor', 'Knative Serving Contributor', etc. as per our requirements). 104 | - Podcasts: Launch a podcast series featuring fireside chats on different topics and personal stories from contributors about their journeys and experiences with Knative. Highlight diverse experiences and the career benefits of participating in open-source projects. These stories can inspire newcomers and demonstrate the impact of contributing to open source and Knative. Include guest speakers from the wider open source community (similar to [kubernetespodcast.com](https://kubernetespodcast.com/about/index.html)). 105 | 106 | #### **Why is it needed?** 107 | 108 | - **Increased Visibility:** A more assertive social media presence will raise awareness of Knative among potential contributors who might otherwise be unaware of the project. This proactive approach can help attract new talent and broaden the community. 109 | - **Engagement and Interest:** By creating high-quality, engaging content tailored for the developer community, Knative can generate more valuable interactions and sustained interest. Social media is a powerful tool for outreach, as evidenced by current contributors who discovered Knative through these channels. 110 | - **Community Building:** Podcasts, live streams, and gamification not only provide information but also build a sense of community and belonging. Recognizing contributors' efforts publicly can motivate ongoing participation and loyalty. 111 | - **Professional Development:** Highlighting personal stories and journeys would make new contributors aware of the individual journeys of many maintainers and active contributors. This might make them feel relatable and more confident, and they would also come to know about the benefits of participating in Knative as a noteworthy addition to their careers. 112 | 113 | #### Implementation: 114 | - Content Strategy Development: Develop a robust content strategy highlighting success stories, technical achievements, and upcoming events. Include tutorials and educational content to add value. Use a content calendar to plan posts, ensuring a consistent mix of articles, videos, and live streams. 115 | - Platform Selection and Optimization: Target platforms—LinkedIn, YouTube, and Twitter (X). Optimize profiles with up-to-date information and branding. On LinkedIn, engage with professional groups. On YouTube, organize content into playlists and upload regular videos and live streams. Use Twitter for quick and short updates to maximize reach. 116 | - Content Creation:Produce high-quality, platform-specific content. Create step-by-step video tutorials, contributor interviews/podcasts, and live streams for big updates. Write in-depth articles, community stories, and guides. Regularly post updates on milestones, use interactive content like polls, and visually engaging posts. 117 | - Promotion and Engagement: Increase the follower base and interaction through cross-promotion with other projects and influencers. Share content across all platforms and encourage contributors to do the same if they find it helpful. Actively participate in industry events and conferences, run interactive contests, challenges, and hackathons to foster engagement. 118 | - Gamification Implementation: Develop and integrate gamification elements such as badges, certificates, and rankings into the Knative contribution process. Use platforms like [Credly](https://info.credly.com/) for badge issuance and display these achievements prominently on social media. 119 | - Analytics and Improvement: Monitor and analyze social media performance regularly. Set KPIs such as follower growth, GitHub Stars, and engagement rates. Use platform analytics tools to track success. Adjust content strategy based on performance data to keep the approach dynamic. 120 | 121 | 122 | ## Monthly Community Hangout Calls 123 | - While formal working group meetings are essential for project progress, hangout calls offer a more relaxed setting for networking and socializing, fostering stronger community bonds. 124 | - Organize interactive activities such as trivia, Q&A sessions, and games. These activities can be both fun and educational, encouraging more relaxed and informal interactions. 125 | - These sessions provide an opportunity for individuals to share their experiences, tips, and tricks, enriching the community's collective knowledge base. 126 | 127 | #### **Why is it needed?** 128 | 129 | - **Fostering Community Bonds:** Interactive and informal activities are crucial for building a sense of community. They provide a space where contributors can get to know each other beyond the scope of their work, fostering a more supportive and collaborative environment. 130 | - **Enhancing Engagement:** Monthly hangouts can keep contributors engaged and motivated. By offering a variety of activities and discussions, these sessions can cater to different interests and needs, making the community more dynamic and inclusive. 131 | - **Encouraging Casual Interactions:** Formal meetings can sometimes be intimidating, especially for new contributors. Informal hangouts create a welcoming atmosphere where everyone feels comfortable participating and sharing their thoughts. 132 | - **Building Relationships:** Strong relationships within the community lead to better teamwork and collaboration. When contributors feel connected and valued, they are more likely to remain active and committed to the project! 133 | 134 | #### Implementation: 135 | 136 | - Scheduling: Set a regular schedule (e.g., the last Friday of every month) for consistency. Use community polls to choose the most convenient time for the majority of contributors across different time zones. 137 | - Promotion: Publicize the hangout sessions through multiple channels, including Slack, community forum, and social media, to ensure maximum participation. 138 | - Duration: The calls should be sufficiently long, at least one hour, to allow for meaningful interaction and a variety of activities. 139 | - Themed Activities: Each call can have a theme and pre-planned list of interactive activities. 140 | 141 | 142 | ## Establishing Clear Growth Paths in the Community 143 | 144 | - Structured Growth Framework: Review and showcase a clear, transparent framework outlining the various stages of contributor growth within the community. This framework should be accessible and should include milestones, criteria, and expectations for advancement. 145 | 146 | - Skills Development Tracks: Offer specialized tracks for different areas of contribution, such as coding, documentation, community management, and user experience. Each track should outline specific skills and knowledge areas to be developed at each stage of progression. 147 | - Personalized Development Plans: Encourage contributors to set personal goals aligned with their interests and aspirations within the community. Provide guidance and resources to help them achieve these goals, whether it's mastering a new technology, leading a project, or becoming a maintainer/mentor. 148 | - Recognition and Rewards: Recognize and celebrate contributors' achievements as they progress along their growth paths. 149 | 150 | 151 | #### **Why is it needed?** 152 | 153 | - **Motivating Contributors:** Clear growth paths provide contributors with a sense of purpose and direction, motivating them to actively participate and contribute to the community. When contributors see a clear path for advancement, they are more likely to invest their time and energy into their involvement. 154 | - **Guiding Development:** Structured growth frameworks help contributors identify areas for skill development and track their progress over time. This guidance ensures that contributors are continuously growing and evolving within the community. 155 | - **Building Long-Term Engagement:** By offering clear pathways for growth, the community can retain contributors over the long term. When contributors feel supported and valued, they are more likely to remain engaged and committed to the project. This will also distribute the load on current maintainers who are suffering from low retention rates. 156 | - **Attracting New Talent:** A well-defined growth framework can attract new contributors by showcasing opportunities for personal and professional development within the community. This can help expand the talent pool and bring fresh perspectives and ideas to the project, leading to the next phase of Knative with new maintainers and contributors. 157 | 158 | 159 | #### Implementation: 160 | - Update/Develop Framework: Define milestones and criteria for contributor growth within the community to motivate new contributors. 161 | - Offer Tracks: Identify key areas and provide skill development tracks across different aspects of Knative. 162 | - Encourage Goals: Educate on goal setting and facilitate mentorship to help contributors achieve their personal development plans. 163 | - Recognition: Design a recognition program for achievements at each level to celebrate and motivate contributors. 164 | 165 | 166 | ## Personalized One-on-One Meetings for New Contributors 167 | - Provide new contributors with the option to have one-on-one meetings with trusted community members or maintainers. These meetings should be short and focused, offering personalized support and guidance tailored to the new contributor's needs. 168 | - These initial interactions help establish trust and rapport, making new contributors feel valued and supported. This personal touch can make a significant difference in their comfort level and confidence. 169 | - The goal of these one-on-one meetings is to provide initial support and gradually encourage new contributors to participate more publicly in the community. Over time, as they become more familiar and comfortable, they will be more inclined to engage with a broader group of contributors. 170 | 171 | #### **Why is it needed?** 172 | 173 | - **Perception of Limited Community Interaction:** New contributors often perceive the community as being comprised of only one or two individuals they are most comfortable with. By facilitating personalized meetings with these 'trusted' members, we can help new contributors expand their network within the community. 174 | - **Enhanced Comfort and Engagement:** Personalized support helps newcomers feel more comfortable asking questions and seeking guidance. As they build confidence, they are more likely to engage publicly, fostering a more inclusive and active community. 175 | - **Expanding Networks:** Encouraging interactions with multiple community members helps new contributors get to know more individuals, broadening their support network and enhancing their sense of belonging. 176 | 177 | #### Implementation: 178 | - A contributor reaches out to a maintainer they trust, possibly seeking help or explicitly requesting a one on one meeting. 179 | - While not mandatory, maintainers may also arrange meetings with contributors who seek significant assistance through direct messages. 180 | - Utilize scheduling tools like [Calendly](https://calendly.com/) to coordinate convenient meeting times for both parties. 181 | - During the initial meeting, maintainers should aim to understand the new contributor’s interests, goals, and immediate challenges. They may also provide an overview of the project and essential resources to facilitate their integration. 182 | - If additional support is needed, schedule follow-up meetings to address further queries and monitor the contributor’s progress. Gradually encourage their participation in public channels and group meetings. 183 | - Maintaining confidentiality throughout these interactions is crucial to ensure contributors feel comfortable sharing their concerns. 184 | 185 | 186 | ## Anonymous Feedback Mechanism 187 | - **Anonymous Surveys:** Create a survey platform where contributors can anonymously provide feedback, share insights, and suggest improvements in the developer experience. 188 | - **Regular Review and Action:** Establish a process for regularly reviewing the feedback collected through the survey platform. Use this feedback to identify areas for improvement and implement changes to address the community's needs and priorities. 189 | For example, new contributors after their onboarding can be encouraged to share their insights and experiences by participating in an anonymous survey. 190 | - **Transparent Communication:** Communicate the changes and improvements made in response to the feedback. Transparency in how feedback is used will encourage more contributors to participate in the feedback process. 191 | 192 | #### **Why is it needed?** 193 | 194 | - **Encouraging Candid Feedback:** An anonymous feedback mechanism allows contributors to share their thoughts and suggestions without fear of judgment or repercussions. This leads to more honest and valuable insights. 195 | - **Targeted Community Improvements:** By gathering comprehensive feedback, the community can better understand its needs and priorities, facilitating targeted improvements that enhance the overall experience for all contributors. 196 | - **Fostering Inclusivity:** Regularly acting on feedback demonstrates a commitment to inclusivity and continuous improvement. It shows that the community values the input of all contributors and is dedicated to creating a supportive and inclusive environment. 197 | 198 | #### Implementation: 199 | - Survey Creation: Set up an anonymous survey platform. The UX Working Group can be in charge of designing and maintaining the survey. 200 | - Promotion: Promote the survey through community channels and encourage participation. 201 | - Analysis and Action: Regularly review the feedback collected and take action on actionable suggestions and concerns. 202 | - Communication: Share updates on the changes and improvements made in response to the feedback to ensure transparency and encourage ongoing participation. --------------------------------------------------------------------------------