Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updating code review process per mailing list disucssion

...

Small patches are almost never rejected, so it's a good strategy to start with small patches for new contributors. Keep in mind that Spark committers act as volunteers - patches with major correctness issues might be rejected without significant review, since such review is very costly in terms of time. If this happens consider finding smaller patches or simpler features to contribute, then building up your confidence and abilities over time.

Code Review Process

Community code review is Spark's fundamental quality assurance process. When reviewing a patch, your goal should be to help streamline the committing process by giving committers confidence this patch has been verified by an additional party. It's encouraged to (politely) submit technical feedback to the author to identify areas for improvement or potential bugs.

If you feel a patch is ready for inclusion in Spark, indicate this to committers with a comment such as: "I think this patch looks good". Spark uses the LGTM convention for indicating the strongest level of technical sign-off on a patch: simply comment with the word "LGTM". An LGTM is a strong statement with specific semantics. It should be interpreted as the following: "I've looked at this thoroughly and take as much ownership as if I wrote the patch myself". If you comment LGTM you will be expected to help with bugs or follow-up issues on the patch. Judicious use of LGTM's is a great way to gain credibility as a reviewer with the broader community.

It's also welcome for reviewers to argue against the inclusion of a feature or patch. Simply indicate this in the comments.

Contributing New Algorithms to MLLib

...