Apologies if this topic already exists elsewhere in the forums. I could not find a topic that discussed what I’m looking for.
Which is responses to the question: How do people/places that have unrestricted module add/delete privileges in their Omeka instances work with their constituencies to have desired functionality without having unsustainable maintenance issues? How are you maximizing options and minimizing technical debt?
Does anyone have protocols in place for a small group to manage successfully the introduction of new modules without unintended consequences to existing Sites? For determining when modules aren’t being used by your Sites and therefore ought to be removed?
The context is that our Online Exhibitions Committee is the maintaining group (other than the great hosting and service we purchase from CDS), and we are wanting both to offer more functionality to our curators and to not expand materially our maintenance labor.
From my perspective the usual model is that there’s a demarcation between users of the Omeka installation, even admin-level, and server-level administrators who would have the necessary permissions to add or remove modules completely. So the decisionmaking on what modules to support/install (and therefore maintain) would run through a single person or group.
I’m not sure if that matches with what you’re trying to accomplish, though.
Thanks for the response. By “unrestricted”, I’m meaning more in the hosting. Though we are hosted externally, there are no gates on what we install, fundamentally. (CDS doesn’t provide support for non-canonical plugins, but we can get them installed.) We do indeed have the separation you mention, so the question is more about the small group acting as the local gatekeeper. Being in that group, I can say that we want to have the modules that our curators will need — we currently use Omeka exclusively for online exhibits — and none that aren’t getting used but also want to be liberal in what we will install for these curators.