Re: Wiki : Code Submission and Review Guidelines

[Leo Simons <LS...@schubergphilis.com>]

On Jul 31, 2014, at 10:34 AM, Santhosh Edukulla <sa...@citrix.com> wrote:
> Iam not sure if it is already available, so i added a simple wiki with few notes for new submission and review process at the link below.
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Code+Submission+and+Review+Guidelines

There were a few places. I changed them to point at this page since it’s better :)

In general the wiki suffers from duplicated info! Now that I have access I might try and do some more cleanup.

> In case, if there are any issues with the wiki, please feel free to modify and add accordingly. If we can add specific examples for few cases helping users to follow them appropriately, then it will be more good.

Well, what I’m missing is the inverse of these guidelines. Being a committer on an apache project is a privilege and a responsibility, and if a guideline is needed for code submission, it requires definition of the behavior of the reviewer at least as much as behavior of the contributor.

* ensuring submissions to reviewboard get review
  * it’s not good community-building to require patch submitters
    to go hunt for a committer that can review their work
* ensuring review is consistent
  * it’s not good to be told to do one thing, then to be told to
    do another thing, then to be told to do another thing…
  * it’s not good to be told something is ok (lazy consensus…),
    do a bunch of work, and then be told it is not ok (remember,
    -1 includes a commitment to help sort out the issue, whether
    a contribution comes from a committer or not)
* ensuring review aligns with committer practice & code quality
  * it’s not a good thing to hold a contributor to a _higher_
    standard than committers
  * it’s not a good thing to require contributors to follow all
    code quality standards when existing code does not follow those
    standards — fixing a bug shouldn’t involve rewriting the
    surrounding code and accepting a bugfix shouldn’t involve
    those things either

I think it is good to improve quality and good to have quality guidelines, but when you have them it is more important that committers adhere to them than external contributors. I.e. quality _practices_.

In general I’m not a big fan of documented guidelines and policies and procedures. I think apache has too many of them already, and I’m _especially_ guilty since I wrote a bunch of it :-).

_That_ said, what we need the most is more people stepping up and doing review, and if this guideline helps with that, great! Go go go! :)


cheers,


Leo