incubator-samza git commit: Fix typo in coding guide

[jg...@apache.org]

Repository: incubator-samza
Updated Branches:
  refs/heads/master 3161c640a -> 377e5cc3f


Fix typo in coding guide

Signed-off-by: Jakob Homan <jg...@gmail.com>


Project: http://git-wip-us.apache.org/repos/asf/incubator-samza/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-samza/commit/377e5cc3
Tree: http://git-wip-us.apache.org/repos/asf/incubator-samza/tree/377e5cc3
Diff: http://git-wip-us.apache.org/repos/asf/incubator-samza/diff/377e5cc3

Branch: refs/heads/master
Commit: 377e5cc3f56549a02cbbb79cc3dc7166df7da585
Parents: 3161c64
Author: Peter Vandenabeele <pe...@vandenabeele.com>
Authored: Sat Dec 20 21:19:21 2014 +0100
Committer: Jakob Homan <jg...@gmail.com>
Committed: Sat Dec 20 17:42:08 2014 -0800

----------------------------------------------------------------------
 docs/contribute/coding-guide.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-samza/blob/377e5cc3/docs/contribute/coding-guide.md
----------------------------------------------------------------------
diff --git a/docs/contribute/coding-guide.md b/docs/contribute/coding-guide.md
index edae995..6cb4cee 100644
--- a/docs/contribute/coding-guide.md
+++ b/docs/contribute/coding-guide.md
@@ -30,7 +30,7 @@ These guidelines are meant to encourage consistency and best practices amongst p
 * Logging, configuration, and public APIs are our "UI". Make them pretty, consistent, and usable.
 * There is not a maximum line length (certainly not 80 characters, we don't work on punch cards any more), but be reasonable.
 * Don't be sloppy. Don't check in commented out code: we use version control, it is still there in the history. Don't leave TODOs in the code or FIXMEs if you can help it. Don't leave println statements in the code. Hopefully this is all obvious.
-* We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing the feature, just like unit tests or performance results.
+* We want people to use our stuff, which means we need clear, correct documentation. User documentation should be considered a part of any user-facing feature, just like unit tests or performance results.
 * Don't duplicate code (duh).
 * Any API that's user-facing (something that a Samza job could use) should be defined in samza-api as a Java interface. Scala is for implementation only.