summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorParis <parispittman@google.com>2017-12-08 11:27:31 -0600
committerGitHub <noreply@github.com>2017-12-08 11:27:31 -0600
commit731707382cf0a6a44c059e0189323ee3c10f97b1 (patch)
tree094189983bed8493bcb1fc10a22d7f558944ce69
parentfb42b3fbadaf249cf4bb4e825c5647f2dedda097 (diff)
Create scaling-new-contributors.md
Appreciate help with copy-editing from this session
-rw-r--r--community/2017-events/12-contributor-summit/scaling-new-contributors.md61
1 files changed, 61 insertions, 0 deletions
diff --git a/community/2017-events/12-contributor-summit/scaling-new-contributors.md b/community/2017-events/12-contributor-summit/scaling-new-contributors.md
new file mode 100644
index 00000000..925e18ac
--- /dev/null
+++ b/community/2017-events/12-contributor-summit/scaling-new-contributors.md
@@ -0,0 +1,61 @@
+# Scaling New Contributors
+*Lead: Vishnu Kannan*
+*Notetaker: Chris Love*
+
+New pull requests are plateauing in k/k
+Takes much longer for a PR to get through
+
+Contributor Experience
+3 mo for PR merged - minor PR that was a fix
+Nobody reviewed - was ignored
+PRs are lacking process to get them on milestones
+Lack of organization and understanding PR process
+There is a need for a sig buyin
+We have a explicate state machine, instead of a implicate state machine
+We do have a well defined process for new contributors to follow
+We need to have committed resources to a PR,
+File an issue first, then file a PR
+When the needs sig is there, the issue will be processed and you can find out which sig
+
+What is the problem
+No time to review PRs
+
+Mentoring Program
+Mentoring program overview
+Common theme is that we do not have time to review PR
+Bootcamps for new contributors
+
+Lot of Common Complaints
+
+Tests did not pass what happened
+Devstats
+Everyone needs to look at the stats
+We are currently bottlenecked at approvers not reviews
+
+How to fix the problem
+SIG Leads are too busy
+Have another role within the sigs for mentors
+Can we label the issues in terms of complexity
+Sig-cli has it documented in a contributor guide
+Incentivizing mentoring
+How do we help take the load off of the approvers pool, how do we improve reviews
+How many times a reviewer say lgtm
+Reviewer performance
+We need to document what a good review looks like
+Guidance on progress to contributor -> reviewer -> maintainer
+How does maintain a good citizenship in the community
+Put the documentation into kubernetes.io
+Simple use-case examples on how to get a PR in
+Give contributors some responsibilities
+Planned workshop on how to get a PR merged
+Contributor based workshop
+Ask questions on #kubernetes-dev
+We need to document how to get answers
+We need to move our documents into kubernetes.io
+Sigs may not want to have new contributors
+We need to cleanup those who are inactive in k/k - OWNERS and MAINTAINERS
+How do we create incentives?
+If they are autosigned an issue and do not respond - we need to measure that metric
+How do we fix the release process in terms of what is in a release, because we do not have a target we do not know what we are shooting at
+We need to figure out what new contributors are working on
+Start off by using kubernetes then become contributors