what goes here and what goes on HTYP

Well, yes, there is that whole "that's sort of a silly thing to do" aspect about it, and the question's occurred to me.

Poking around Wikipedia further (as I've been doing): there are numerous projects and categories within it, and one possibility is to emphasize content within one or more of those, and to escalate the primary projects on the homepage. It's a tagging solution to a classification problem, and handily avoids the question of "should this go here or here" that any fixed hierarchy imposes (absent links, references, etc.).

If you're using HTYP for specific business issues (and it's customer-facing), that could be a valid argument for keeping it split off. Otherwise, I'm not sure I see the need for a distinction.

CWRE as a project within Issuepedia seems like a slam-dunk to me.

I'm not versed on how Mediawiki projects are set up / supported within a given instance.

Let me see if I can shed a little light on the current situation...

First, there are now two different issue areas under discussion here:

1. whether and how related areas of concern should be separated (separate projects)
2. what the dividing lines should be, as far as content (the original subject of this discussion)

We've been discussing #2, so let me go into my attempts to find other options for #1 and hopefully give you some more familiarity with the MediaWiki solution-space.

Benefits of Combining

Combined functionality would clearly have benefits, but it's important to have a good understanding of what they are so that we can determine the best way to provide them.

Here are the benefits I can think of:

• search across all content -- there is clearly some considerable value in being able to search for any content at all on a given topic, whether it's something technical/objective (HTYP), issue-oriented (IP), debunking (CWRE), related to governance methods (InstaGov), or brainstorming (ICMS).
• single sign-on -- having to create and maintain accounts on three (or more) separate sites is a nuisance
• reduces indecision about where an article belongs -- in my view this actually happens quite rarely, but there are at least a few articles that would be happier in a unified wiki
• better linking between projects -- MediaWiki displays internal links in a different color depending on whether the article exists or not, which is useful feedback for editors. This feature does not work for interwiki links, however... and there is a great deal of inter-project linking.

Need for Separation

It seems to me that there are distinct reasons that one might visit each of these projects, and different sorts of information one would hope to see. Each of these related sites has its own character -- mainly iconography and authorial "voice", but also domain name (and title, where that's not just the domain).

Issuepedia, for example, tries to phrase things in neutral, factual terms except when explicitly taking a position; The Center for Wingnut Remedial Education, on the other hand, gets snarky, and makes use of "meme" images to illustrate both myths and the debunking thereof. CWRE also tends to assume a US context, while Issuepedia assumes only a human context.

This "character" is important for promotional means in (at least) two ways:

• It sometimes results in shorter, more to-the-point URLs. (Need to find an example...)
• It provides hooks for use on promotional materials (e.g. t-shirts) -- which, it must be admitted, I have not yet gotten around to doing...

Also, since each site covers different aspects of many of the same subjects, there would definitely need to be longer URLs in many case, which also creates an issue of how best to organize the conceptual divisions between them. Let's say we combined Issuepedia and HTYP -- right now we have issuepedia.org/US/NC/Durham and htyp.org/US/NC/Durham; if they were combined, we'd need to distinguish the "directory" (HTYP) from the "issues" somehow -- something like hyperpedia.org/US/NC/Durham/issues and hyperpedia.org/US/NC/Durham/yp... or would it be hyperpedia.org/issues/US/NC/Durham and hyperpedia.org/yp/US/NC/Durham, so that we could still search "Issuepedia" by searching hyperpedia.org/issues? It gets awkward.

Means of Separation

keep as now, but provide inter-site functionality

Functions which would benefit from combining all projects into a single site:

• single-sign-on
• search
• anything else?

I'm trying to address the SSO issue via an "identity manager" back-end of some sort. Combining wikis would only solve it for wikis; a back-end solution would allow solving it for all sites, including Redmine, VbzCart, Friendica, and future projects. (It also ties in with my plans for credibility management -- e.g. that users I trust sufficiently in one venue could automatically gain privileges on my other sites.)

As for search, there is a Google function which lets you search across a designated set of web sites; I could probably set something like that up in less than an hour for all my projects. It would also not be terribly difficult to simply write a plug-in to search across all content databases to which I have access, and make that available as a search option. I've occasionally found myself wishing for such a feature, but it hasn't yet reached the point where I was willing to bother with even the hour needed to set up Google Custom Search (I think it's called).

The other major strategy-fork -- having everything in one wiki/database but somehow present subsets in a functional way -- is more difficult; here are the avenues I've investigated:

subpages

The "subpages" concept does help a great deal with organization, but it's also frustratingly limited.

MediaWiki supports "subpages" in the following ways:

• automatic navigation links from each subpage up to the "top-level" page
• "magic words" for parsing the URL into subpage name, main page name, etc.

MediaWiki does not support:

• automatically displaying only the subpage name as a title (e.g. the page /US/NC/Durham is displayed as just that, rather than "Durham" or something more friendly like "Durham, North Carolina")
• an automatic listing or directory of subpages
• searching only within subpages of the current page (though it should be possible to write an extension for this)
• present a "subwiki" (a given page and its subpages) under a separate domain -- though I've gotten close using a "wiki transclusion" kluge (see below); "subwikis" are something I've wished for since the very early days of Issuepedia and HTYP.
• different logo, skin, or site title for subpages

external transclusion

This is a custom index.php file which lets you present the contents of any wiki page at an arbitrary URL, and the subpages of that wiki page as subpages of that URL.

(See gnumusiq.com for an example: at present, it's just a transclusion of a wiki page -- but it does not include any of the "skin" functionality. This could possibly be added, but it may turn out to be technically awkward.)

This functionality is not, however, supported by MediaWiki, and the code necessary to do it seems to change every few MediaWiki versions... which means I have to spend an hour or two experimenting whenever the existing code stops working.

There are other technical issues that would need to be addressed (e.g. at present, any internal links go back to the source wiki rather than staying within the transclusion URL base; fixing this would require adding some HTML parsing ability) if this were going to be used as the primary means of presentation for a major site such as HTYP or Issuepedia.

same database, just a different home page

This is something I almost succeeded at in 2006, although the issue of search functionality remains. It could probably be done.

namespaces

MediaWiki also supports "namespaces", and lets the site administrator define custom namespaces which can then be searched separately. I made a major attempt to use a custom namespace in Issuepedia a couple of years ago, but the results weren't appealing for some reason and I ended up merging the articles back into the main namespace in various ways.

Also, unlike a complete wiki, namespaces don't each have a default "home page".

On the positive side, MediaWiki does support (either natively or via an existing extension - not sure) different CSS styles for different namespaces.

tags / categories

"Categories" in MediaWiki are much like "tags" on blogs such as WordPress. They are organized as an directed acyclic graph.

The main deficit here is that there is no way to search only within a given category, although (again) that could probably be implemented.

Since each category can have an associated content page, we could have (e.g.) an "HTYP" category to serve as HTYP's home page. Category pages automatically list all appropriately categorized pages (including subpages) in alphabetical order, which is fine if you only have a few dozen pages per category but is less useful when you have hundreds or thousands of pages. Of course, HTYP's existing home page is only marginally more useful (showing most recently edited articles, with newest at the top).

import by tag

A variant which would require some coding (with said coding also creating some functionality that would be useful in other ways) is one in which there is a central "commons" wiki where pages are tagged according to which specialized wiki(s) (HTYP, Issuepedia...) they also belong in, and an extension periodically checks for new edits in the commons and exports changes to the specialized wikis tagged on that page.

It could probably work in the other direction as well (detect page changes on specialized wikis, import to commons with appropriate tag added), but there would be some issues to address (mainly preventing edit conflicts).

This would also allow us to (eventually, theoretically) import the entire contents of other reference MediaWiki wikis such as Wikipedia and SourceWatch and could even form the basis of a "distributed wiki" network.

write new wiki software from scratch

While this would be a major project, I find it rather appealing. MediaWiki has a number of shortcomings which really can't be addressed by extensions but which could be done right by a comeplete rewrite, and "subwiki" capability is one of them. Better control over read access is another. There are others. I have already written a crude application framework which could be used as the starting point.

A variant of this idea might be to use something like Drupal, which at least provides things like granular access control out of the box -- but I don't know it well enough to determine if it could solve the subwiki issue, and also I often find it more difficult and time-consuming to learn an existing package than to write one from scratch that does what I need.