[Home]TopicCanonicalization

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Most sites have a notion of what is "on-topic" and what is not. Sometimes this has been written down on a particular place . We call this a MissionStatement. Often an OnlineCommunity will also have a notion of where particular bits of "off-topic" content should go.

This page discusses movement of content from communities where it is considered "off-topic" to communities where it is considered "on-topic". In particular, it focuses on wikis which facilitate this action in ways other software does not. The basic assumption is that there is usually one particular wiki where the particular piece of content fits best; that there is a canonical wiki for every piece of content. In practice, this assumption is very false, but there may be best wikis where particular pieces of content fit.

This page also discusses the limitations of this concept. Sometimes content is duplicated on a particular wiki, and there are not enough reasons to actually delete it on one of the two. Sometimes content is very similar to existing content on another wiki, but the fact that a local community member wrote it is somehow important to the community.

This page also illustrates all the comments made with some examples.

Contrast TopicCompetition for another related problem.

Mission Statements

Every wiki should have a positive assertion on what is on topic. This not only helps determine how well new pages are received, it also helps to attract more contributors from other communities with off-topic content that might be on-topic here. Mission statements can be rather vague like the MeatballMission, or they can be rather concise like the EmacsWiki:MissionStatement.

Pointing to other wikis

Wikis can point to other wikis in a effort to prevent off-topic pages, or as reference when community members point out off-topic pages to new contributors. On Meatball, these redirections are not codified.

When a user posts something here on religion, we point them to AndStuff. If someone posts something here on Emacs, we point them to EmacsWiki. If someone asks a technical question about UseModWiki, we point them at UseModWiki. Book reviews to BookShelved. French discussion to CraoWiki. But this is already an informal process. TheCollective just knows better places to write certain things, or at least that certain things are off-topic. Frequently we send them to SeedWiki if we don't know any better. I don't see how this process could be improved, especially since off-topic posts are an unconstrained domain. -- SunirShah

I don't see how this process could be improved -- I think that having a standard practice of where people can find out where they can find places to add their content will help us (wiki community) in the future. It would be easier to say go to the WikiNode to find a proper wiki to place your content. Thus we don't need to depend as heavily on one of us knowing exactly where to send people. We can send them to SwitchWiki and they can figure it out themselves. -- MarkDilley

On other wikis, this is part of the introduction to newbies. The EmacsWiki has a list of alternative wikis on its EmacsWiki:HowTo page.

Future developments in pointing to other wikis

The traditional way of pointing out other wikis is a list of wikis, with a short description of their mission. As the number of wikis grows, richer visualization tools will be necessary: Hierarchies, graphical maps, network descriptions.

Facilitating contact with other wikis

One of the technologies used to refer to related content on other wikis are InterWiki links. Another is SisterSite, which offers links to identically named pages of "sister" wikis.

Difficulty of determining boundaries

There are always cases where determining the most appropriate wiki is not possible, and there are certain tendencies to add content to wikis even if it is off-topic.

Sometimes eventhough a well-known canonical wiki exists for a particular piece of content, it will be added to another wiki, potentially off-topic. An example would be a book-review of BeyondFear being added to Meatball instead of BookShelved. If the author is only a member of one of the communities, there is a natural tendency to add content to your own community. In order to reduce overlap, the general aspects of such a book-review could be moved to BookShelved, while the community-specific aspect remains on Meatball, a solution explored in ProductiveWikiOverlap?. The reason the off-topic content appeared in a wiki was caused by the author not belonging to the community of the canonical wiki. This kind of situation will be unavoidable, because authors will never be members of all relevant canonical wikis. If editors belonging to both communities feel like fixing this, they often find themselves confronted with a CopyrightTrap. Resolving this kind of problem is hard.

Sometimes pages are written in a style that make it very hard to add conflicting view points. Perhaps the argument is well made, perhaps it fits the mindset of the collective particularly well. In the real world, where space is a constrait, this causes tension. On a wiki, you can just create a new page to present dissent. This pattern is called EnlargeSpace. This technique can also be used by people that want to present related content that doesn't quite fit on the original page. In some cases, this can lead to off-topic content being added to the wiki. It is important to realize that this particular content cannot easily be sent to another wiki, because it arose from a social conflict due to another page on the same wiki. Its only purpose is to EnlargeSpace in order to relieve tension.

Right to fork facilitates competing wikis with similar mission

The RightToFork implies that a wiki PageDatabase can be copied, and the copy will be just as good as the old one. The deciding factor, as discussed on the RightToFork page, is the effect on the community. If there was dissent before, splitting the community may reduce internal tension and lead to more productive environments. However, it may have the effect of creating external tension between the newly-separated communities.

The accumulation of objective knowledge will also suffer, as the MindShare? of the two new communities will be smaller. This reduced MindShare? has been identified as the main reason forks in FreeSoftware do not happen often, even though the RightToFork is guaranteed. When forks happen, they are often very traumatic for the community, eg. the Emacs/XEmacs fork, see EmacsWiki:EmacsSchism for links to some statements by the parties involved and note aggravation on both sides (ignore the technical discussion).

Keeping content because of emotional investment

Sometimes content is "on-topic" only because a community member wrote it. An example for this would be some Python advice being stored on the Seattly Python Wiki [1], eventhough it would fit just as well or better onto the official Python Wiki [2].

See also RadicalInclusiveness for a discussion of MeatballWiki's canonicalness.

What is wrong with canonicalization

TopicCanonicalization, like any top-down structuring organization really irks me. The Internet succeeds by being a FreeMarket?. Each person or group may form his or her own space that represents their values (cf. EnlargeSpace). Those spaces compete against other similar spaces for attention in the so-called AttentionEconomy?. This provides the back-and-forth to provide the necessary pressure to keep things progressing and to keep things sharp. The RightToFork is another such pressuring tool, but only insomuch as it similarly violates canonicalization--and it is a contradiction that is described above as part of the process.

The human species needs competition and overlap in an open-ended, unconstrained, free way in order to develop new ideas. cf. TheFutureAndItsEnemies?. Canonicalization would fail for the same reason Communism fails. While in an ideal Marxist world every person is identical, with the same values, and an unemotional detached collectivist perspective, reality is so much more enjoyable than that. Prescriptive, top-down structures fail to capture the drive to innovate, the emotional investment that is derided above. Understanding that people are not machines or object encyclopaedias to be data mined is critical to understanding how group projects function.

Failure modes are multivarious. First, it puts responsibility on a canonical wiki to be canonical. It must accept the whole world in its space which may counter the original founders' motivations for creating it--i.e. to create a new, separate unique space. Further, no one has yet discovered meaningful ways to accept the entire world's perspectives in one place. Normally this requires some form of forcing concensus, which is evil (literally); pluralism demands a more contingent multiplicitous approach.

Second, the canonical wiki may not be up to the task. It may be controlled by a GodKing, or the wiki server may fail, or the wiki community may change its focus--its concept of "topicness". Malfeasance and errors are why every other endeavour on earth, human or ecological, is undertakenly competively and redundantly. That's simply evolution theory.

Third, there is no such thing as an ontology. Modernism is refuted. Get over it. You cannot carve out some range of knowledge space and say it belongs here or there. I'm taking a library science degree; I hear about the politics of catalogues weekly. No ontology is correct. No ontology is value neutral. No ontology is static.

Fourth, similarly, content is not apolitical. Even the NeutralPointOfView (NPOV) is bogus, but its style conventions afford NPOV content the best fit with other NPOV corpuses. Most text is not neutral and intended to be anything but neutral. People's opinions fit within a context (cf. WhatIsContext), which includes values and perspectives, that do not exist elsewhere. For example, moving MeatballWiki's text to a place that believed more strongly in HardSecurity would be discontiguous. Furthermore, content is not disconnected from its authors. The emotional investment is the critical impetus for content creation in the AttentionEconomy?. Watering down people's contributions so they fit into some canonical mold is first very political and second totally the wrong direction. WebLogs exist for a reason. Wikis mute individuality only insomuch as to foster superordinality.

I recognize some of this is described above, partially because I contributed to the above, but I just felt that the positive reaction to this concept of canonicalization, not just within wikis but also within WebLogs and the Internet as a whole, deserved a frigid ColdBlanket in response. -- SunirShah

Thank you, Sunir, I think you've stated my own feelings pretty closely. -- ChrisPurcell

Paradox named Life

I think we are so trained to think methodically that we dislike paradoxical situations, but they are the essence of life. It's natural to avoid redundancies and look for best places for contributions. But if we would make this a strict law we'd get all types of problems. On the other hand if we put no order into systems, some people would sing their basis-anarchical halleluja but communities and cooperations would fall apart. There is no way but to get along with this paradox and seek for order as long as it makes sense but refrain from such principles if other things get priority. Bad news: There is no way to follow a rule and stop thinking! -- HelmutLeitner

"A wiki is not a tree"? (http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml)

Top-down?

How does TopicCanonicalization require:

Do people force blog readers to read popular blogs?

Do people force wiki readers to come to Meatball to discuss meatball issues?

What tree does Meatball hang from?

In IRC, you shift from "#wiki" to "#moin" to talk about MoinMoin, rather than Wiki. What government agency forces, or even suggests, that movement?

-- LionKimbro

From http://dictionary.reference.com/search?q=canonical I get: 

 ca·non·i·cal

Hence the confusion perhaps.

I suggest an ideal opening task for your WikiNodes project is a case study, Lion. Find a heap of Wikis, look at their mandates, and pick a bunch that are conceptually "close". Learn about their communities and their existing page database. Then decide how they could best relate/link to each other with your scheme. Put your thoughts and conclusions on a Meatball page, and we'll all have something real and useful to think about and comment on. (I recommend picking a good name - or discussing a good name first - so we can mentally filter it out of RecentChanges.) -- ChrisPurcell

Great idea. There aren't many that are "conceptually close" by easily connected path. If you know of some good ones, please let me know. I'm thinking of making no.wiki.taoriver.net (as in "no wiki exists yet") to help glue WikiNode space between, say, [the Zshell wiki,] and, say, [the Tcsh wiki.] There is, presently, no "shell environments wiki" to logically connect them. Put another way: I don't think anyone would go to the Tcsh wiki expecting to talk about Zshell, or vice versa. However, people on the Tcsh wiki would be interested in a general shell scripting wiki, as would Zshell. In the other direction, general scripting would point both to Zshell and Tcsh. http://no.wiki.taoriver.net/moin.cgi/ShellEnvironmentsWikiNode would hold a placeholder WikiNode, suggesting the existance of a wiki that hasn't been created yet. When the wiki is created, the placeholder points to the actual WikiNode, and the neighboring wikinodes are repointed to the actual wiki as well. -- LionKimbro

Have you read http://www.rudi.net/bookshelf/classics/city/alexander/alexander1.shtml? It seems you are suggesting a semi-lattice design, not a tree. It might be useful to settle on that terminology (c.f. "graph") if that is so. We can then discuss issues within that framework.

In the context of your example, the Tcsh and Zshell wikis intersect in (general) shell scripting. The semi-lattice property says that this concept should exist, though we may not have a Wiki for it. You may find that general shell scripting is not a useful concept to base a Wiki on. I would assert generalities are better placed on a hypothetical Bourne shell scripting wiki. Bourne is what portable scripts usually end up coded in, so if a concept is to be useful, it probably needs to be possible to write it in Bourne.

Let us go further. Suppose we are at the birth of Wiki:ExtremeProgramming, but the only programming Wikis are language-specific. While we might consider a generic programming wiki to be useful, what we actually want is a new wiki for this cross-language idea. Alternatively, we could incorporate within an existing Wiki of related scope, such as one about programming patterns. The logical connections we want to make will then be between tangential, not parallel, Wikis.

Any Wiki whose mission subsumes that of another will have a hard time of it, because it needs to keep up with it. Another alternative to creating a generic shell scripting wiki, or generic programming wiki, is to be more precise and make a generic cross-shell or language-independent wiki, specific to ideas independent of shell/language. In the shell case, as I've stated, this Wiki could just be subsumed into the Bourne one; in the programming language case, we can subsume into a wiki already devoted to a language-independent idea like patterns, if it doesn't object. (Historical note: WikiWiki did, and part of its community rioted over it, then left. Hopefully technology can help avoid that in future...)

Hence I conclude that Wikis should exist for the union of many basic concepts, high up in the semi-lattice. Tangential links should be of primary interest.

Search engines will then be the best way of initially finding the Wiki you want - I may be wrong here, but I understand that a proliferation of tangential links actually makes search engines more useful, by strongly associating a particular site with particular words or phrases. Wikis covering the same topic can link to each other, or not, depending on how tangential they feel each other to be, since different community spirits and the like can rightly be considered a tangent.

What are your thoughts, Lion? (And anyone else, for that matter.) -- ChrisPurcell

I have too many thoughts, and would love to continue these threads. To to avoid digressing from my GoalStatement, though, I'd like to continue this discussion on pages [StructureOfAWikiNodesNetwork,] and [CanonicalPositionDiscoveryProcedure]) at [the WikiNodes wiki,] (or elsewhere,) if that's agreeable to you.

Short answers: I've borrowed ["graph"] from [graph theory.] I need to think more carefully about the definition of "semilattice": A collection of sets forms a semilattice if and only if... However, two things are certain: WikiNodes is not a tree, and it is a graph.

Part of my GoalStatement is to convince key Meatball decision makers that TopicCanonicalization is real, whether we ask for it or not, by the PowerLaw. Furthermore, that it can be harnessed positively.

I think I miswrote, or SunirShah misunderstood what I meant, by use of the word "Canonical." (Which I've been using in the "hacker" sense of the word.) But perhaps SunirShah did understand what I meant, and sees something that I don't. In that case, I, and many others, want to understand how TopicCanonicalization really does mean a top-down structuring organization, strict laws, trees, NPOV, or some other officially mandated point of view. Because nobody I know who is interested in TopicCanonicalization is interested in those sorts of things.

-- LionKimbro

Motivation for founders -- how will you motivate people to actually start a wiki? Take the "generic shell programming wiki" example. I claim that such a wiki will not be created because all the people motivated are already part of a shell project, thus there will be a section of "compatibility with the Bourne Shell" in the tcsh wiki, the ksh wiki, the bash wiki -- but nobody will feel the motivation to pull all these together into a wiki-without-a-project. That's the key point here. No project, no wiki. Basically wikis will only exist on the leaves of our ontology -- never on the nodes further up. All that will ever happen is pointers to related stuff amongst the leaves. Maybe there will be One Page to find them -- but really, what else are you going to put there? And therefore, unless a project pops into existence (a port of the original bourne shell by retrocomputing fans), no wiki will ever be founded for "the stuff all shells have in common." -- AlexSchroeder

Motivation. Let me ask in return, what motivates a founder now? I believe that wikis will be as easy to create, if not easier, as web pages are now. What kinds of things motivate people to create web pages? I suspect it would be something like InternetRelayChat: As a topic is found to gather mass, a new space is made for it: If #wiki is becoming crowded by MoinMoin chatter, the participants of the MoinMoin chatter form #moin.

Leaves. Is Meatball a leaf or a root? The topics of the TourBus project, canonicalization, online government, wiki development, wiki and language, etc. all can be explored better on their own wiki rather than competing for a slice of RecentChanges, namespace in the page database, and restricted to follow the norms of the people interested in the other subjects.

I think each of these "leaves" is pregnant. As they accumulate a mass of pages, still more SubWikis will be found within them. Online government develops a special wiki for wiki government. Since relationships are a graph, the wiki government wiki may also connect laterally to the wiki development wiki.

Pathways. I have explored many paths for [the Subject Life Cycle.] Were Meatball to endorse children, I think it would continue as an active community, possibly further dividing into more children. Supposing, however, that Meatball becomes merely a directory of SubWikis, links would still need to be updated, added, and removed. The directory wiki could still host administrata meta discussions such as deciding how the directory should be organized. Or perhaps it would just die, but that may not be so bad as long as there are healthy progeny.

EmacsWiki. Perhaps EmacsWiki is pregnant; Maybe it could spawn an Emacs Lisp wiki? People don't necessarily ask or demand these things, I think because people aren't used to thinking about wikis. On the Python wiki, people wanted to put the whole Python documentation into the wiki, but others didn't want to clutter Python wiki. Both are reasonable approaches, but the possibility of making a separate wiki for just the Python documentation occured to nobody. People view wiki and participants as limited resources.

If you create an "Emacs Lisp" wiki, people on Emacs wiki may suddenly say, "Of course! Great idea!" On the Emacs Lisp wiki, they would feel comfortable documenting particular emacs lisp functions, as they felt they had more "breathing room." (EnlargeSpace) They could make their own Category tree for Emacs lisp issues, their own structure. I think they'd feel too confined to do so, as it is, on the present Emacs wiki. But right now, the possibility doesn't even occur to people--I don't think.

Conclusion. Wikis are so new, we literally have not thought about everything we can do with them. I've discovered that, upon consideration, there's very little I don't want wiki for. Security of pages? We can make wiki security technology. Privacy? We can even make private wikis, for corporations and militaries. But pretty much everything - every permutation and every interpretation of any idea- can use a wiki, and everything that is public can be integrated into a canonical nodal framework. -- LionKimbro

My point is: No project, no wiki. I think you didn't address that in your reply. You said (once again) how different everything will be, and how nobody has thought of it all. But that's not really an answer to the basic human question: Who will want to do it? Your entire idea of wikis being pregnant assumes that there is some kind of pressure to leave, to start anew -- and I can see the pressure that led to the emigration of MeatballWiki from the more general WikiWiki. But I don't see such pressure to move to the more general. And I don't see pressure to separate Emacs from Elisp. So now we have two hypothesis of mine:

  1. No project, no wiki.
  2. Without pressure, no motivation, no wiki.

-- AlexSchroeder

I think Lion answered your question of motivation here: "The topics of the TourBus project, canonicalization, online government, wiki development, wiki and language, etc. all can be explored better on their own wiki rather than competing for a slice of RecentChanges, namespace in the page database, and restricted to follow the norms of the people interested in the other subjects."

Lion, I suggest you step back, and concentrate on one concrete issue, or maybe two. Postpone any and all discussion of a future built on these steps. Any dissent should be sent to /dev/null. -- ChrisPurcell

My GoalStatement has 3 things in it I want to establish, one by one:

First:

In our case, that means: People come here to talk about wiki community.

(Is this what you have in mind, Chris?)

-- LionKimbro

TopicCanonicalization, here, means that with time, wikis become canonical for a subject domain. -- LionKimbro

That's a matter of popularity, as you argue with the PowerLaw, but you are not accounting for the fact that the PowerLaw distribution is not static. The PowerLaw works precisely because the system is continuously dynamic and competitive. While the curve remains static, the positions of particular data elements are highly motive. It makes no sense to use the terms PowerLaw and canonical in the same breath as canonicalization entrenches, standardizes, and solidifies.

I don't think you are actually talking about canonicalization. I think you are talking about restructuring along topical lines. You are arguing for a much finer-grained structure than people are naturally used to. While I don't disagree with you that people are likely to wait much longer than they should before reorganizing a project, there are real reasons why this happens that are well-known. Splitting a project is very expensive; it requires a lot of investment to go through all the assets of a project and reallocate them to both places. While digitally you might just fork the project, that is not very useful to the reader as you will inherit a lot of material that is not part of your focus that you will have to audit and repurpose or prune. Also, you disagree that people are finite resources, but in fact they are. It is legitimate to claim that RecentChanges must improve as an interface. You will discover five years of literature on that between WikiWiki, MuWebWeb, and MeatballWiki. InterWiki is well-covered and it is not as easy as you think. (Or maybe it is as easy as you think and we haven't thought of it yet.)

The more I read what you are saying, I don't think you are really saying anything all that new, which is a good thing. The new factor is your spin. You speak of inevitability and canonicalization, which are key signals that your idea is wrong. Society is neither inevitable nor regulatable en masse. Don't get caught up in futurism. It is especially difficult to have a real discussion if you base your argument on a the future which has not happened and remains to be proven. Even I don't agree that wikis will become the predominant paradigm, and some might argue that I have the most invested in seeing that happens (even if I wouldn't like that future too much). - SunirShah

(Note: To keep focus, I'm not addressing futurism, the future, and the pragmatics of project-splitting, and people as finite resources. They are interesting, important, and the last two are particularly relevant to this discussion. I'm just not responding because I don't want to distract from this one central thread.)

Great! So, we just been having semantic difficulty.
What should we replace the word TopicCanonicalization with?

So, it sounds like we agree on:
* (what-was-formerly-called-TopicCanonicalization) is real, whether we ask for it or not, by the PowerLaw.
* Delegation of ConceptSpace? to distinct regions of change-list reading is necessary and beneficial.
Is that right? -- LionKimbro

Why don't you read the PageDatabase and find out what it is already called? We've given you a lot of pointers. You're passionate; you can figure it out. You know, RTFM: Read The Full Meatball. -- SunirShah

I've searched the PageDatabase, several times. I have been reading it while I have been here. To the best of my memory, I have not once seen a word that meets:

I've looked at WikiMass, CanonicalizationAndItsDiscontents?, TopicCompetition, PowerLaw, many many pages.

Does anybody know this word? Does anybody?

Supposing the word is not found, suppose perhaps that the word doesn't even exist- does it mean discussion cannot continue?

-- LionKimbro

Try searching for the word namespace. Read the pages related to that. Read Wiki:WikiEmigration. There may be no better word at the moment, but if you can relate your ideas to the others we already understand, even in detailed contrast (you can't just say it isn't X or Y, but you have to explain how it isn't), that would be helpful for us to understand what you think. -- SunirShah

Perhaps we should call it WikiPopularization?: the process by which wiki become PopularWiki for a particular subject at a particular time.

I'm not sure how the definition of this concept requires reference, to, say, WikiEmigration, WikiNameSpace, facets, subcommunity, subwiki, etc.,. This is just a definition, not an exploration of its implications.

If WikiPopularization? is okay-

Then it sounds like we agree that:

Is that right? -- LionKimbro

No, because we have a strong counterexample. WikiWiki is very popular, but it has no subject focus. The process you are trying to describe is an impetus for WikiEmigration, and the solutions given so far include WikiNameSpace, facets, subcommunity, subwiki, etc. While you claim the populations won't split, that's hardly true either, because if I was only interested in Emacs lisp then I would just move to Emacs Lisp Wiki and ditch EmacsWiki. Maybe you are talking about

  1. The motivation: double focus.
  2. The solution: WikiEmigration, WikiNameSpace, facets, subcommunity, subwiki, etc
  3. How the after effects differ: vs. the normal WikiLifeCycle.

Maybe you don't really know what you are talking about... yet. ;) Find an RealWorld example or three. Wiki:RuleOfThree. Maybe you're generalizing from only one case, which is bad. -- SunirShah

I want to talk about those things, but have been told to take baby steps; Let the conclusions come later.

I am establishing: WikiPopularization? is real; It happens.

Definition: WikiPopularization? is the process by which wiki become PopularWiki for a particular subject at a particular time. (And let me add:) WikiPopularization? follows from PreferentialAttachment applied to wiki, resulting in a PowerLaw distribution of reputation of activity.

Are you saying that WikiPopularization? doesn't happen in general, or that it's not common, or that that Meatball hasn't become a PopularWiki for particular subjects, or something else, or is this just semantics again? -- LionKimbro

Popularity is not equivalent to subjectivity. The notion of popular for a particular subject is also interesting. Take Meatball, for instance. How many online communities on the Internet talk about online communities? One and a half. Since online communities are very popular on the Internet, and there is a lot of discussion about online communities, one might surmise that Meatball would be very popular. It isn't. Thankfully.

There is no natural connection between subject and popularity. Some subjects are intrinsically more interesting. Barely legal teens are more interesting than toilet standards, but that won't necessarily mean that your pr0n site will gain more hits than http://worldtoilet.org.

So, is wiki popularization real? The PowerLaw is a very simple curve that generalizes a very complicated system, right? What you haven't described is what makes a wiki go to the top or bottom of the curve. And then when you break it down by subject, the population of wikis drops to below the limit where the PowerLaw applies. There aren't enough wikis in the world to compete with each other within any single subject. That is simply because there aren't enough wikis in the world period. You might do a study of Linux groups or guerilla network projects, but those projects are naturally geographically distributed. What's the difference between PythonWiki and SeaPig? wiki? One is a local user group for Seattle, the other is for Germans. Another study might look at the Wikipedia""s and their forks, but there aren't any interesting forks. One could claim this is because there is no point in forking if you can just contribute to the original wiki. If you are bounced from the wiki, it is likely you do not have the social skills to create a successful fork, or the motivation to recreate a project. Or you could claim that wiki users aren't bloggers, so we aren't very competitive by nature, but that would also claim that wiki user demographics are static; the more wikis there are, the more bloglike they get. Why? Blogs fit closer to the general population because they are more popular, by a factor of ten. -- SunirShah

CategoryInterCommunity

Discussion

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