Developer Meetings/20170328

To Discuss

• Creation of private list (slicer-admin@googlegroups.com) that will be associated to web resources managed by the core developers. These resources will for example include:
  • the slicerbot Github user
  • access to the DigitalOcean instances used to host slicer.org, wiki, ...

• Different web resource descriptions along with instructions to access them will be documented.

• Automatic generation of API documentation. See https://github.com/Slicer/Slicer/pull/690

• Slicer module/extension template duplication: Does it still make sense to have the module and extension templates in Utilities/Templates along with the complete example of extensions in Extensions/Testing ?

• Gitbook CEO replied to our inquiry about increasing the limit and asked "How many people to you foresee contributing to your docs ?"

• Request for adding Slicer license as an official SPDX (Software Package Data Exchange) License:
  • https://spdx.org/spdx-license-list/request-new-license
  • https://spdx.org/licenses/
  • Rational: Then, we could
    • (1) use the qualifier "'License :: OSI Approved :: Slicer License" in python packages (and similar references in other ecosystems),
    • and (2) also potentially request to have the Slicer listed as an option on Github (that said, we need at least a 1000 repos using the license on GitHub ... and we currently have 110 reported).

• SSL error on windows: http://slicer-devel.65872.n3.nabble.com/SSL-error-in-latest-nightly-td4038361.html

• Slicer related bugs in ITK addressed for 4.11.1 release:
  • ITK-3519 When ThinPlateSplineTransform is read from file, ->ComputeWMatrix() is required to avoid a crash.
  • ITK-3523 incorrect dicom from encapsulated metadata
  • ITK-3529 Failed to build ITK Remote module using Release 4.11.0
  • ITK-3498 Support modules in find_package OPTIONAL_COMPONENTS (related to getting ITK-3529 in the release branch)

Conclusion

• Talk with Jon from Intel:
  • ITK, Slicer, VTK .. popular tool.
  • Explore how Intel could have the biggest impact.
  • Explore area where we are headed to.
  • Bring Intel to contribute something meaningful.
  • How to move forward ? Collect feedback. Come with initial list of idea. Priority list.
  • From Andras: Identify a specific project and see how we can move forward.
  • From Matt (last week): Improve ITK threading geared toward registration.
  • From Steve:
    • A lot of tool in house to look at executable and identify issue on a given arch. May something could be done in that directory.
    • Jon: Easy to generate a lot of results from tool. But need to identify a use case
    • Steve/Andrey: May be improve perf of BRAINSFit
    • Andras: Slicer uses one processor most of the time .. learn about how to maximize use of processor.
    • Jon: Profiling would allow to identify where we can optimize. Would it make sense to use Mkl ? First assumption is that we don t need MKL.
    • Steve: May it could be made available for open source project.

• Remove Extensions/Testing

• private mailing list makes sense

• SPDX license:
  • Steve: Worth trying to request for its addition
  • Andras: What about avoiding to fragment the license ecosystem .. and standardizing ?
  • Steve: Slicer License has been carefully crafted.
  • Matt: Limitation of Apache 2.0, complicated and long. But the industry is standardizing on it.

Appendix

Exchange with Gitbook CEO

From GitBook CEO

Hi Jean-Christophe,

Cool project !

How many people to you foresee contributing to your docs ?

Kind Regards,
Aaron, Co-Founder & CEO

From Jc: March 22

Dear Gitbook team,

Thanks for both maintaining this awesome project and also offering for free it for open-source project. This is great.

The Slicer community, whom I represent here, is evaluating Gitbook as an outlet for publishing its
user manual(s) associated with 3D Slicer.

3D Slicer is an open source software platform for medical image informatics, image processing, and
three-dimensional visualization. It has been downloaded more than 250K times in past 5 years (with
a current download rate of 300 per day) and is used in more than 18 countries.

To effectively support our community, we would like to allow contributor from all other the world to
submit change requests to our manuals. To allow this, we were wondering if you could bump the
number of contributors limit to a larger number. Unlimited would be ideal.

Thanks for considering,
Jc

For reference: https://www.gitbook.com/@slicer