I think it's in more then one category but I see it as the big "enabler" for hosted use cases especially in the ETL space, for us it's all about using the API to integrate OpenRefine with other software like our data pipelines or visualizations.
We have surprisingly few issues I would say. When someone works on a project it's marked as "occupied" to avoid that multiply people work at the same project at once, however, the main reason isn't technical but rather that it wouldn't improve anyone's productivity.
For instance, say we introduce a notion of user account in the tool and require people to be logged in to open a project. I would not want local users to be asked to create an account on their single-user OpenRefine instance when they install it, because it would be an unnecessary extra step in the start up process.
I completely agree and might even argue that accounts or access control** shouldn't be in OpenRefine but rather OpenRefine should provide a good set of extension points allow one to annotate project and edit history metadata. In general for this type of features I think focusing on extensibility rather than the feature itself is the best solution for all. A focus and commitment to the API, extension points, and possibly webhooks would go a very long way.
This is actually what we do, and then we "lockdown" server side settings for the things we don't want users to access. I could see some issues with trying to align this approach as some settings which local users are used to isn't available to them on our end(reconciliation services for example) but I could imagine that "settings-levels" could be a matter of configuration if it's ever enough of a use case.
You can only do so much with such an approach of course, but I would open to more ambitious changes, for instance making the PreferenceStore pluggable, making it possible to implement different versions of it (the existing one, and some multi-user one which would rely on some authentication mechanism exposed by the proxy behind which OpenRefine runs). Our preferences system is really poor at the moment anyway, so it's easy to imagine we could have something better.
Oh I'm getting ideas as I read, sounds like a case for that BarCamp!
Did you consider submitting those patches upstream? The new process to disclose advisories on GitHub is pretty nice and would let us review the issues privately.
Yes, but it's unlikely I will contribute in this area given how quickly it have gotten toxic and dismissive in the "past". Maybe in the future.
**Some native access control mechanism for the API could be useful, but it's a different question I believe.