[Home]SpaghettiWiki

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Proposal

The other half of MeatballWiki. SpaghettiWiki serves as a less structured, less edited space for Meatball-related discussions. We decided to EnlargeSpace to allow new ideas to germinate without becoming asphyxiated by the deeply rooted structure of ideas already implanted on meatball, and the greater standard of style demanded here.

Connections from spaghetti to meatball are nearly transparent. All of meatball's pages will be available as TwinPages. meatball's RecentChanges will be folded directly into spaghetti's as a UnifiedRecentChanges. Spaghetti falls under the MeatballWikiCopyright, as simply another portion of meatball. On the face of it, spaghetti seems essentially a superset of meatball. Conversely, meatball treats spaghetti architecturally as a separate wiki, with the only technical bridges being explicit InterWiki links. Of course, it's important to note that the common copyright will allow content to move back and forth freely.

SpaghettiWiki has an important difference than most wikis, however. Every page on SpaghettiWiki is automatically scheduled to be deleted, except the timeout period is longer: (one month? three months? one year?) This is because spaghetti 's purpose is to be a separate space in BrainstormMode -- even possibly being many pages wide, unlike what's allowed on meatball --that are just too immature to place here.

SpaghettiWiki also alludes to spaghetti Westerns, those laughable and extremely stereotypical Westerns shot in Italy. Take the space as the "frontier" compared to the otherwise "civilized" space of meatball. This could either be good or bad; it's certainly more interesting, so take it in good fun.

I've been thinking that MeatballWiki needs to EnlargeSpace to handle the more off-beat ideas, but I didn't know how. I've long thought that creating a catch-all wiki would be a good way to get rid of a lot of stupid discussions that don't belong here, but I didn't want to create another WikiWiki disaster. After I came up with the idea of BrainstormMode, the idea of making a wiki with all the pages in BrainstormMode hit me as a great solution to the problem. It affords space and audience to those who just want to throw an idea at the wall to see what sticks, and it allows MeatballWiki to tighten its CommunityExpectations--a direction that I have to say I want it to go and I suspect would be helpful for those of us who do the more serious wiki development. However, the separation between the two spaces is not a Chinese wall, but a great way to mentor those new to the wiki world without disrupting those of us already well accustomed to it. After all, content can move freely from one site to the other in the normal wiki way, and the connections are weak and strong in nearly all the right places.

I also think that those of us who want MeatballWiki to be more open would be excellent general editors for SpaghettiWiki, leaving the cold and wet blankets to our more academic MeatballWiki. -- SunirShah

An interesting question is whether we will still UseRealNames on SpaghettiWiki... I'll leave the debate open for the moment; I certainly have some ideas about that. -- SunirShah

Sounds like a good idea. So, the pages there would be deleted after a few months of inactivity? That way we don't have to waste time editing it so carefully? Like a /Talk section for each page? Concerns to be worked out:

-- BayleShanks

I think keeping notes on your homepage is currently enough. Perhaps the only thing to do is to put up more GuidePosts, streamline our Newbie introduction. We worked on a HowTo. We worked on a StyleGuide. We gree newbies creating a HomePage. What pages do newbies read? Maybe RecentVisitors. If so, what points them there? Clearly the editing of RecentVisitors and the creation of your first homepage was once considered the "initiation ritual". Wherever this is explained to new visitors, there would be the place to explain how we like essays, and keep brainstorms on our homepages, for others to read, and comment, but not yet ready for a real page.

Explaining SpaghettiWiki seems too complicated. And what am I going to do myself -- should I read SpaghettiWiki recent changes? If I am going to do that, then I might as well welcome newbies on MeatballWiki, since I'm going to read their RecentChanges and their new pages anyway.

The separation should serve a purpose. At the moment it seems that the purpose is "we want to create a high-quality site". With SpaghettiWiki, the purpose would be "we want a high-quality site, but you can post over there and work on your ideas and some of us will join you there". That's weird. I foresee a future where there'll be two wikis, one for brainstorming, and one for high-quality pages, and they will drift appart as their communities grow appart. If the communities do not grow appart, then the two sites will be very similar to each other, and therefore the entire experiment will have served no purpose.

-- AlexSchroeder

I dislike the name because SpaghettiWiki makes me think of link structure (similar to Wiki:SpaghettiCode, contrast HubAndSpoke) rather than spaghetti westerns. How about RawMeatWiki? ? What MeatballWiki pages and discussion should be moved to SpaghettiWiki?

SpaghettiWiki is an example of TransClusion. -- MartinHarper

In response to Alex, above...

As you know, I loathe to create new TechnologySolutions for social problems. However, I don't see the problem as being entirely social. There are social dimensions to the problem, such as the growing pressure to expand our scope now that wikis are popular due to TheWikiWay and the necessity to invite participants with a wider range of skills and interests (lest we die through GroupThink). Unfortunately, our ability to cope with these new challenges has been confounded by the landscape of this wiki. If you recall, we opted long long ago to only provide one layer to the wiki, and thus put pressure on us to keep the site well edited, not to mention allowed the community here to have a very strong sense of CommonContext. For the first two or three years that worked fairly well, but we have had a lot of arguments here on MeatballWiki about direction more recently.

Consider the TourBus, which only barely stayed here, and OneBigWiki, which did not. We almost dropped Chris's PeriPeri write up because it was so confusing, but Jerry came to the rescue. We lost Lion's write up. Now, Lion was less inclined towards BarnRaising than Chris, but that doesn't mean that MeatballWiki didn't suffer a loss when he left. Another good example is CraoWiki, though I think the existing situation is probably nearly optimal (minus the bridges that we haven't had time to construct).

You might suggest that these two problems are different classes. We have on one hand space issues; where should the project go? And on the other hand, we have editing issues; how do we integrate the ideas? And while SpaghettiWiki specifically attempts to address the latter (though, brainstorming, see [below] for another solution), I think both are heavily impacted by the same architectural considerations. We've known about these problems for a long time; within the first year we had already identified RecentChanges as a bottleneck to growth. And really, one of the main problems with the rapid "braindumps" is the flood on RecentChanges (i.e. due to a ForestFire). The other related technical problem, of course, is dumping a lot of crap into the PageDatabase all at once, which is already overfull of crap. Because we only have one PageDatabase, it's compendium is a precious resource that needs to be carefully tended. However, when first developing an idea, you may not know exactly how your idea fits into the corpus, but there is no space to experiment.

Then again, as you mention, what would you do, Alex? Well, besides myself, you are the one person here most interested in restraint, good style, and editorialship. We are the cold & wet blankets that keep this place from burning down in a ForestFire, to carefully mix metaphors! However, good editors are a short supply (cf. your ReworkingProblems). I'm personally fed up with chasing after people, and it really goes against my fundamental desire to let people express themselves. It's too emotionally draining; I hate it, and I hate coming to MeatballWiki to waste an hour working on other people's ideas. It also really--to me--indicates a failure on our ability to organize. Sure, often these people need to learn how to write, but it's better to let them finish thinking before we get onto the hard task of editing. Editing too early undercuts the creative process; hence, brainstorming theory.

Your suggested solution of using your namepage is not sufficient. First, it's too cramped for most people who like to abuse hypertext. As much as I'd like people to be as linear as I am, that just isn't how the world operates. Second, it's not a very good solution because it disrupts the FrontLawn and MessageBox aspects of the namepage. Third, it's a really bad solution because it doesn't help evaluate how the new mini-corpus will ultimately mesh with the PageDatabase. For small ideas it may be sufficient, but there are also big complicated ideas that people don't know the shape of before they write them. And certainly most people do not write like you or me, like zen painters who just emit a well-balanced, clean image at once after much meditation.

But of course, that's the writer's perspective. From the editors? I don't expect you to read SpaghettiWiki. I expect the more experimental people to be the bridge, like Mark and Bayle. I also think that it may be valuable to split MeatballWiki's space up between the two foci of "the wiki community" and "online collaboration theory"; I'm personally mostly interested in the latter (even if I see immense value in the former), which is another reason why we've been having arguments about scope and direction. I'm not too worried about not keeping track of everything. I haven't really been up to speed since I left for Europe, and I certainly don't pay attention to everything now that school has started.

Finally, as for ease of use, there are lots of ways of improving usability of this. Note that new users wouldn't automatically be expected to know where to put their material. As editors, we could politely indicate to them as such. That's our role. Though I might envision navigation aids, such as a nice navigation banner now at the top of all the usemod.com wikis with all the pretty logos and the simple instructions "SpaghettiWiki: Brainstorm... --> MeatballWiki: Discuss... --> UseModWiki: Develop..."

So those are the forces I am trying to resolve. -- SunirShah

FractalWiki, another solution?

Now that I've elucidated more of the forces that need to be resolved, I can see that there are two problems:

A better solution may be Helmut's FractalWiki. Consider this scenario. Assume for the moment that OneBigWiki was hosted here on MeatballWiki. We would have one page, OneBigWiki, underneath which we would host all of the OneBigWiki's directories. On the MeatballWiki's RecentChanges, common contributors would only see the listing "OneBigWiki (changes) ..." whenever any page inside the subwiki changes. Similarly, all the TourBus pages could go under the grouping "TourBus". For those more interested in the particular topic, they could expand the hierarchy to see what was going on in that space.

For those who just want to screw around with an opaque idea until it was clear, like Lion's TopicCanonicalization idea, they can create a whole subwiki to muck around in. For those of us who don't care, we would only see that Lion was writing stuff on "TopicCanonicalization", even if he was writing all those other pages WikiOverlap, ProductiveWikiOverlap, IntelligenceFailure, etc.. Eventually, someone who did care would suggest it would be a good time to move (and rewrite) those pages up to the main PageDatabase. To delete the whole mess when you're done, you just delete the one page TopicCanonicalization, and then TopicCanonicalization/WikiOverlap, etc. would go with it. That way, the whole ball becomes a giant BrainstormMode.

Of course, this solution brings us back to SubPages, and we have lots of reasons to loathe SubPages. But I think maybe we've run the course with a flat namespace.

This solution also avoids the political problem of having an "elite wiki" and a "gutter wiki". -- SunirShah

(I am highly aware that this is actually the same discussion we had three years ago regarding SubPages; see Dave's comment on SubPage.)

Does the idea that I have over at WikiWeblog fit in here? Creating the FrontPage that you desire, along with adding rss pages of whatever pages you want to have be part of the recent changes (via something like NewsIsFree?)? Best, MarkDilley

ChrisPurcellsSpaghetti? idea, which became PageClusters, first mentioned here

re: comment on SunirShah's page, I'd like to note that although I presented concerns, I think the idea is good and we should try it.

After reading the above, it seems to me that many of the proposals (the SubPage/FractalWiki thing, MarkDilley's suggestion, ChrisPurcell's suggestion) are aimed at decluttering RecentChanges. While obviously the two are deeply related, in my mind decluttering RecentChanges is separate from what I see as what SpaghettiWiki would help with.

Which is, enlarging the space in terms of allowed style/rawness of content. Along the lines of SunirShah's focus on allowing a space for brainstorming, and allowing a space for "community", talking, and bouncing small ideas around as opposed for essays.

thesis

the problem we are having right now is that there is a need to "protect" the timeless page database of Meatball from cruft. The problem is that brainstorming, offbeat ideas, community talk, and newcomers' getting used to the system is what the cruft is frequently composed of, and these either aren't things we want to get rid of, or editing them without being blunt and destructive just takes too much time.

A SpaghettiWiki, if it works, might allow us to direct some of the cruft into the spaghetti side. Because this is clearly not in the sacred part of the page database, it needn't be edited into timeless perfection. This will

1) allow more space for (/prevent some arguments about) brainstorming/newcomers/talking

2) keep the sacred part cleaner

3) save us time because there will be no need to edit a lot of this stuff

SpaghettiWiki would save us time by removing pressures to edit certain things. Stuff on the spaghetti side wouldn't even appear on the meatball side's RecentChanges, so RecentChanges clutter is reduced. The changes that did appear on the meatball side would be the only "important" ones from the point of view of protecting -- no longer would we feel any pressure to look at every little change, lest something good about the sacred page database be lost or modified. We would feel this pressure for changes on the Meatball side but the Spaghetti side would just be discussion.

on RecentChanges

If RecentChanges clutter itself is the problem, though, then to me there are better ways to deal with it. I feel that RatingGroups is one of the most general/powerful proposals. RatingGroups would essentially allow users to subscribe to custom-made RecentChanges filters.

RatingGroups subsumes the functionality of the subpages idea for this application; instead of making a sub-wiki for OneBigWiki, one could make a OneBigWiki RatingGroup whose charter is to "filter out all changes in the OneBigWiki subset". If RatingGroups was sufficiently automated (as it should be), there would be some OneBigWikiRatingGroupControlPage with a list of the set of pages that is considered "in the OneBigWiki subset", and which creates a RecentChanges filter than lists everything but OneBigWiki stuff. Then individual users could "plug into" the OneBigWiki RatingGroup, and their personal RecentChanges would cease to list OneBigWiki stuff.

RatingGroups is similar to Mark's idea; instead of using an RSS intermediary, the mechanics work differently (instead of "creating a FrontPage" you "create/join a ratingsgroup", instead of "adding RSS feeds" you change the filter for your ratingsgroup somewhat). But the end result is a custom-filtered RecentChanges.

RatingGroups would take a little programming effort, but I don't think it would take any more than implementing fractal SubPages for RecentChanges (at least to implement enough of the RatingGroups to do what is described above).

Of course, as long as we are talking about major wiki feature additions, I think the first thing to do would be to implement a PublicScript / CommunityProgrammableWiki -- something where the Meatball community could add and more importantly tweak features like RatingGroups or FractalWiki by a consensus/wiki-like process, rather than the current setup where the Meatball ScriptDeveloper? would become a bottleneck through which all proposed customizations would have to flow. This would allow us to experiement on new features piecemeal and incrementally, rather than discussing a new feature a lot right now and then not being able to change it for a long time (because the ScriptDeveloper?, currently Sunir, would presumably not have the time or the inclination to always be overhauling the script, especially when it came to features that he is not personally excited by).

more concerns

I also think that it may be valuable to split MeatballWiki's space up between the two foci of "the wiki community" and "online collaboration theory";

Do you mean Meatball's own wiki community, or the community in general? If you mean Meatball's own wiki community, then I agree that some banter would usefully be moved onto SpaghettiWiki. If you mean the topic of "the wiki community", then I don't think it should be moved onto SpaghettiWiki (example: the ChangeAggregator page is mostly a useful list of currently available tools, which is not timeless and doesn't have much to do with online collaboration theory. Yet, I would strongly argue that it would belong on Meatball as opposed to Spaghetti.).

If you did want to focus on a certain subset of the topics that are currently discussed here, then the solution would be a complete mitosis, not a structural change or addition. There is nothing about "the wiki community" as a topic which requires a different structure from the topic of "online collaboration theory". If you have two sets of people with different topical interests who don't want to see each other's changes, the natural solution is a completely separate wiki (although, if the topics are closely related, the futuristic RecentChanges filtering ideas might be more appropriate once they're implemented).

evaluate how the new mini-corpus will ultimately mesh with the PageDatabase

I don't think that SpaghettiWiki will be a good home for entire subprojects or for larger clusters of pages. It will just be too much effort to graft an entire structure from the spaghetti page graph to the meatball one (until the maturity of a WikiRefactoringBrowser tool, which seems far away). I am thinking it would do better for paragraphs of text, threads, and ~1-4 page clusters.

And, I think the best way to evaluate how a mini-corpus would mesh with a PageDatabase is to actually do it. Everyone knows how they think some text would mesh; but the process of meshing it may bring up new ideas, and will expose conflicts in different people's unspoken ideas.

summary

I think SpaghettiWiki is a good idea and should be tried, and I think it may or may not solve the problems discussed above in the thesis section of this post. I do not think it, or the other things being suggested, is the best available solution for the goal of filtering RecentChanges. I am, as always, gung-ho on RatingGroups. I am still wary about the presence of a SpaghettiWiki being a catalyst for a restriction in the allowed topics and styles on MeatballWiki, but I think that can be avoided if we try. I feel that the prevelance of undesired topics and styles on MeatballWiki may decrease voluntarily/naturally if there is a SpaghettiWiki. If not, we can always stop the experiment.

-- BayleShanks

To be clear, I didn't mean to split the corpus of MeatballWiki. I meant split the people. I don't have time to keep up with wikis any more, nor am I overly interested in wikis right now. I'm more interested in the general problem of online collaboration, mostly since that is what my Master's degree is in. That was the original formulation of the MeatballMission, if you recall. Speaking of which, there is this strange desire to call all the general organizational problems WikiFoo (e.g. WikiLifeCycle, TopicCanonicalization). I've been meaning to upgrade GoodLinkStyle to ColdBlanket this tendency.

However, the original formulation of SpaghettiWiki does not solve the problem. The FractalWiki solution seems closer to the mark. -- SunirShah

We've kept RecentChanges less volatile by deterring the more enthusiastic from doing too much at once, essentially moving them to other sites. I use PeriPeri as my SpaghettiWiki, for example. I keep up with FractalWiki (have its RecentChanges page bookmarked), and any project whose page I see update on RC. I like the ideas proposed above because they keep this model, albeit as an illusion.

I don't feel protecting the page database from cruft is such an issue, myself. I'd rather cruft was kept off, not posted on a spaghetti. My take on the problem is to allow people space to flesh out their ideas, without making them feel second-rate while they do so. I'd be far happier moving some of my finished pages from PeriPeri if I could file them under a spaghetti: I feel they are part of the FacetWiki page, but I don't want to traumatise RecentChanges more than I already have.

On RatingGroups: Trying to let everyone do what they want but rate the bad things away will only work when the old members have nearly as much energy as the new. It will deter enthusiastic people away because they think nobody is interested, while actually they are just waiting for the brainstorm to settle down and are preserving RC. My idea of relevant/interesting is not yours, so I probably don't want you to filter my RecentChanges about third-party pages :)

In contrast, the above lets the author hide his work voluntarily, so his energy works for us. I can keep up with any project I like, when I like. It stays hidden until the author chooses otherwise, so we don't need to keep voting the changes off RC.

I also suspect RatingGroups will require huge changes to the underlying engine. You need to add extra places to store this information, tools to see who voted down what (to defeat evil manipulation), ways to combine different ratings filters, forms to vote on... Adding spaghetti will be cheaper: if a page starts with a link, follow it to see if that page starts with SpaghettiWiki, and if it does just divert the logging to RecentEdits? and the project page.

As an addendum, I suggest that we make changes to a spaghetti come up as a modification to the root project on RecentEdits?, not RecentChanges. This lets the project page be a status log, giving a feel for what's happening without having to trawl through the spaghetti. -- ChrisPurcell

I am convinced now that using the homepage is not enough. What I'm not so sure about is this: What significant difference is there between the new proposal (fractal wiki etc) compared to subpages? As far as I am concerned, subpages are a failure, nobody used them except for /Talk pages. At the moment I don't think that a long RecentChanges would bother me. I can skip all TourBus and CraoWiki changes without problems. I can also handle pages marked as "Please hold" or "Work in progress". What I think matters is my idea of "on-topic/quality": When I see something that claims to be on-topic and finished, then the PeerReview process starts in earnest. And to some that might feel like a ColdBlanket. -- AlexSchroeder

I agree with you on the importance of the OT-issue. That's orthogonal to subpages. I don't agree about subpages (let's not talk about fractality for the moment). Subpages are a form of structure that one has to get used to. If you don't have them, you can't. You can look into BücherWiki, TolkienWiki or DseWiki (index) to see a number of good used for them. -- HelmutLeitner

What significant difference: [About my suggestion] The pages are in the main page database. They are a single edit of one word away from being out of the spaghetti and into the meatball. They are a very visible mark of project, but done in traditional Wiki way, not hierarchic. Small but important differences.

I personally would be happy just advising newcomers to mark their pages "In progress (xxx project)", but can see advantages to the hidden-iceberg idea. As I see it, we're trying to solve ForestFire by "recanning the worms" on a whole swathe of pages at once, rather than on a single page.

Alex and Bayle, why do you feel the home-page is insufficient for bouncing around small ideas? I have thoughts here, but I've yapped on enough already. -- ChrisPurcell

Sunir's argument convinced me: 1. Not enough space to express ideas that require several pages (after all, this is hypertext, therefore some ideas might require a set of interlinked pages to express something complex), and 2. the homepage is also for leaving friendly notes and it acts as a FrontLawn, therefore using it in BrainstormMode is overusing it. Check BayleShanks' homepage. It is crammed full with stuff. Where would you leave him a note? It is too big. -- AlexSchroeder

At the bottom. And it's not as big as Sunir's! But this is why it's no use for brainstorming. Why is it no good for bouncing around small ideas and comments? I find diff/Version makes it quite possible to follow ThreadMode as found on a home-page. Is that just me? -- ChrisPurcell

My namepage is a disaster. As it implies on Wiki:SunirShah, it's a reflection of my life. -- SunirShah

One problem with hiding pages is that lack of visibility violates our SoftSecurity principles, although I suspect that I really should write a new pattern VisibleChange? to encompass the following:

Though perhaps UserInterface improvements could be made. -- SunirShah

It's important to understand that the two forces of editing and free expression are BalancingForces. They can never be resolved, but we must choose the fulcrum. Currently the system is off-balance, pushing people off-site. Often when teeter-totters fall off balance, both actors are affected: would-be contributors (like Lion) and long-time contributors (like me). -- SunirShah

Adding structure must be done with care. It will shape the text. We have a flat hypertext because that is the simplest choice, the one with the highest FeatureKarma. Affording hierarchies will create hierarchies. Hierarchy is ugly because hierarchy is weaker than hypertext. Hierarchy forces you to make an imperfect decision where something belongs, and then mediating your interaction with that something through the structure of the hierarchy. Placing a page underneath another says, "this page is second class." It can only be accessed through its parent page. Who is to say that I don't want to refer to that concept directly? We use SubPage syntax, but that is ugly because it is a reflection of a broken topology. SubPage syntax says the parent page is the important idea, and the subpage is only a small idea. InterWiki syntax is similarly ugly because it is the same syntax. Wiki/SunirShah and Wiki:SunirShah are only different in punctuation marks.

TwinPages and SisterSites are nice ideas because they reflect "AccidentalLinking", as mythological as that is. The basic idea of having no special syntax, but having WikiSyntax transform plaintext, is closest achieved by the GaGaParser, and next by "AccidentalLinking". SisterSites break through the mismatch of hierarchy by cutting out the parent page, the middleman, and going directly to the children.

Could we in principle follow this model? Can we not think of the subwikis as separate wikis entirely, connected to the main wiki through our InterWiki system? At first, the syntax would remain unified, if potentially ambiguous. TopicCanonicalization:WikiOverlap instead of TopicCanonicalization/WikiOverlap. Alternatively, following AutoLinkStrategies, we could link directly to WikiOverlap, which will automatically discover TopicCanonicalization/WikiOverlap.

But is this the right answer? Autolinking is an invisible mystical fragile process. I could create another subpage to work on my contribution: SunirShah/WikiOverlap. Which page would win? I don't want the system to compute an answer; I want to tell it the right answer! We could follow WikiWiki's example and let both win, through an indirect page, even if potentially more tedious for the user. But then do we really want to make all those innumerable pages first class? That is after all the point of hierarchy. To limit scope. -- SunirShah

I currently prefer the pure management without technology solution, since as I said, I don't consider big RecentChanges nor boring categories a problem. (To reinterpret the past: I did not mind the TourBus, I minded the spurious creation of shallow pages.) The only thing I want to change is the cold blanket effect I seem to having on people. Therefore, the only thing I need is an indicator "Please hold, I'm working on this." Even if we all forget about this, I won't mind. Because when I happen upon the page much later, I will be able do what is right by looking at the page history and the "Please hold" tag. So adding the "Please hold" concept to the intro is one of my priorities right now. -- AlexSchroeder

I haven't digested today's comments enough yet but I'm going to go ahead and speak anyways because this is a conversation, rather than a permanent document. (this conversation would be a good choice to move to the spaghetti side, as it was originally envisioned).

The part about the original spaghetti idea that I thought would work best was having parallel pages to those pages which are here, to say things in a way that wasn't meant for timelessness. Then those discussions and ideas could be refactored and added to the "real" page. I still like the original idea.

I still don't feel that much is gained by having a subproject be "invisible" from RecentChanges and then suddenly become visible later. If the subproject was unacceptable or controversial at first, how will it become less so by being expanded upon by its enthusiasts? You are just delaying the editing or the conflict. Also, when the subproject is finished, it will still be a WalledGarden because it would be silly to add links on sacred meatball pages to ephemeral spaghetti pages before the subproject is "ready". It will be that much harder to graft the subproject into the link graph because the subproject will be bigger. I feel as if maybe some people are thinking of an example in their heads of the kind of subproject that would benefit from this, and how/why it would; what is that example?

I sort of like the idea of allowing an author to say "my project is not central enough to be on RecentChanges", but I also feel that this is balkanizing the community in a messy way. If we want to have lots of subprojects, let's just put them on different wikis. Let's have a WikiFarm that hosts lots of wikis under the rubric of the "meatball project". We can have one for collaboration theory, one for discussion about wiki, one for tourbus, and then MeatballWiki itself will be the incubator for new project, the place for discussing the "meatball project" as a whole, and the miscellaneous section. We can have a UnifiedRecentChanges, a copyright that allows one to move text between them, and TwinPages.

I think it would be cleaner to start with a bunch of wikis and unify them than to start with one wiki and try to make it some sort of metropolis. Not that the latter can't be done, but I think changes like require out visionary, powerful new frameworks, such as PeriPeri or FractalWiki or total syndication or ViewPoint style filtering. I think if we want to make piecemeal changes, the one-wiki-with-many-parts will be too messy; FeatureKarma problems.

Also, I still feel unclear as to whether people want:

1) To EnlargeSpace vis a vis proper style and brainstorming, or

2) To have less to go through on RecentChanges, or

3) To spin off different topics (or communities)

I feel that (1) requires some sort of creative solution like the original spaghetti idea; (2) requires us to think in terms of filtering (whether it is the author who filters or the readers), and (3) is best served by mitosis; moving some content to new wikis.

I can't tell which ones you guys think the problem really is. If I had to guess, I'd say it's (3); the "online collaboration theory" stuff has the potential to be very essay-like, whereas some of the other topics don't (most notably, my chief interest, which is new technological ideas for collaboration); perhaps this causes frustration at not seeing enough essays.

Personally, I don't have any major problems with the way things are going and I don't need a change. I would prefer to have more power to filter RecentChanges, but it's not a dire need. But I think it would be neat to try the original spaghetti idea. -- BayleShanks

As for homepages, I think they do allright for discussing new ideas, although it may be better to allow each person to have a few different "homepages", i.e. a personal one, a brainstorm one, a personal diary one, a personal notes one, etc. I don't think there is a problem there. But, I feel that if you have a new idea that is related to an already existing page, you should put it on that page, not your homepage, even if it is "brainstormy". The point here is to have collaborative brainstorms, after all (the word "brainstorm" is getting kind of annoying to me, btw, but I can't think of anything to replace it). -- BayleShanks

I like that. It would be trivial for me to host a few more Oddmuse wikis at the same company that is hosting emacswiki.org. Do we want to go that way? It would solve my (tiny) problem, I guess. All I'd need would be a domain name (unless we want to use emacswiki.org, haha). Any suggestions? -- AlexSchroeder

In TwinWikiForAds the authors suggests some additional options:

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: