Yes we had it, and we used it and contributed and it is still working. Why not start to use a Plone Instance we own for storing results only again.
We can keep all the resulting PDF or image, text material in Plone and reference the source repositories as necessary. Maybe we end up with something like Plone Software Center (hides).
The benefit of coactivate was, that we could act agile independent from the foundation and contribute. The control freak approach killed this. Today we should adapt the new approaches for the Plone docs and look for proper licenses based on CC4.0-BY (and NOT SA-NC!) .
The only issue I still see with github is that it is not well suitable for large media binaries and not designer friendly. By the way: today another customer killed my Dropbox, so keep away from these services. We need to have a sustainable solution. All suggestions welcome.
I have not finished my git-annex evaluation, but it is promising for handling media files. On the website https://git-annex.branchable.com/ you find an overview what the differences between git-annex and e.g. dropbox are and a comparison to other similar technologies: https://git-annex.branchable.com/not/ . Any experience out there?
For now I am happy to use git (github) myself, but with no structure it will end up as a mess. If we use one repo per media solution we should declare a namespace for repos, but do not use "marketing" but "media".
If we can support translated versions and different formats we need also to provide some metadata which Plone version is covered or what target audience is aimed at. Managing this in a github repo only without overview is a nightmare.
If we have strong points to vote against an overview on Plone related media on Plone.org/com we can put these overviews into a subsection of the Plone documentation, where it makes absolutely sense together with the brand manual etc. But remember that we need to avoid to draw away the communications, marketing and media people not familiar with sphinx, github etc.
My suggestion would be to have repos like:
We just register them incrementally on github and go for it. It is a good compromise for readability and order.
plone.media.folder0003/plone5/de should be avoided, since it hops one level.
better use another
plone.media.folder0004/de and define a standard how to write a manifest file or use tags to tag this.
Inside the repo we should have the same rules for folder/file structures like we have with sourcecode. Graphic artists know this from "collect for print service" scripts. I think they can follow those rules, given by the source programs.
We internally use a system similar to this since over 20 years and it simply works, even without a database!
I would like to help out with docs or cooperation on this, lets get in touch again. I am in Sorrento and happy for feedback.