[vtk-developers] [EXTERNAL] Re: Driving away your existing developers

[Scott, W Alan]

Berk/all,

I have read this thread with interest, and have been impressed with how open and honest everyone has been.  We have a problem, we discuss the problem, we find fixes for the problem.  After discussing these issues with my local team, one comment came up over and over again.  I realize that the VTK workflow and this thread are different than ParaView, but since my experience is with ParaView, I will comment accordingly.  Further, I realize that the two projects have different needs, but I think the following comments still apply.

Although the current procedures do have issues slowing down community contributions, they also have strengths.  This is true for ParaView, and I assume for VTK.  I have been doing a lot of testing of ParaView for the upcoming 4.2 release, and ParaView is amazingly “clean” at this point.  GUI’s are clear, workflows are simple (or as simple as can be), lots of stuff gets tested in the dashboards, and everything just works (well, most things just work).  I am now somewhat surprised when I find bugs, as opposed to the past, where I was surprised when I didn’t.  Numerous years ago, before development was reviewed before moving it into head, it was always a crap shoot when updating.  Now, it is rare that Master isn’t in a state that is release candidate quality.  And I believe that Master should always be in a state that is release candidate quality.

My executive summary is this: as we move forward, let’s make sure we don’t lose the processes and controls that have given us the quality products we currently have.

my $0.02.

Alan


From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Berk Geveci
Sent: Wednesday, August 27, 2014 7:11 AM
To: Ronald Römer
Cc: VTK Developers
Subject: [EXTERNAL] Re: [vtk-developers] Driving away your existing developers

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:

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.

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).

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.

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.

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?

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.

My 2 cents.
-berk


On Wed, Aug 27, 2014 at 8:37 AM, Ronald Römer <rroemer at gmail.com<mailto:rroemer at gmail.com>> wrote:

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...

_______________________________________________
Powered by www.kitware.com<http://www.kitware.com>

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/vtk-developers


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140828/299adfdc/attachment-0002.html>