<div dir="ltr"><div>It is nice to see all this discussion happening, so keeping the discussion at the higher level.</div><div><br></div><div>A) When the VTK ARB was set up there were a group of people nominated for topic leads.</div>
<div>See: <a href="http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process">http://www.vtk.org/Wiki/VTK/Managing_the_Development_Process</a></div><div>maybe this list needs updating. This feeds into B), below, as these people are often very busy and should be alerted to relevant submissions.</div>
<div><br></div><div><br></div><div>B) A while back I asked a question about whether it is possible to get from gerrit regular management reports, see: <a href="http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html">http://vtk.1045678.n5.nabble.com/Gerrit-Searching-td5725938.html</a> and I got no replies. I saw that David Cole did a simple enquiry much like I have done. </div>
<div><br></div><div>Unless I am really missing something fundamental, and I have searched the web, this does not happen easily with gerrit.</div><div><br></div><div>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.</div>
<div><br></div><div>What would be really useful would be management style status reports such as:</div><div>1) The number of reviews with no reviewers.</div><div>2) The number of reviews approved but not submitted.</div><div>
3) The number of reviews awaiting approval.</div><div>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.</div>
<div><br></div><div>I think putting a process in place like this should help a lot particularly with respect to the issues Dabid Gobbi raised. </div><div><br></div><div>This would also help community engagement as submitters will know that their submissions are being looked at.</div>
<div><br></div><div>So this feeds into Will's comments too.</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>Anyway this is my take on it.</div><div><br></div><div>Regards</div><div>   Andrew</div><div><br></div><div><br></div>-- <br>___________________________________________<br>Andrew J. P. Maclean<br>
<br>___________________________________________
</div>