RFC: Slicer extension end-of-life procedure

[fedorov (Andrey Fedorov)]

In one of the discussions unrelated to Slicer, someone raised a question about how to properly phase out software tools that for one reason or another are no longer supported/needed/working. Martin Morgan from the Bioconductor team shared their “Package End-of-Life Policy”. Bioconductor is a well-established project in many ways similar to Slicer, but from a very different community. I think it makes sense to learn from them.

I think we should consider having something like this for Slicer extensions. I am pretty sure that there are some extensions that have not been touched for a very long time, where developers are no longer around or are not responding, and which are always red on the dashboard. I think those extensions make a dis-service both the users (since the advertisement of the working functionality provided in in the documentation, raising expectations), to the developers (by polluting the dashboard and making it more difficult to identify real problems), and to the whole image of the platform, raising concerns about quality and the level of curation of the content.

Would be great to hear both from the users and from the developers on this!

• YES, we should have End-of-life policy for 3D Slicer extensions
• NO, we should not have End-of-life policy for 3D Slicer extensions

[pieper (Steve Pieper (Isomics, Inc.))]

Very good point. We actually started discussing this the other day on the developer hangout and started working on a standardized scheme for the extension status.

2019.03.26 Hangout

Notes: Thanks to @Sam_Horvath, extension status will be standardized to Stable, Experimental and Unmaintained (or similar). The status will be used to dispatch the build results in appropriate groups: for SlicerPreview dashboard Stable|Experimental -> Extensions-Nightly Unmaintained -> Extensions-Nightly-Unmaintained code to update here in master branch for SlicerStable dashboard Stable|Experimental -> Extensions-X.Y-Nightly Unmaintained -> Extensions-X.Y-Nightly-Unmaintained co…

[lassoan (Andras Lasso)]

Thanks for the link. The policy makes complete sense and even if the policy is almost trivial, I agree that it could be useful to put it in writing.

We could address some not-so-trivial issues in the policy. For example, we could explicitly state that if the maintainer does not integrate a pull request that fixes a major issue (e.g., build error) within a specific time limit then (after giving notices, waiting, etc.) the extension may be forked and maintenance taken over by others.