fix typo around the project

Signed-off-by: cheyang <cheyang@163.com>

4 files changed, 6 insertions, 6 deletions

diff --git a/events/2017/12-contributor-summit/breaking-up-the-monolith.md b/events/2017/12-contributor-summit/breaking-up-the-monolith.md
index 3616aeca..baf95727 100644
--- a/events/2017/12-contributor-summit/breaking-up-the-monolith.md
+++ b/events/2017/12-contributor-summit/breaking-up-the-monolith.md
@@ -45,10 +45,10 @@ Assumption: "big tangled ball of pasta" is hard to contribute to
   - what about storage providers, if we break them up there's a clear interface for storage providers
 - second thing: here are api/components that are required, required but swappable, optional... how can you do that swapping around of stuff in the monorepo
 - robertbailey: when I proposed this session I thought we had all agreed that breaking the repo was the way to go, but maybe we don't have that conensus could we try and figure out who is the decision maker / set of decision makers there and try to come to consensus
-- dchen1107: I heard a lot of benefits of the split.  So there's a huge cost for release management, as the release manager, I don't know what's in the other repositiory.  Clear APIs and interfaces could be built without needing separate repositories. Gave example of Docker and CRI, which got API without moving repos.
+- dchen1107: I heard a lot of benefits of the split.  So there's a huge cost for release management, as the release manager, I don't know what's in the other repository.  Clear APIs and interfaces could be built without needing separate repositories. Gave example of Docker and CRI, which got API without moving repos.
 - Example of Cloud Foundry, build process which took two weeks.  How do we ensure that we're delivering security updates quickly?
 - thockin: We can put many things in APIs and cloud providers are a good example of that.  Splitting stuff out into multiple repos comes down to the question of: are we a piece of software or a distribution?  You'll have to come to my talk to see the rest.
-- spiffxp: Increasing our dependency on integration tools will add overhead and process we don't have now.  But I understand that most OSS people expect multiple repos and it's easier for them.  Github notifications are awful, having multiple repos would make this better.  The bots have improved the automation situation, but not really triaging notifications.  How many issues do we have that are based on Github.  Maybe we should improve the routing of GH notificaitons instead?
+- spiffxp: Increasing our dependency on integration tools will add overhead and process we don't have now.  But I understand that most OSS people expect multiple repos and it's easier for them.  Github notifications are awful, having multiple repos would make this better.  The bots have improved the automation situation, but not really triaging notifications.  How many issues do we have that are based on Github.  Maybe we should improve the routing of GH notifications instead?
 - solly: if we split, we really need to make it easier for tiny repos to plug into our automation and other tools. I shouldn't have to figure out who to ask about getting plugged in, we should have a doc.  We need to make sure it's not possible for repos to fall through the cracks like Heapster, which I work on.
 - bgrant: We're already in the land of 90 repos.  We don't need to debate splitting, we're alread split.  We have incubator, and kubernates-client.  I think client has helped a lot, we have 7 languages and that'll grow.
 - bgrant: the velocity of things in the monorepo are static
diff --git a/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md b/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md
index 50be4b66..23ef1082 100644
--- a/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md
+++ b/events/2017/12-contributor-summit/enabling-kubernetes-ecosystem.md
@@ -72,7 +72,7 @@ Notes by @directxman12
 
     * Need to look at human-consumable media, not necessarily machine-consumable
 
-* Question: do we currate
+* Question: do we curate
 
     * Do we require "discoverable" things to be maintained/use a CLA/etc?
 
diff --git a/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md b/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md
index ddb6d688..7afa5b16 100644
--- a/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md
+++ b/events/2017/12-contributor-summit/onboarding-new-developers-through-better-docs.md
@@ -148,7 +148,7 @@ Note: the focus is on documentation, so we won’t be able to act on suggestions
 
     * Templates/guidelines mentioned above may be helpful
 
-    * Talk to SIG docs (SIG docs wants to try and send delagates to SIG, but for now, come to meetings)
+    * Talk to SIG docs (SIG docs wants to try and send delegates to SIG, but for now, come to meetings)
 
 * Question: should there even *be* a split between user and contributor docs?
 
diff --git a/events/2017/12-contributor-summit/role-of-sig-lead.md b/events/2017/12-contributor-summit/role-of-sig-lead.md
index 54e3d26f..6b68e9c3 100644
--- a/events/2017/12-contributor-summit/role-of-sig-lead.md
+++ b/events/2017/12-contributor-summit/role-of-sig-lead.md
@@ -8,7 +8,7 @@ Joe wants to redefine the session
 Power and role of sig leads is defined in how we pick these people. Voting?  Membership? What do we do for governance in general
 
 
-Paul: Roles that are valuable that are not sig lead. Svc cat, moderator of discussions and took notes. Secratary of committee. 
+Paul: Roles that are valuable that are not sig lead. Svc cat, moderator of discussions and took notes. Secretary of committee. 
 
 Back to joe; what does the sig think. Each leader doesn’t know. Who shows up to a meeting isn’t helpful as not everyone can attend. What does the lead thing? Allows too much personal power. Decision maker or tech lead? 
 
@@ -31,7 +31,7 @@ Joe -need someone who cares
 Eric chang - every sig needs a person doing X,Y, Z. docs, tests, etc. fundamental goals. Sig lead has too much to do. Formalize roles and fill them with people, especially different people for each role. 
 Large sigs have more people to allocate to alt roles.
 
-Jessie - Can’t have the person who facilitates be unbiased techincally. Best solution vs alternative monetary gain.
+Jessie - Can’t have the person who facilitates be unbiased technically. Best solution vs alternative monetary gain.
 
 Joe -  people as sig leads in name only to game the system as being important