FrontPage RecentChanges AboutWikiFeatures WikiNode


Ideas to Place

Unpolished ideas about anything go here. If you have the time to write a polished feature description, place it on FeatureSummaries.


Please preface...

feature ideas              with "Feature -"
sources of information     with "Source -"
discussion about the site  with "Meta -"


Feature - RateLimitedCaptcha -

Many people set up a wiki by manually typing in a bunch of literal question/answer pairs. (Such as ).

A few people (such as DavidCary) semi-automatically generate question/answer pairs according to a few question/answer template pairs that slot in a freshly-generated random number every time, and the answer is some function of that random number.

There is a rumor that spam-bots can be trained to automatically recognize some questions, and then plug in the correct answer.

Perhaps it would be interesting to track how many times a particular pair was presented to a user, and of those times how many times the user gave the correct answer:

It’s a lot easier for humans to block 50 spam-bots than a firehose of an indefinite number of spam-bots.


Source - TV tropes wiki: Wiki Tech Wish List has many suggestions for making the wiki better – I suspect a lot of them would also be useful at other wiki.


Source - Oddmuse:Wish_list, suggestions for Oddmuse but maybe some can be extrapolated.


Source -, many suggestions for UseMod but maybe some can be extrapolated.


Feature: (insert cool name here), Most wiki has a way to search for *all* the pages with a category tag. The search returns with a list that shows the *name* of each of those pages. I wish there was a way of asking, not just for a list of the *names* of those pages, but a much longer page showing the first few lines of each of those pages. Sort of a combination of transclusion + backlinks. This is similar to MeatBall:InternalTransclusion and SnippetPublishing, except it works with the “category” system – I don’t have to set up a special “frame” page and manually add #include links to each and every page I want on the list. Instead, I manually add a category tag to the bottom of each and every page I want on the list. For example: It’s a big hassle going through all the (over 1000 !) pages listing all the wiki at WorldWideWiki:SwitchWiki, so people are just listing all the wiki on the 26 “letter pages”. If the above feature were implemented, the “letter W” page would be merely a “view” combining all the individual pages that start with the letter W -- it would *look* the same, but it would have the added flexibility of helping people who want to look for all the “ProgrammingWiki”. Maybe this one additional feature is all that the SwitchWiki project needs; rather than full DatabaseCapabilities discussed at WorldWideWiki:OneBigWikiSoftwareProject . the first few lines – instead of hard-wiring “the first 3 lines”, perhaps better to have “the entire chunk of text above the first horizontal line”, whether that’s 2 or 3 or 100 lines. ( DavidCary )


Feature - MassRevert - Revert back all pages (or pages accessed in the last N days) until the given links don’t appear any more. (LionKimbro)


Feature - MapEditing - Make it so you can construct “map pages,” which are spatial arrangments of pages. A page can back-link to all of the maps it is featured in. Pages on maps can be resized and repositioned. You can put doodles and comments in the map as well. You can make maps of maps. A page could participate in multiple maps. (LionKimbro) Now that I think about it, this is just about having a particular type of page, called a “map”- which allows graphical editing of a particular sort, and that respects linking to other pages/maps. It also has MetaData for supporting the distinction “This is a map, this is a document.” As such, this is probably best considered under the model of CommunityWiki:OneBigSoup. (LionKimbro) Though, we’d like to be able to construct navigation paths attached to maps: You can say, “I want to travel this map,” and have it in constant view as you look at it’s features.” (LionKimbro)


Feature - SpamMop - Automatically undo all changes (diffs) that included a given spam URL, along with prompts for auto-banning the URL, submitting link and IP address to blacklists, and automatic banning (for a specified period) of IP addresses. Priveledged users can run it, non-priveledged users can submit instances for approval. But the key thing that’s called the SpamMop, is the code that goes over the pages, and auto-reverts anything with a nasty URL.


Feature - PageRating - (pretty related to RatedComments?) “Insightful, Interesting, Off-topic, Troll, …” (would work as categories) or even “score: 3.7 points, 20 votes” - As “Exploring with Wiki - Interview with WardCunningham” explains, newbies often find wikis too unorganized and want important content separated from uninteresting stuff.

Then perhaps users could view categories or search results sorted most-insightful-first.

(Is this part of the same feature, or does it need to be a separate feature?) Perhaps even *sections* of a page could be individually rated, and then the software could display that page most-insightful-section-first. Perhaps then software could do a job currently handled entirely manually: Ordering the sections of an article to “Put the most understandable parts of the article up front” (Wikipedia guideline WP:UPFRONT).


Feature - ProposedChange - (see also StagedCommits, DelayedCommits, which this is subtly different than) - You make it so people can propose a change to Wiklossary:DocumentMode text. If nobody objects, the change is applied. The proposed change is displayed in a way that is clear to everybody, and highlighted- “This is a proposal to change that.” For example, the new proposed paragraph appears immediately below the old paragraph. The change automatically commits after a period of, say, 7 days. People can say, “Let’s hold for another 7 days” by clicking on some widget on the proposed change. Why have this feature? Because, as it is, people propose text in the Wiklossary:ThreadMode text, and then it’s forgotten about, without every being applied. If you could put ProposedChanges in the Wiklossary:DocumentMode text, people would be much less averse to changing it, and we would see more [wiki:Wiklossary/refactor refactoring.]


Feature - ManagedChanges - Like a RecentChanges list, but that can be administered by TrustedUsers. That way, if someone attacks the RecentChanges page, filling it with garbage, someone can fix it. (LionKimbro)


Feature - DigitallySignedEdits - Use a cryptographic signing system like OpenPGP to sign edited pages.


Feature - PerPageStylesheet - A wiki implementation would keep a repository of style sheet snippets in a directory (or in separate edit box), one for each page (if the admin has the time).


Feature - CssMarkup - Allows to embed CSS style and/or class= settings into pages for styling paragraphes, text fragments, lists or tables. Of course should look wikiish and less annoying than HTML equivalents. (MarioSalzer)


Feature - WordAlerts - Like in IRC. Like- if someone says your name in IRC, or a word you’re “looking out for,” then you get an alert notice. You need some sort of form that takes lists of words to look for, or convention for writing on wiki pages that communicates “look for this word.” Then the system starts checking diffs against new edits, scanning for the presence of alert words, all kept in a big list, with who to send the alert to in there as well. When the user next logs in, they get a page notice, or some other form of notice, (perhaps by an EventSystem that can post notes to an external IntComm:EventSystem.) They can see where their name, or whatever word it was, was entered.


Feature - RatedComments - Note that there are other uses for rating besides CommentModeration. For instance, I think it would be useful if every comment had a quick way to indicate “I agree” or “I disagree”. Currently, you don’t often see people posting just “I agree” when they have nothing else to say, because it clutters up the discussion. But this makes it impossible to distinguish silent agreement from silent disagreement from silent disinterest. In my proposal, the agreements and disagreements wouldn’t be posted as separate comments; there would simply be a small icon next to the target comment that you could click on, which would take you to a page with a list of who agreed and disagreed with the target comment. So, you are incorporating voting, but not for the purpose of displaying only highly-ranked content; instead, the ratings are a mechanism for making discussion concise yet expressive. See also MeatBall:RatingAsContent. See also CommunityWiki:WikiVoting.


Feature - GraphViz - I know I’ve seen somewhere, that someone’s incorporated GraphViz into their wiki engine. By this feature, you can put GraphViz notation (I think it’s called the “.dot” format, or something like that,) into your wiki page, and then when it renders, you see a full graphic. Here's a perl script, that makes a IntComm:WebServer out of GraphViz. (LionKimbro)


Feature - UrlTitleLookup - People love to drop URLs into wiki. As much as we may dislike it, we can make it at least a little more bearable: Automatically look up the URL, retrieve the Title if it’s an HTML page, cache it, and then display that title instead of the ugly URL beast. Let the cache expire after a week or something. If someone really wants to show the URL, then they could write: [http://blahblah/ http://blahblah/], expressing that they really intended for the raw URL to be shown. (LionKimbro)


Feature - CheckBoxes - As seen in Sparrow- checkboxes that remember their state. Useful for to-do lists; People can just check things off w/o going to the edit page and finding the part to change. (LionKimbro)


(./) Feature - RevisionMarking - Include the entire history of a page when the page is displayed, using <insert> and <delete> tags. Use Javascript and CSS to show or hide these revisions. (Based on --EvanProdromou


Source - - There are many ideas in here worth culling.


Feature - non-indexable sections; should be a way to put a link on a page without placing that page in the backlinks, for example. See also MeatBall:CategoryCategoryDiscussion.


Feature - DelayedCommands - The ability to put commands into the wiki, that will be automatically executed after N days. The execution of the commands could be halted by anyone who wanted to. So for example, you could say, “In 4 days, unless someone objects, rename this page to blah.” Or, “In 4 days, unless someone objects, delete this paragraph.” (LionKimbro) #16 SelfDeletingBlock, FileReplacement, and DeletedPage as implemented in UseMod are instantiations of this general idea. This is also one way that patches can be evaluated in a CommunityProgrammableWiki, and in fact it is the way that is used in BayleShanks’s CommunityProgrammableWiki implementation.


Feature - SnippetPublishing - You could make it so that the returned HTML was just a snippet of a web page. That would make it easy to [wiki:WikiPedia/Transclusion transclude] across the Internet. You could use numbered pages, and make “micro-wiki” pages- content in a static page that was kept, edited, and maintained on a wiki. (LionKimbro)


Feature - TraceBack - I’ve looked at the TraceBack architecture notes, it seems pretty simple to implement. You could make it so that- if you click on the top of a page, which shows all the pages that reference the present page, you also get a list of all blog entries, or whatever else on the web links to that particular page. (LionKimbro)


Feature - CheapNearLinks - A page macro (a setting) instructs the engine to use a specific InterWiki moniker (MetaWiki: for example) for all further WikiWords of the current page that didn’t exist in the local database. (MarioSalzer)


Meta - Use Cases - Extend the template to include “use cases.” Change “Possibilities” to “Minor Variations.” (LionKimbro)


Feature - EmbeddedCode - Embedding code in wiki. See also [wiki:Wiki/SmartWiki Wiki:SmartWiki] and [wiki:PythonInfo/SandboxedPython PythonInfo:SandboxedPython].


Source - This is a link about an “SVG” wiki, this is possibly WikiWhiteboard material.


Feature - MarkupEmulation - engines` formatting kernels may mimic other implementations I think we’ve already placed this; At the very least, see InterWiki:MarkupSkins


(./) Feature - InclusiveLinkSyntax - Moved to AutoLink.


Feature - WikiComponents - You could have some sort of page namespace where you can create “components.” They would have inputs, for both WikiVariables data, PageMetadata, and for instantiation parameters. You would specify the component with something like component.NameOfComponent(arg1,arg2,...arg-n). If you had something like PythonInfo:SandboxedPython, you could also attach code to the components. CategoryObject. (idea based on [[Date(2004-05-04T19:28:26Z)]]‘s version of Wiki:IdealInternetWikiEngine) (LionKimbro)


(./) Source - We could harvest some ideas from Wiki:IdealInternetWikiEngine Wiki:IdealInternetWikiEngineDiscussionDone; Listed on ExternalSources. (LionKimbro)


{X} Feature - PerUserRecentChanges - A RecentChanges for an individual user. Can combine with EventCasting. From the PerUserRecentChanges page, point to the IntComm:EventServer & Event Key number for whenever that user makes an event. Provided, that the user allows their changes to be published in the PerUserRecentChanges, and to the IntComm:EventServer. (LionKimbro) Duplicate of #56 - UserFollowingRecentChanges. (LionKimbro)


(./) Feature - EventCasting - Have an IntComm:EventServer of some sort set up, and then whenever an edit is made, cast out some events. (LionKimbro)


(./) Feature - LinkBanning - failing all edits that include links to particular web sites. We’ve been seeing a lot of wiki spam, and it generally points to some particular web site or another. By banning particular target links, and perhaps even sharing those links, we can (possibly) protect ourselves. (Of course, this may well just end up in “roving web sites…”)


Feature - BayesianFiltering - use bayesian filtering techniques, as suggested in A Plan for Spam, and widely implemented in email spam filters, to detect unwanted edits to Wiki pages. Lots of interesting questions about how to make this work, but something that could be helpful for e.g. Wikipedia-style high-volume wikis. --EvanProdromou Repeats #140.


Feature - LocalNameServerInteraction - Interacting with a local name server, keeping links, and gateways out to other name spaces. Link IntComm:LocalNameServer. (LionKimbro)


Feature - ExternalLinks - You write a normal WikiName, but it points to something not a wiki page. Problem: How do you bind the name to something else? (LionKimbro) – I’ve did that, a page named “InstantUrls” contains a definition list or table with WikiWords and associated URLs, also it takes InterWiki monikers into account. An implementation could as well scan the whole Wiki for any previously defined [URL | titles]. (MarioSalzer)


Feature - PageHistoryVisualization - I think that ecological concerns would be much stronger (LionKimbro)


Meta - FeatureChecklist. A page listing basic, intermediate, advanced, and experimental features, with links to each. It would provide guidelines for WikiEngine implementors. --EvanProdromou Can we do this w/ categories? We don’t have DatabaseCapabilities yet; I’m worried about the increasing number of dependencies. What do you think? Or maybe we can embed this in FeatureSummaries. (LionKimbro)


Meta - Perhaps we need to name “TablePainting” as “TablePaintingSyntax,” and “TableEditing” as “TableEditingUI”, and set “TableSyntax” as a general page on table syntax, linking to TablePaintingSyntax, and See-also-ing “TableEditingUI”. Or something. (LionKimbro) – I’ve renamed my idea to TableEditor, so “TableEditing” is free for better discussions. (MarioSalzer)


Feature - TablePainting. Able to “paint” into table cells, by the wiki syntax. Presently described on page TableEditing. (LionKimbro)


Feature - TableEditor. One of the page elements that often get difficult to edit (due to the choosen markup and content size) are tables. A specialized editing capability (a bit like WysiwygEditor) would allow easy modification of table cells. An example is available at ErfurtWiki:TableEditor (MarioSalzer) …discussion continued on TableEditing


BayesianFiltering. Paul Graham’s A Plan for Spam describes a technique called Bayesian filtering to distinguish between spam email and good email. Could the same technology (or similar but better ones, like the Markovian filtering used in CRM114) be used to flag “good” and “bad” wiki pages? Probably especially important for high-volume wikis like Wikipedia, where the great number of edits per day makes it hard to find problematic ones in the noise. --EvanProdromou




AllowUsersToChangeEditTips ? While editing a page, many wiki have (below the edit box) EditTips: a brief summary of the most important TextFormattingRules and a few other useful links relevant to editors. Rather than make those EditTips some set-in-stone text that only the SysAdmin can change, have the wiki pull that text from some otherwise-ordinary wiki page (perhaps “the part of page ‘EditTips’ above the first horizontal line” … or page Wiki:OneMinuteEditing) (Wiki:OneMinuteWiki Wiki:BriefIntro). (related to: CommunityWiki:MakeWikiMoreAccessible). (a specific application of CommunityWiki:Transclusion, CommunityWiki:TransclusionWithLayout). CategoryEditing. – Visual:DavidCary (Note: This has been implemented in PWiki2 as of version 0.9.x --JamesMills)


Feature - WikiScript. Allow users to embed executable code into Wiki pages. Unlike MetaWiki:CommunityProgrammableWiki this would preferrably be run in a sandboxed interpreted language. (MarioSalzer)


SkinnableInterface. Allow administrators to define multiple UI presentations, which can be selected by users. cf. MediaWiki, PmWiki for some examples. --EvanProdromou - Some Wikis even allow their users to edit, add and change the designs by simply having ordinary Wiki pages used as layout templates. --MarioSalzer


Meta - Process for Off-Topic - We’ve decided that there are feature ideas that don’t belong here. Quite right. However, they do need a place to go, I believe. A place that can be referenced. We need to figure out what that place is, so that we can forward the ideas there. It is entirely reasonable people would think to come here to talk about something like CodeHosting (#134). We just need to figure out how to MeatBall:EnlargeSpace. IntComm isn’t really the place for #134.


Off-Topic Feature - CodeHosting - This is an idea that doesn’t belong on this wiki, but that I’m listing here until we figure out a place to forward it to. (See process notes in #135.) You could have a wiki that lets some pages be designated “code” pages, or perhaps sections of pages would be “code.” The sum of all code on the wiki could be collected into a distribution for download, on demand. The sections of code would be divided into two parts: Documentation, and Protected Code. The Documentation part would be one big comment block at the beginning of the code. The Protected Code would be everything else. You would have to have priviledges granted to you on the wiki to work with the protected code. Anybody could work on the Documentation part. (by default.) This is off-topic to this wiki, because it’s about a wiki-like technology, but isn’t applicable to wiki in general. It is a “utility wiki” idea, and utility wiki tend to diverge dramatically from more pure communications wiki. (LionKimbro.)


Feature - WikiExport - The complete WikiWikiWeb can be downloaded as tarball or .zip file, containing all pages in html format, or a wiki could support DocBook, PDF or OpenOffice exportation of all pages. (MarioSalzer.) Whoever writes this up, link it to MobileContent, a way to ship documents from server to server. (LionKimbro.)


Feature - UserAuthentication and (Tracking) - Multiple engines require users to log in, before they could edit pages (they are called WikiWarez). Others do it only optionally (user name reservation). (MarioSalzer)


Feature - CaseInsensitiveWikiLinks - ThisPage and ThIsPaGe would link to the same content. - Is implemented in multiple (MySQL-based) engines by accident, but not fully. Users regularily demand for it, while it appears too complicated to get adopted by major engines. (MarioSalzer.) How about, just: CaseInsensitiveLinks ? (LionKimbro.) True, the “Wiki” is redundant here, just rename it, Lion. (MarioSalzer)


Feature - EmailAddressProtection - Makes the Wiki automaticall hide email adresses from bots and spiders on an advanced technical basis (e.g. no silly JavaScript “solution”). May be there is even sometimes the need to expand this on generic URL hiding? (MarioSalzer)


Feature - LinkDatabase - a standardized __interface__ for accessing the page structure of a Wiki. This was introduced by MeatBall:LinkDatabase, but is currently not supported by most engines. (MarioSalzer)


Feature - MouseoverNotes - If you hold your mouse over a link, it gives you a line or two of information- maybe even a whole block. The information is retrieved from the target page itself. Could store all page’s in a big hash, for quick loading in the engine. Would require JavaScript. Could use WikiVariables to set the definition on a page for what should show up in it’s MouseoverNotes. (LionKimbro, on behalf of MattisManzel.) The ErfurtWiki can do it already, it however pops up a short page summary, not a separate description/note entry. (-?) I was looking for this on ErfurtWiki, but didn’t find it. Where can I see it working? (LionKimbro.) It’s disabled on the demo site, and I can’t actually point to a site, that knowingly has it enabled. (MarioSalzer) I just saw which has mouseover notes. I think it’s called the “Sushi” wiki, or something like that. (LionKimbro) See also this, which, while it isn’t a wiki, (I think,) has a good demonstration of the basic technology. (LionKimbro)


Meta - Specific vs. general features. There are some groups of pages where there is one “general feature” page (e.g. FineGrainedAddressing) and many pages for very specific features related to the general idea (e.g. PurpleNumbers, PermanentAnchors). The default feature template is not useful for these. (BrianTempleton) Generally, I’ve been thinking, “If this particular possibility is important enough, and mentioned on it’s own enough, we should give it it’s own page.” Hence, both FineGrainedAddressing and PurpleNumbers, and when we get to writing it, PermanentAnchor as well. Does that sound good? We should think up a page name for ideas like this, and for talking about ideas like this. What do you think? (LionKimbro)


Feature - PermanentAnchor - Like OddMuse does. Many notes on [wiki:MeatBall/PermanentAnchor MeatBall:PermanentAnchor.] x-ref with PurpleNumbers. Reaches out and grabs a piece of the link name-space. (LionKimbro)


Feature - IdeaSpaces - An implementation of a concept of an IdeaSpace applied to a Wiki, a type of IdeaSpace particularly useful in the conceptualization, initiation, collaboration, organization, presentation and proliferation of spaces which are ideas and can be named. The name is the handle which enables the ideas existance and propels it into usefulness and incorporation into a societal knowledge base. For clarification of IdeaSpace, see Wiki:IdeaSpace. (DonaldNoyes) I think I understand what you’re talking about; Are you talking about putting name-tags on ideas, and then cross referencing resources (like, blog entries, wiki pages, emails, etc., etc.,) by tagging them with that name tag? I’ve read Wiki:IdeaSpace, but it didn’t clarify it much for me. BTW, you may want to note WikiKM:IdeasHaveContext. (LionKimbro)


Feature - ReifiedChanges - a type of VersionControl where wikizens can easily manipulate deltas and reified modifications in various ways, not only mutable wikipages (BrianTempleton) ??? I don’t get it..? Do you mean like MeatBall:DigestedChanges? (LionKimbro) No. (BrianTempleton) I don’t get it; I need some help here. :) (LionKimbro)


(./) Feature - AppendOnly - marks a page as almost read-only. New content can only be appended (or inserted), but nothing could be removed from a page. (MarioSalzer)


(./) Feature - PageMetaData is a separate chunk of data, that for example describes and classifies a page. Unlike the BundledPages idea, this is more than just technical/database page informations. (MarioSalzer)


(./) Feature - PublicallyEditableIntermap. (LionKimbro, on behalf of anon.)


Feature - InterWikiUrnNamespace. A Uniform Resource Name (URN) is an URI that isn’t an URL. RFC 2141 ( defines the format of an URN: urn:namespace:some-string. RFC 2611 ( defines a registration mechanism for namespaces, including experimental namespaces (prefixed with “x-”). This feature is for developing an “x-wiki” namespace that could be used for InterWiki links. (EvanProdromou) What are the benefits? (LionKimbro)


Feature - MobilePieces - The ability to move pieces of a page to another page. Like MobileContent, but beneath the level of the page. Makes it easy for people to refactor conversations. Can move or copy. Likely use a special mode. Special considerations for threadmode? Cross-wiki or Intra-wiki. Possible that this is just an HTTP pragmatics problem. (LionKimbro) Currently, a “diff” display makes it appear that that paragraph was simply deleted, tempting others to restore it – I wonder if “diff” can be made smart enough to reassure me that that paragraph was *not* lost, simply moved elsewhere on this page, elsewhere on this wiki, or elsewhere to another wiki. (DavidCary) Hm. Well, I don’t think we’d make wiki scan various wiki for additions matching a deletion. But I think that if MobilePieces were implemented, it should also work across wiki boundaries, too. (LionKimbro)


Feature - TemperedPages - The ability to make a page (or pages) immutable (except, possibly, for comment, by a DocViewThreadViewSplit) by the concensus of the members of the wiki. Requires some form of CommunityGovernment features (#5). You could also reverse the immutable pages (rending them mutable), by consensus of members as well. In this way, the wiki can establish a canon. People are moved to purify the pages, make them sparkling clean, when there is a call to temper a page. (LionKimbro) Another possible benefit- things that aren’t meant to be reworked beyond spelling / grammer- manifestos, personal stories- things like that, perhaps this kind of thing could protect that. (LionKimbro)


Feature Note - WikiVariables, BuiltinCategories - Just realized- you can do a lot of BuiltinCategories work by relying on WikiVariables. Have a “page category” WikiVariable, and have it indicate the list of categories it belongs to. Make a macro that reads those values, and outputs them. etc., etc.,. Build up the system out of macros and variables. (LionKimbro)


Category - CategorySecurity, for features that have to do with securing the wiki from vandals. Link Meatball:HardSecurity, Meatball:SoftSecurity. (LionKimbro)


(moved to TrashCan)


(moved to “zero-click authorization” section of StagedCommits)


(./) Talk alert - There’s a long thread of people begging for features at, plus commentary analyzing why these ideas Are Never Going To Work :-). Great! I’m adding it to ExternalSources. (LionKimbro)


Feature - VersionedImages - What would a collaborative (Wiki-like) system for discussing a drawing and changing a drawing look like ? Perhaps people could see a “current image”, then optionally turn on a “discussion layer” on top of it … with comments like “I like the colors in *this* area”, “The dolphin I drew here doesn’t look right – could someone help me fix it ?”, etc. (LionKimbro, on behalf of DavidCary)


Feature - RatedChanges - When you submit a change, you can also “rate” it. You say “Minor Change,” or “Major Change,” or just leave it as a normal change. (LionKimbro, on behalf of DavidCary.)


Feature - SideScrollingNarrowColumns. I just found Tofu for the first time – a side-scrolling, narrow-columned text reader. The idea being that text is more readable that way. More of a general readability question than a wiki-specific feature, but… hey, we’re making text here! B-) (EvanProdromou)


Feature Note - Link to MeatBall:SubscribedChanges (mb) from the page that comes out of MailedUpdates. (LionKimbro)


(./) Feature - WikiFutures:CollaborativeComics. Re-reading Understanding Comics has made me think about the great Web comics out there. I then started wondering how well comics would adapt to collaborative, bidirectional Web systems. What would be the interface? How would people collaborate in a comics format? What possible applications? (EvanProdromou) I’ve forwarded this idea to WikiFutures: WikiFutures:IdeasToPlace #61 - Since, WikiFutures:CollaborativeComics is more about the future of wiki, than about a particular feature. (LionKimbro)


(./) Feature - WebDav - Explore how WebDAV ( and wiki overlap. Both are technologies for a bidirectional Web. What’s the difference? What can DAV teach wiki – and vice versa? Could DAV be an enabling technology for future wikis? (EvanProdromou)


Feature - AutoLink - As seen on MeatBall:AutoLink (LionKimbro)


Feature Note - Are UnifiedRecentChanges and NearRecentChanges different? Hmm… (LionKimbro)


Category - Need a new category- “CategoryNear.” Include NearRecentChanges, NearLink, NearSearch. (Well, just 3 items, really need a category? But if we ever get 5, definitely.) (LionKimbro)


Meta - reorg - I’m thinking of two major changes to the Category system. One, not using the word “Category” in every category page. Two, decomposing FeatureSummaries into the category pages. It doesn’t feel terribly useful, just walking down the FeatureSummaries. WikiVariables exist in MoinMoin 1.2, but we don’t have them yet. Ah, but that sucks, because the features that belong to 3 categories will need the same writeup 3 times. I think we have to wait for MoinMoin 1.2. (LionKimbro)


Feature - SisterSites - Showing pages with the same name on other wiki at the bottom of the page. (LionKimbro)


Feature - WorksInProgress - Sometimes you are working on a page, but resist saving because you don’t want the page to go public yet. It’s messy, says mean things, or really really incomplete. You want to save it as a “Work in Progress.” You want to be able to save to your “Work in Progress” bin. You want to be able to review your works in progress. (LionKimbro)


Category - CategoryInterNet - Like CategoryInterWiki, but linking to general internet utilities. Such as IrcInclusion, MailedPageUpdates (#95), etc., etc.,.


Feature (Humerous) - UserTargettedParallelUniverse - Make it so that all edits that a particular user make occur in a parallel universe. That is, the user believes that they are making a bunch of edits to the wiki. However, nobody else sees (or- has to see) the edits. Likely to incur terrible wrath if discovered. (LionKimbro)

A “UserTargettedParallelUniverse” is more or less the same as what Jeff Atwood calls "hellbanning": “A hellbanned user is invisible to all other users, but crucially, not himself. From their perspective, they are participating normally in the community but nobody ever responds to them. They can no longer disrupt the community because they are effectively a ghost. … Like so many other things in social software, it keeps getting reinvented over and over again … (There is one additional form of hellbanning that I feel compelled to mention because it is particularly cruel – when hellbanned users can see only themselves and other hellbanned users. Brrr. I’m pretty sure Dante wrote a chapter about that, somewhere.)”


Category - CategoryReaders, or something like that. Things that dramatically affect the reading of a wiki. BrowsingBackInTime (#97), or the trails feature. (Constructed paths, or something like that.) (LionKimbro)


Feature - BrowsingBackInTime - browsing the wiki as if it’s a particular date. Note problem of automatically generated content- may need to, daily, store the output of every page. (LionKimbro)


:\ Feature - NearSearch - like AlexSchroeder’s implemented over on CommunityWiki. :) I’ve written it up, but it’s ugly. It needs to be refactored with NearLink. (LionKimbro)


(./) Feature - MailedUpdates - Makes it so you can get “roped in” to a conversation on a foreign wiki. (Otherwise, you can’t carry on a correspondence, because you’re not constantly checking for updates.) When a wiki is just forming, you probably want to support MailedPageUpdates for the entire wiki..! When a change happens anywhere, you want to know. With time, you want to restrict yourself to just individual changes. (LionKimbro)


Feature - MarkupStandard - See MeatBall:WikiMarkupStandard - another one for CategoryStandard (LionKimbro)


Feature - BundledPages - A page is not just the contents, but also the title, revision history, etc., etc.,. Treat all the meta-data attached to a page as part of the “page.” You could also add information about the email addresses of the various contributors, etc., etc., to the “contents” of the page. That way, when moving a page between wiki with different licenses, all contributors could be contacted, in order to ask for consent. BrianTempleton expressed some interest in this. (LionKimbro)


(./) Feature Note - DelayedCommits, StagedCommits - One problem with DelayedCommits, is that you have to wait. You have to make sure you can perform a bunch of work at once, even though the commits are delayed. People can choose to edit the original page, or the delayed page. (LionKimbro)


Feature - FreeLink - See Wiki:FreeLink for details. [“free”] [“link”] on MoinMoin. (LionKimbro)


Connections - - the author of this has an idea similar to what is listed here; We should note this on the page for the idea he’s talking about. (Linking up interested people, and all.) (LionKimbro)


Feature - GraphicChronologyVisualization - The ability to graphicly represent and merge chronologies. Both CategoryVisualization, and CategoryRecentChanges. (LionKimbro) You mean, like a time line ? (Visual:DavidCary)


Work to do - Make sure all Category pages follow the basic model of CategoryFeature. That is, titled, with message “pages that include word…” (LionKimbro)


Feature - RecentChangesByRss - Yet another item that should’ve been on the list by now. Very common, but still a feature we talk about a lot. (LionKimbro)


(./) Feature - UnifiedRecentChanges - Don’t know what this wasn’t on the list before. (LionKimbro) (related to #67)


(./) Feature - RaisedRecentChange - Make it so you can add a “RecentChanges” entry for an entry on a related, but different, wiki. That way, if people post something that some other people need to see, (because it’s relevant,) but for organizational purposes, was put on another wiki, then everyone can be happy. You are “raising” an entry onto RecentChanges manually. Maybe should call it “RemotelyNotifiedRecentChanges,” or “ManualRecentChangesAddendum.” But this is not UnifiedRecentChanges. Nor is this NearRecentChanges. This is an addition done manually, can be across arbitrary distance, and is infrequent. (LionKimbro)


Meta - We need a “CategoryWikiFeatures,” for all the Meta talk, and miscellaneous pages (such as FeatureSummaries) that are important, need to be tracked and collected on a map, but aren’t about features. Mmmm…. TypedWikiPages… (LionKimbro)


Meta - WikiVariables - When I upgrade the system to the version of MoinMoin that includes WikiVariables, we can use the variables to give one-line descriptions to every feature page. Then we can make FeatureSummaries and the category pages all include the one-line summaries, from the page itself..! Woo Hoo! (LionKimbro)


(./) Feature - WikiVariables - ThomasWaldmann is already implementing in MoinMoin. You can assign variables on a wiki page, and refer to them from elsewhere. Possibilities include nesting lists, dictionaries, and strings, and retrieval from other programs. Games and applications and help systems that pull down data from wiki or BitTorrent. Primitive (but useful!) verson of DatabaseCapabilities. (LionKimbro)


Meta - Is StandardPages a feature? Need to figure out what to do with this sort of thing. (LionKimbro)


Feature - EasilyCreatedWiki - Link to ideas such as WikiFarm. However, you could also just have an easy-to-setup wiki feature. Many possibile ways to make this a reality. (LionKimbro)


(./) Feature - PurpleNumbers - We now have FineGrainedAddressing- awesome! I’d still like a seperate entry for the particular PurpleNumbers system. It’s pretty interesting, and already implemented..! Purple Numbers (LionKimbro)


Feature - TypedWikiPages - New Pages should be created automatically with an appropriate Template. The Decision could be based on the pagename (Other Meta Data is not available). Possible Problem : Long and clumsy page names . Benefit : Not Necessary to select a template. (NorbertKlamann) I feel there is more to this idea than what you’ve written- WikiEngines that can attach some intelligence to a page- what it is, what it’s function in, could do a lot of other cool things as well. What you are describing seems more like: PagesTypedByName. It’s typing, but you’re describing how we put the type on a page. Good to see you, by the way! (LionKimbro) Just occured to me: BuiltinCategories is a similar idea to TypedWikiPages. (LionKimbro)


Feature - RealTimeEdits - Supported by SubEthaEdit ( Need to link to the IRC idea as well. (Pulling meeting notes from IRC into the wiki’s jurisdiction.) See also: Wiki:RealTimeWikiDesign (LionKimbro) See RealTimeEditing and #26


Feature Note - RSS for Wiki can mine information from . (LionKimbro)


Feature - TelePresence - Common name for seeing who’s available to talk, by plugging into IM networks. CraoWiki has implmented it: see . Personally, I’d rather use another term, since for TelePresence, I’d refer to closer to moment-by-moment observations of activities in general. (LionKimbro) Need to talk with ArnaudFontaine about the name. (LionKimbro)


Meta - Second thoughts- maybe this should remain WikiFeatures. Make another wiki, for wiki technologies, or even just Internet collaboration technologies, and delegate wiki features over to here. (LionKimbro)


Meta - there are more things to talk about then there are extant wiki, unless there already is an IRC technologies wiki, or an Email technologies wiki, etc., etc.,. May need temporarily park pages here, before we can establish good delegations. (LionKimbro)


Tool - LocalCacheWikiBrowser - download an entire wiki, than traverse it locally. Eventually, could use to upload. But short term, just use to quickly find the name of the word you’re looking for. (LionKimbro)


Feature Family - IRC interactions, such as: pages that ship out from the IRC document (irc docs don’t exist yet), using SubPageAddressing (#69) to put things in pages, existing tech- IRC bot looks up a wiki page url. (LionKimbro)


Feature Note - BuiltinCategories - You could make a “Category Browser” if you had BuiltinCategories. It would help you find words that you needed to link to, but just forgot what they were. (LionKimbro) Even better, in terms of short term, just implement LocalCacheWikiBrowser, and then you can walk the whole wiki. See #72. (LionKimbro)


(./) Feature - SubPageAddressing - The ability to address the internals of a page with some degree of specificity. It a page is participating in two PageClusters, there may be the desire to give one half of the page to one group, and the other half to another. Then again, maybe you just want two different pages, right? Don’t know this is a good idea or not, but it comes up a lot, and should have an entry here, I think. (LionKimbro) Rename FineGrainedAddressing? (BrianTempleton)


Meta - this wiki may need to have some notions of what is wiki and what is not. Since you could build just about anything into a wiki (say, a working calculator on a page), you don’t necessarily want discussion on non-wiki elements of anything to appear here. (Say a feature such as “the logarithm function,” for the wiki calculator.)


(./) Feature Note - UnifiedRecentChanges - You can make it support any change reporting format. You can make it support complex visualization possibilities. For example, you could say “overlap threads A, B, and D for me in time.” CategoryVisualization for that. (But does it really belong? It’s also about change aggregators in general, not just built into wiki.)


Feature - SelfDestructingPages - Pages that time-out after a certain amount of time since their last edit. See #65.


(./) Feature Note - FadingText - you could apply it on the RecentChanges page to show how long a page will live before it dies. That is, when you have pages that automatically delete after a set number of days after their last edit, then you can visually show the page slipping into death by the fading text on it. Then again, perhaps it’d be better to have a “death list”, with most-recent to die on the top. (See #66.)


Category - Create CategoryVisualization. A lot of CategoryRecentChanges work would likely end up in there. FadingText and FadingLinks would go in there. Anything having to do with the visual form of a wiki.


(./) Feature - WysiwygEditor - …or close to it. You select text, hit B, and it’s bold. Hit i, and it’s italic. For people who are pretty computer illiterate. Link to Also see, which looks quite mature, and is open source. Wow! That's AMAZING! – LionKimbro Also found: - A wiki devoted to the idea. Aha- EditMe has it. login as admin pword: demo. Problem: Lynx users. :P Theres a lot of talk about this on Wiki:WysiwygWiki .


(./) Feature - AutomaticFeatureInstall - MoinMoin is headed this way, whether it knows it or not. Just say “We want this feature,” admnistrator approves, and bam. Automatically done over the network. Feature installed.


(./) Tool - PersonalLogServer - A tool for open, minute, logging. Can interact with wiki in many ways. Link to See also #24 - see PersonalPing. (LionKimbro.)


Feature - DrawingCapabilities - Ability to draw on wiki. MoinMoin has, Twiki has. More radical vision- all visual wikis, special clients, cast out static web pages for web browsers (read-only, though.) See Visual:VisuallyOrientedWiki and Visual:LongImageIncorporationProcess, for cool future possibilities. Probably need to expand out into multiple entries. See also "Creating an SVG Wiki," and the mentioned PurpleWiki:WikiWhiteboard. Another page with screenshots.

“How about a LegoWiki, where instead writing pages you can construct buildings? Now wouldn’t that be cool…” – anonymous


Feature - CollaborativeVisualMaps - Ability to collaborate on collaborative, 2D maps.


Feature - GaGaLinks - As demonstrated at . An interesting solution to link names. No camel case! An approach to #33- arbitrary links.


Essay - The importance of RecentChanges, and types of RecentChanges.


Feature - UserFollowingRecentChanges - Being able to track a clique member across multiple wiki. I have the greatest enthusiasm for this one. – LionKimbro. See also: #24 WikiPassport, #61 PersonalLogServer, #87 RecentChangesByRss combined with #42 AuthorFeed.


(./) Feature - NearWikiRecentChanges - Looking at RecentChanges in a nearby wiki. This is NearRecentChanges. (LionKimbro)


Feature - CategorizedRecentChanges - Looking at RecentChanges within a given category.


Feature - NearPageRecentChanges - Looking at RecentChanges around a page. I, personally, think it’s only useful in a few cases. – LionKimbro


(./) Feature - DelayedCommits - Possibly superior to StagedCommits. Make a page for it, and link to it from StagedCommits.


Feature - SoftLinks - Automatic prioritized linking between pages. If a page links to another page, the target automatically soft-links back to the source. (If I understand correctly.)


(./) Feature - FadingLinks - Links that are not followed much gradually fade to black.


(./) Feature - DatabaseCapabilities - The ability to map parts of the page (somehow) to a database. People can edit the database, observe edits to the database, perform some types of selects onto the database, etc.,. Be sure to give a timeout to database ops, so people can’t just crash down the database by selecting everything in it.


(./) Feature - AutomaticTranslation - Build translation capabilities into the wiki engine. (Or, alternatively, let the wiki engine send the text somewhere to be translated, get the result, and show it to the user.)


(./) Rename - BuiltInCategories to BuiltinCategories, for consistency with BuiltinThreading


FeatureFamily - TimelineTools - visualization and collation of timelines. For example, view politicians life from the perspective of drugs & alcohol, politics, economics, life stages, location. Mix & Match. Not just mixing from one wiki, but overlaping with other wikis’ timelines as well..! Existing change aggregators sort of like this, but not time-scaled presentation.


Feature - ConstructedStructure - ability to create navigation systems that people can hook onto in order to traverse the system. Trees, graphs, etc.,. This is like “trails,” except more like “maps” than linear trails.


(./) Feature - MobileContent - support for CommunityWiki:MobileContent, as envisioned by BayleShanks. Basically, easy to move content from wiki to wiki. Can also automatically support license checking, so you don’t accidentally send GFDL’d content to a whatever-whatever-license wiki.


(./) To-Do- Make a FeatureSummaries page with summaries of various features on it. Transfer most of these feature ideas onto the FeatureSummaries page.


Feature - AuthorFeed - As seen on OddMuse: (related to Wiki:WikiTechnologyTheAuthorsFunction ?) yes- related to #56 UserFollowingRecentChanges. OddMuse has it implemented, incidentally. (LionKimbro)


(./) Feature - MultiPosting - When you make a commit, you can simultaneously send a summary email to your personal blog, wiki blog, by email to friends, post a notice to peers irc or people on Jabber, etc., etc., etc.,. PersonalPing.


Idea - If you had BuiltinThreading, you could make it so that that in addition to RecentChanges, there was RecentDocumentChanges, which would isolate document changes, but ignore all threaded discussion. That way people who casually observed the wiki could ignore the conversations..!


(./) To-Do - Rename the wiki “WikiTechnologies”, so that we can include ideas like Bayle’s awesome MeatBall:WikiRefactoringBrowser, and multi-tiered architecture. (Custom wiki browsers, page databases translated by various wiki engines.) WikiFeaturesDirection has addressed this question. Now that [wiki:IntComm/FrontPage IntComm] exists, there is less pull to expand the scope of this wiki beyond features, feature notes, feature cataloguing.


Feature - AccessControl - Implemented in MoinMoin, too (Access Control Lists)


{X} Principle - The LessIsMoreFeature to help against creeping featurism. ;) <laugh> There *should* be a LessIsMore entry. The point of this wiki isn’t to say all these features should be implemented in one wiki, (a SwissArmyKnife,) But to show the kinds of things that are possible, deliberate over what is desireable, etc., etc.,. – LK


(./) Idea - WikiClique - not a community, but a clique. These are people who watch what each other are doing, even though they may be in disparate locations. If someone’s doing something somewhere else that the clique might be interested in knowing about, it’s automatically reported. This idea needs some development, and is likely a cross-over between blog and wiki technologies. I believe that the PersonalPing accounts for this. (LionKimbro)


(./) Feature - NearRecentChanges - so communities can isolate content and gradually divide the wiki.


Feature - NumberedPages - …with textual maps onto the numbers. Connect to PageRenaming. May be connected to the idea of “Anonymous Pages.”


Feature - ArbitraryLinks - the ability to support any string of text as a link. For external links to the site, the may need to publish maps (MachineServices) or support numbered pages, or something like that. See #58 (MoinMoin gaga parser.)


(./) Change the name of WikiCriticism to IdeaSources, or something like that. Done.


(./) See a bunch of features on Wiki:InnovativeWikiFeatures and a message to Lion from RobertAbitbol at Wiki:InnovativeWikiFeaturesComments. Thanks for the link to the discussion page. BTW, there is a link to Wiki:InnovativeWikiFeatures on the page “ExternalSources.”LionKimbro


(./) to do - Segregate BuiltinThreading from DocViewThreadViewSplit. Done.


Feature - ContextualLinking / Facet - As seen at Peri Peri (?)


Feature - PageCluster - As seen at


Feature - PageTranslation - As seen at


Feature - RealTimeEditing - As seen at, see #77 and RealTimeEditing


Feature - SeperateRooms - RecentChanges lists are maintained in seperate “rooms” that documents and threads can live in. (Threads can also attach to documents.) The group can post a small notice describing what kinds of things are going on for publishing to a larger aggregate across all rooms. Or, could model as a blog that people can propose posts to, a la K5, to keep an update on the progress of the project as a whole. A system of delegation, sort of.


Feature - WikiPassport - a cross-wiki passport system, so that you can specify per-wiki, multi-wiki, and pan-wiki settings. I believe the guy with the hard to write name is promoting this idea. Can be merged with PersonalLogServer. (#61)


(./) Feature - StagedCommits - Changes are “staged” until the receive some form of authorization, from the site maintainer, or through some sort of group process. Anyone can view the versions awaiting in staging, but the default is the non-staged version. Whoever commits a staged commit sees the site as if their commit has been accepted, unless they opt out, or if the staged change is rejected. When someone with commit rights sees a staged page for the first time, they are presented with a diff and immediately asked if the stage should be committed or not.


(./) Feature - PageRenaming - Ability to rename pages easily. Ideally, en masse, as part of an atomic change. (AtomicCommits) Instances on the same wiki of the old name are automatically repointed to the new name. Forwards are written onto pages of the old name (unless something else has taken their place) for the benefit of off-site linkers. You’d want to be able to id pages by unique number, as well.


Feature - FootNotes -


(./) Feature - FadingText - the older text is, the more it fades, until it fades into a readable gray. Text from the last 3 hours practically sparkles. Text from the last day is lighter than pitch black. Text from the last week is a very dark grey. Text from the last 3 months is grey. Older text is a light grey, almost merging into the white background, but still readable. You should be able to turn this on or off, defaulting to off. You don’t turn it on and off on a per-page basis- you carry on-or-off as a sort of global mode. Why? Because at times, all you are doing is looking at recent changes and following threads. You hop from page to page doing so. You wouldn’t want to have to keep turning it on and off.


Feature - SimpleUiForVisitors - Until you log in, show only a minimal amount of icons, backlinks, etc., etc.,.


(./) Feature - NearLink, like in OddMuse. Revolutionary cross-wiki referencing system. A must-have feature for wikis as WikiFutures:WikiCanonicalization / WikiFragmentation occures.


(./) Feature - DocViewThreadViewSplit. Pages have two panes, Document view and Thread view, that can be viewed side by side. So, a page is really a page and a discussion. The doc view side is edited as normal, the thread view side is a hierarchical threaded conversation system. You cannot change other people’s text. Most recent message at the top. Would need to figure out how to erase huge chunks of thread in a recoverable way, so that “clearing the board” is possible.


Feature - SelfDeletingBlock. Lines that delete themselves automatically on a particular date. Useful for leaving notes for a limited period of time, and having them automatically clean up after themselves. See also #162: DelayedCommands.


Feature - GroupWareWiki - Wiki become more like what is called “GroupWare” today. GroupWareWiki feature mailing list integration, database integration, co-static page development.


Feature - VisitorVisualization. Everyone can see who’s visiting the site, what pages they are visiting, more or less as it happens. (or, within 10-20 seconds, given HTTP.) See also: MoinMoin:ExtensionProposals (Footprints idea.)


(./) Feature - IrcInclusion. Somehow, IRC conversations are easily tied to pages, beyond just cut-and-past.


Feature - TestBranches. Ability to have a bunch of changes in mind, awaiting approval to clobber (or, more nicely, merge into) the baseline.


(./) Feature - AtomicCommits. Ability to collect a number of changes into one RecentChanges entry, revocable as a group, or in pieces. Good for describing proposals. Written up: AtomicCommits.


Feature - ImmutableTextBlocks Ability to say, “This block of text is immutable. Either deleted all, or deleted some, but immutable.” Useful for things like petitions, where you want to make sure the text isn’t changed at the last minute… use “#immutable-begins” and “#immutable-ends” in text box. When displayed for edit, have edit box above/below immutable text. Immutable text in middle, check box to delete it. Code detects a recreation of immutable text, or very similar text. (Maybe..?) See also: (LionKimbro)


Feature - PerPageRss doesn’t necessarily have to be the case. You could get a custom RSS feed generated for different clients, summing over multiple pages, perhaps. The things you cared about would be collected. Wait- no… Well, something to think about. See also #2. See also: MoinMoin macro:


Feature Family - More ComplexWikiObjects, such as intelligent tables. You could “subscribe” to an individual row (SubscribeToRow), and when any of its values change, get mail or RSS notification. Or, the same thing for list items in a list. So, for instance, in these IdeasToPlace items, you could be notified when the list item change, meaning that someone’s adding to the thought, or that it’s been forwarded to another wiki, or whatever.


(./) Feature - RdfForWiki. RDF & Wiki combination. Likely uses MachineServices. See also: MeatBall:RdfForWikis, RdfWikiNodes.


Feature - MachineServices - for example, the ability to ask a wiki “what do you have containing the word ABC?” and get a response, at the API level. That search capability, usable by other programs, would be one of the MachineServices a wiki could support.


Feature Family - CommunityGovernment - A whole class of features, that make it so that a community of wiki-zens can govern the wiki and its contents effectively. As elements of wiki become critical to Internet infrastructure, people will need to feel secure in those systems. We will not be able to tolerate some random guy showing up and messing things up. Thus, we will need to be able to perform sealings and unsealings of critical content. How we perform such sealing and unsealing is the domain of CommunityGovernment. This is a large topic. It needs it’s own page now, and likely needs many many wiki in the future. At any rate: The folks over at Atom are gaining a lot of intelligence about wiki community government. See also: WikiFutures’ WikiFutures:IdeasToPlace #20. Job rotation: CommunityWiki:PeerReview, greeting new visitors, etc., etc.,. see also WikiProcess wiki, though nothing there yet.


Feature - MachineReadablePages - Wikis are able to publish content made to be directly read by other machines. People can easily edit the information made for reading by other machines. Perhaps this can already be done with a raw page retrieval..? But not all pages support raw page retrieval by the same syntax.


Feature - Wikis that lets people colaboratively design static pages together. Wiki lets you edit HTML tag, HEAD tag, TITLE tag, etc.,. Seperate pages for design and display. “WebpageDesignCapability”. Certain technologies may be forbidden, such as scripts, or otherwise highly regulated. The “face” of the page would appear somewhere quite different- not as a normally linkable wiki page name.


(./) Feature - PerPageRss. See also #9.


Feature - “SimultaneousWikiBlogPost” - You can simultaneously post a wiki entry, and a brief blog summary. The wiki entry will go on the page, and the blog entry will be routed to your personal blog. There’s default text in the blog summary, saying something like “I created blahblah on blahblah-wiki,” or, “I edited blahblah on blahblahwiki.” Can be easily switched off. Default on for creation, default off for edits. ’’(If you use your HomePage as a blog … perhaps the wiki could automatically append a link to the page each time you create/edit a page.)’’ Click on “LionKimbro”, and you can see a list of links to pages I’ve edited in the last 24 hours. All I need to do is make a module to read the PlogDev: personal log server. (LionKimbro)