User:Sysy~metawiki/page creation by email
Wouldn't it be cool if you could CC an address and it would automatically generate a new wiki page based on that email? This would remove the burden from wikignomes constantly having to cut and paste emails into new pages..
Subject: [Trac] Integrating mailing list comments into the TRAC WIKI Date: Thu, 8 Sep 2005 09:30:59 -0400 ECKHART.CURT at leg.state.fl.us [This post was actually in a reply to some other post, but it got out of hand so I pulled it out into its own thread.] If you think that the information provided to this list by TRAC experts is valuable and should be preserved, read on. This is a proposal for a TRAC pluggable module. If the idea gets any traction, I will start up a side effort to pursue it. A pointer to the appropriate venue would be appreciated. I know about the TRAC Macros site; is there a similar site for TRAC plug-ins? --- proposal begins here --- I have been joined to this mailing list for only a month maybe two, and I have benefited greatly by the advice and comments of the people working on this project. Much good information gets posted here, often with the tag line "this ought to be added to the WIKI". I doubt that happens much of the time because we're all people and we're all very busy creating the software, plus it's a real pain in the @$$ to go back through old email sifting for golden nuggets of information. This post is a proposal to take a step toward automating the harvesting of the great information from this list or and automating the capture of it into the project wiki. If people find this idea interesting, we can probably start up an effort on one of the sites devoted to TRAC plug-in development. Here's the idea: I am envisioning a tool which could harvest information out of a mailing list which exists to support a TRAC based project. First the following module or modules would need to be built: 1) Develop a plug-in to TRAC which will accept a post of text and recognize some bits which are marked up according to a well defined but simple tagging scheme. I have written a conceptual example at the bottom of this post. 2) Develop one of the following alternatives: 2a) Develop a plug-in to the mailing list software which will effectively submit a copy of each email to the TRAC project associated with the mailing list. I don't really like this solution since there are so many mailing list handlers in existence these days. I would prefer to pursue the strategy of the next item. 2b) As an alternate solution to item 2a, develop the plug-in mentioned in item #1 to understand SMTP protocol and simply receive the email as a CC from the list. This has the advantage of not having to mess with the mailing list installation at all beyond directing a copy of all posts to the TRAC email handler. It has the drawback, however, of requiring an implementation of the evil SMTP protocol. It could be built as an XML service, but then we're back to the 2a scenario. Once built, the solution would work like this: 1) A poster to the list submits email with special markup delimiting bits of text which should be added some WIKI page on the TRAC project that the list is supporting. 2) The text is cross posted to the TRAC plug-in, via either the component developed in item #2a described in the previous paragraph, or by CC if the strategy described in #2b is built. 3) After processing by the component, the new information appears as an appendage to the associated wiki page, perhaps with annotation as to its source or perhaps as a comment to the page (don't know if the default TRAC wiki permits comments appended to a wiki page) 4) Some friendly soul takes on the task of moving the new information into a more appropriate context on the affected wiki page in an unmanaged wiki-like manner. PROS and CONS: Some may worry that we will unnecessarily spoil the WIKI with a lot of spurious information, but consider the following: 1) The poster must be aware of the automation and the markup language that will cross post their comments to the project wiki 2) One would expect that the poster has done a little bit of research into which page should receive the additional information. 3) Since posters to the list must join to participate, a configurable option might be to only cross post comments from people on the known list of subscribers. This would prevent spambots from having their messages automatically added to people's TRAC projects. :-) 4) The default behavior should be to only allow additions to existing pages; this would prevent the creation of a myriad of almost-the-same-name pages with a single item in them due to typos. All of the mismatches could be aggregated into a junk drawer page, or simple ignored. A configuration option could be built to permit new pages to be created by a short list of trusted parties. 5) Something would need to be done to prevent quoted text from being appended more than once. This might be as simple as demanding that the starting and ending markup tags be left justified each on their own line. Any embedded or indented delimiters would simply be ignored by the parser. If we are fully signed on to the WIKI mindset, we should all be confident that someone will see the new comments and take on the editor's task of putting the new information in context on the page. I think that the gain from capturing the information from the experts responding to the list would far outweigh the chaos created by appending the information to the wiki. Also if people are concerned that they would start hammering their TRAC website with thousands of copies of emails, you could post to the wiki in digest mode and only hit it a few times per day. Since the plug-in is extracting specially marked up text only, it should make no difference if it is 100 little postings or 1 huge one. ----------------------------------- Example markup text (I would suspect that TRAC formatting might work out of the box): <wiki:SomePage> THIS TEXT SHOULD APPEND TO SOME PAGE </wiki> Curt Eckhart The Florida Legislature Office of Legislative Information Technology Services Office : (850) 488-5340 "A successful tool is one that was used to do something undreamt of by its author." - Stephen C. Johnson _______________________________________________ Trac mailing list Trac at lists.edgewall.com http://lists.edgewall.com/mailman/listinfo/trac
Dave Brewster <dbrewster at guidewire.com> reported on the mw mailing list:
I was kicking around a similar idea here for our development group. My thoughts were to create a program that would plug into sendmail. This would harvest the email sent to an address and add it as a wiki page; very, very similar to Eckhard's. IMHO, the *really* important stuff is what the markup in the email should look like. Our primary use of this will be for HowTo's. I.e. when someone figures out how to do X, they simply copy the email thread to the wiki by supplying a CC and adding some markup. I was thinking something like this in the email: <topic namespace="development" name="How to get a Location's bundle for tests"> One of the improvements we made to Location bundle handling was to deny external access to the Location's bundle in general (so Location.getBundle() went from public to protected). However in tests you might want to do things like verify that a given bean is in the Location's bundle. For that sort of thing there is a new static test method LocationTest.getLocationBundle(Location), which should be self-explanatory. </topic> The markup I created is really geared toward a discussion group. I would think the topic tag would also accept things like category. Thoughts?
Dave later reported that he didn't get a chance to work on this.