<div dir="ltr">You are both absolutely right. The review process is broken when it comes to accepting patches from the community. It is broken in 3 ways:<div><br></div><div>1. As Kitware, we haven't put the right attention to reviewing contributed code from top down (i.e. me and other managers using project resources and asking developers to review contributed work). Even when we have specific projects under which this can be done, we favor developing new code to reviewing contributions.</div>

<div><br></div><div>2. As individual contributors to VTK and ParaView, many of the Kitware developers are focused on their primary goals. We haven't built the open source community spirit as well as we can. Part of this needs to be done by the larger community with encouragement by senior folks (not just ones at Kitware).</div>

<div><br></div><div>3. As others pointed out, there is not enough emphasis and encouragement in reviewing code by the larger community. My code would languish in Gerrit if I didn't have the ability to walk to someone next door and ask them to review it please. David Gobbi and others had suggestions on how to encourage the larger community to be more involved in reviewing.</div>

<div><br></div><div>My opinion is that this all boils down to making people feel ownership for VTK rather than seeing it as a tool that needs to be patched as necessary for other work or some project goal (deliver x,y and z and you are done). This is not something I can easily force people to do nor is it a top down thing. I am doing my best by encouraging more community engagement, removing barriers from tools and setting an example by contributing in various ways. I'd like to hear suggestions on how to achieve this and what I can do towards this.</div>

<div><br></div><div>One idea: more community hack-a-tons. I just sent out a suggestion for addressing issues in the bug tracker. Why not have another one for reviewing code?</div><div><br></div><div>One final note. Everyone please keep in mind that while there are quite a lot of contributors to VTK, certain parts of it are developed by only a few people. Core pipeline: I am it at this point. Rendering: by next year, it will be Ken and Marcus. Imaging: hardly anyone in the scientific vis team at Kitware does anything with imaging filters. We update them when we make changes to the pipeline or data model but that's it. So some of those are maintained and developed by others or they are some orphaned. This can only be addressed by either encouraging new (or existing) developers to take ownership or by removing those components all together.</div>

<div><br></div><div>My 2 cents.</div><div>-berk</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 27, 2014 at 8:37 AM, Ronald Römer <span dir="ltr"><<a href="mailto:rroemer@gmail.com" target="_blank">rroemer@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">You are absolutely right, in most of your points. None if my commits were previewed by any native kitware developers. Its a pain to find the right previewers and after that none of them will do that job. So it is very hard for a new developer from outside the organization to get the right attention. This is frustrating...</p>



<br>_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
<br></blockquote></div><br></div>