[vtk-developers] Driving away your existing developers

[Andrew Maclean]

It is nice to see all this discussion happening, so keeping the discussion
at the higher level.

A) When the VTK ARB was set up there were a group of people nominated for
topic leads.
See: http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process
maybe this list needs updating. This feeds into B), below, as these people
are often very busy and should be alerted to relevant submissions.


B) A while back I asked a question about whether it is possible to get from
gerrit regular management reports, see:
http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html and I got
no replies. I saw that David Cole did a simple enquiry much like I have
done.

Unless I am really missing something fundamental, and I have searched the
web, this does not happen easily with gerrit.

I have taken the approach of being notified of all submissions to gerrit
and then helping where possible. Obviously on some days this results in a
lot of e-mails.

What would be really useful would be management style status reports such
as:
1) The number of reviews with no reviewers.
2) The number of reviews approved but not submitted.
3) The number of reviews awaiting approval.
If these are generated, say monthly, then we should get a good overall
picture of what is happening and for example in the case of 1) notify the
submitter that reviewers are needed. One of the issues here is that often
people submitting new code or updates often do not noiminate reviewers - I
guess they either do not read all the documentation for the process or they
feel uncomfortable about nominating someone unknown to them.

I think putting a process in place like this should help a lot particularly
with respect to the issues Dabid Gobbi raised.

This would also help community engagement as submitters will know that
their submissions are being looked at.

So this feeds into Will's comments too.


C) As to the complexity of VTK ... hey it is a library and it is complex!
It supports many compilers, has many contributions from many different
people, has a rigorous somewhat old-fashioned C++ programming style.
However it has survived for over 20 years ... so it must be working.
Personally I think discussion about moving classes such as vtkITK, vtkTeem,
and vtkMRML out may be a bit early, particularly when we must remember that
VTK underpins ParaView, and their users need/want(?) this functionality.

One other worrying aspect (to me) is the slowness of the migration to VTK
6.x - it seems from the users group lots of people are still using older
versions such as VTK 5.8. These people need to be encouraged to upgrade to
6. I know that Steve Piper had issues with Slicer, but, correct me if I am
wrong, I did see something along the lines that these issues are largely
resolved.

D) VTK is not broken and it has many years of life yet! I think if we can
implement better management reporting, move people to VTK 6.1 and always
encourage migration to the most recent version, then this will reduce the
burden on Kitware and also encourage newer developers because the
responsiveness will be there. There is always exciting stuff happening in
VTK e.g OpenGL2, Numpy, Android stuff etc. We need to get this message out
that there is great stuff happening and everybody can help.


Anyway this is my take on it.

Regards
   Andrew


-- 
___________________________________________
Andrew J. P. Maclean

___________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20140828/8d897bb0/attachment-0001.html>