Hi Lorenz
Been meaning to respond in case nobody else did (had a parked tab with thread open), sorry for not getting back to you sooner. It’s quite something to ask though, took me 30 minutes to write this, so not surprised the lack of answers.
First off, sounds like a very exciting project. I’ve given the different use cases of Neos quite some thought over time and this one actually sounds like a potentially good fit.
The content repository with the constraints should have no problem filling the needs of the project, unless there are more complicated needs like limits on how many of a kind etc. Should probably be solvable with user guidelines if so though.
It’s possible to auto-fill content fairly easily until the node template which is currently in progress is finalized, basically a proper configurable API for the job. See RFC: Node Templates for more details.
Regarding the review workflow, that is somewhat covered by the new workflow in Neos 2.1 (see it in action in https://www.neos.io/news/neos-2-1-released.html). However the first version doesn’t include hard restrictions (who can do what) since it had to be pulled out due to some missing things in the Flow security framework. But I’m certain it will find it’s way into the core soon, get in touch with @robert for a status on that or to help making that happen.
For commenting on content, that’s a feature that has been developed but never made it into the core as the first version was determined as a experiment. However it’s available to install from https://github.com/sandstorm/ContentComments and get in touch with @sebastian if you want to know more.
The export parts should be very straight forward with the Flow/Neos stack.
There are a couple of additional challenges you might face, depending on the project needs and the people involved:
-
If you generate a lot of issues you might run into problems with the backend becoming slow due to the amount of content displayed. This can be worked around by only loading one issue in the tree at once, but might be a bit annoying for the editors. Another way would be to create a separate site instance each issue, not straight forward but can be automated with scripts.
-
The current text editor (Aloha) is fairly limited in it’s possibilities, so that might lead to some problems. It is possible to create custom node types to fill specific needs that the editor doesn’t provide (e.g. quote element with author field). Additionally there’s an ongoing project to replace Aloha with CKEditor, but that looks like it will be some time before that is finished.
-
Another problem might be multiple editors working on the same content, since it’s the last edit that wins. However it sounds like the workflow is fairly separated and user processes could prevent most issues related to that.
Also sounds like a project where outside help from someone with deep knowledge about the platform would be a good investment.
Don’t know if there are other tools out there better suited for the task though.
Anyway I’d suggest you give a prototype a go (should be doable in a couple of days probably) and evaluate the result.
Hope that helps.
Best,
Aske