For those of you who have already created accounts, I’ll transfer the accounts to the new system, and email you when it’s up.

1. Did you choose both of these from opensourcecms.com? Not to complication things, but they also have other well-reviewed portal alternatives, like XOOP, Xaraya, Mambo… More importantly, you can so basic evaluations of running versions there - or send other people to check them out.

2. I’ve had groups of 3-10 people do portal evaluation before, and it doesn’t usually go well - most portals are so customizable (by functions, plugins, and “skinning” the interface) that evaluating them and picking a preference doesn’t always answer much - people often make choices on factors that are trivial to change. A better question is “what do we want it to do?” and then looking for a portal / configuration that can do *that*. Although working from both ends towards the middle is good too….

2b. Another way is to shop around for the perfect portal that does what you envision doing (at a meta level) and then seeing (or asking them) what they use.

3. You don’t already know what you want, so the two priorities are flexible and portable. The three projects I started on a CMS all changed CMS platform after a year, because the things we thought were live-or-die requirements turned out not to be such a big deal, and vice-versa. For instance, when shopping for blogware for WRT, we thought blog channels and complex author management was really important, so we went with b2evolution. Six months later, we switched to WordPress.  Better to pick something that has well documented inport / export functions into a number of other packages - otherwise the switch later will be really tedious.

4. Portals are usually really top-heavy (example: AOIR’s drupal install), and their admin interfaces can be intimidating to people who want to get involved with one aspect of a project (as an editor, reviewer, etc.).  Sometimes the integration is nice, but sometimes it is worth considering handling each segment of what you want to do as a separate package - run the wiki in a wiki directory, the blog separately, and the actual article publishing system separately. The duplicate accounts aren’t always that big a deal, and the ability to easily switch out one thing (e.g. the blog, the wiki) is nice. Biggest advantage: having the people that get involved with your project work with whatever software they are already comfortable with.  Worth considering…

Good luck!

Any chance that ElectraPress will evolve to encompass new media studies and Milton studies?

Oh well.  It was worth a shot.