On Wed, Jul 29, 2015 at 7:38 PM, Gwen Shapira <gshap...@cloudera.com> wrote:
> I guess we see the "reviewer" part with different interpretations.
>
Yes. As you know, Git was created for and initially used by the Linux
Kernel. As such they were very influential in conventions, terminology and
best practices. This is what their documentation states:
"By offering my Reviewed-by: tag, I state that:
(a) I have carried out a technical review of this patch to
evaluate its appropriateness and readiness for inclusion into
the mainline kernel.
(b) Any problems, concerns, or questions relating to the patch
have been communicated back to the submitter. I am satisfied
with the submitter's response to my comments.
(c) While there may be things that could be improved with this
submission, I believe that it is, at this time, (1) a
worthwhile modification to the kernel, and (2) free of known
issues which would argue against its inclusion.
(d) While I have reviewed the patch and believe it to be sound, I
do not (unless explicitly stated elsewhere) make any
warranties or guarantees that it will achieve its stated
purpose or function properly in any given situation."
This is a common interpretation when the word reviewer or reviewed-by is
used in a Git commit. If we mean something else, maybe it's better to use a
different word.
What are the benefits you see of formalizing who gets mentioned as reviewer?
>
* Consistency
* Easier for new committers if there's a clear guideline
* Avoid surprises for people who comment on PRs. Now that we are accepting
pull requests via GitHub, it is more likely that people will comment on
pull requests as they see it in their news feed (the repository has more
than 300 watchers and this number is likely to rise); many/most of them
won't be doing a proper review.
In any case, if the committers don't think this is an issue, we can
continue as it is and see if anyone else complains. Each community is
different after all.
Best,
Ismael
