Tomorrow, we will be having our next weekly hangout at 10:00 AM ET until 11:00 AM ET.
Anyone is welcome to join at this link: https://bit.ly/slicer-googlemeet-hosted-by-kitware
Agenda:
Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.
Thanks
Sam and Ebrahim
Notes from the meeting today:
VTK pushed a very small but very breaking change in minor version (removing a transitive include of iostream), which broke a lot of extensions. We have been working through the extensions – the fix is very simple.
Steve rebuilt mac arm64 build and there didn’t seem to be any issues this time, except that a dialog box didn’t seem to allow discarding without saving.
Service is now deployed at slicer-telemetry.kitware.com.
Current output: https://drive.google.com/file/d/1BGOqYuWVIFYtjthLLXDQQ8ob5Htiu4oU/view?usp=sharing
Here’s something we can discuss at the next meeting: Add a feature to make it easy to install extension PRs · Issue #2341 · Slicer/ExtensionsIndex · GitHub
BTW, maybe we should have a “next meeting” thread dedicated to posting agenda items for upcoming developer calls. Currently we post back to the meeting announcement, but sometimes, like this, I want to make a note in advance.
We could relax/automate extension approval process if we had these:
This looks great @lassoan 
It’ll be great to move towards more of a community review process to help keep things moving.
If you describe an interesting question then it is likely that discussion will start before the meeting. Instead of hiding that discussion in a developer meeting minutes topic, it would be better to create a new topic for it. The topic would be more focused, more visible, and more people would have a chance to be involved.
We could introduce a tag “discuss-at-weekly-meeting” that we could attach to any topic to put it on the next meeting’s agenda.
I agree that we need to do something sustainable.
The current heavy process that is similar to app store approval process is just not sustainable without dedicated funding or developers paying the costs.
“Community review process” may not solve the problem automatically, as it suffers from the same issues as the broken scientific paper peer review process. It is now much easier to generate an extension or write a paper, but people don’t have more time to review other people’s stuff.
We could allow publishing without review and let extensions emerge by getting likes or star ratings and comments - similar to YouTube, github, etc. We could then review highly rated extensions to bring them up into a higher tier.
I’m thinking it should literally be just publish a repo and people can use it or not. Not much different than publishing a web site. By community review I mean people can try out different options and suggest the ones they like to other people. Nothing too formal.
I do think we should look seriously at sandboxing options to protect your actual computer from random code. We should discuss architectures for this.
Yes, sandboxing would be important. Users cannot trust extensions but - more importantly - they cannot trust AI agents.
App stores provide some sandboxing but each platform is completely different and it would be significant effort on each to get into a store (and extensions and Python packages would complicate things further).
So, probably containers would be the most economical solution. If someone does not have compatible hardware or too difficult to set up then running on cloud be a good option.
Web browser is a good sandbox, too, so as SlicerTrame, VTK wasm, pyodide are improving, we’ll be able to seriously use that, too (maybe in a couple of years).
The process is not broken, commercial publishers choose profit over the community service the reviewers provide. I reject every single review request from commercial publishers (unless it is a non-profit society journal published by a commerical publisher). I am sure Nature/Elsevier can afford to pay their reviewers a meaningful honorarium when they are charging $12,000 for open access fee for a single publication and raking couple billion on profits for the equivalent of providing the platform.
We do not need to do the same. I brought this up a few times before. High demand extensions can pay an annual fee for the review and support. This is fair in the sense that they are also the ones who are using the infrastructure most. The question whether there is enough extension to support to make this viable (and not prohibitively costly) and in what way we can collect this money (Kitware?) and how do we distribute to the reviewers. I don’t know the answer to that.
As for the new extensions, perhaps an AI agent can review the code for malicious injections and we simply advertise them as “use at your own risk”?
It may also help if Sam and I post the weekly meeting announcement more in advance, so that people have the entire week to add items to the next meeting’s agenda
Added a summary of this discussion to the agenda: 2026.04.21 Weekly Meeting - #2 by ebrahim