From the practical point of view, taking into account backward compatibility and trying to cover as wide audience today as possible, I'd still recommend today to create repositories with XML classes exported. In a longer run, UDL export is much easier to handle [and provide better Cache' visibility], but this moment IMHO is not yet achieved.

Back to repositories questions: well, there are several people which has commit permissions to intersystems and intersystems-ru hubs. So many people could create fork of "interesting" project. But usually it's me, who maintain repositories in synchronized state (using this set of scripts if this matter).

So here is the recommended plan - you create personal repo, with reasonable README and accepted license (MIT is recommended, BSD or Apache is ok). Then give us know (via this same channels as we use at the moment).

I agree with Scott - Facebook practice that you could delete your post (including all comments below it) or entire comments thread under your comment - is good one. And sometimes it allows to reduce noise ratio significantly. 

Your own post or comment is yours - you should be able to change your mind and edit or delete it easily. Forum software just should be able to handle it gracefully and transparently (i.e. marking properly that this post or comments has been edited at  XXX UTC)

Configuring Git integration in the Studio and creating proper GitHub repo is not a rocket science, thoug it requires some getting used to the 1st time. If you want to I'll call you  this Moday.

Here is 1st hint if you want to play with Cache' in container - https://github.com/zrml/ccontainermain 

This is interesting idea, but what those containers would export? (namespace access?) How those containers would be reverted to the initial state? What isolation should be provided between containers? What sequence of steps and set of states would be cloned from the basic container for the different user?

Effeciency of Docker is heavily based on unionfs, cgroups and bridged networking services, which were already available in the linux. What could serve the similar purpose here? I assume you thought about this all before asked, and have some ideas. That would be interesting to hear. 

Yes, topics should be sorted by their "modification time" (i.e. when they were originally created or have been updated with newer comment). 

Yes, agreed that html email for each post/comment and reply-to-email as reply-to-thread-conversation  would be much better and easier, than current text-only digests. 

This portal engine keeps track of all posts this loggedin user has read. So it will be easy to visualize the number of unread posts/articles created in the given subgroups after last visit to portal. It's really very hard to keep track of all relevant updates. (Although this is usual practice to highlight updates since last visit for each forum software):

• we need it be shown at the root page of each group (i.e. number of new comments or new/updated articles)
• we need RSS to easy subscribe to each hierarchy level.

Well, in theory, Exchange is the IMAP superset. Thus if you know how to deal with mails via IMAP then you could work with Exchange server similarly.