Jump to content

User:Sysy~metawiki/page creation by email

From Meta, a Wikimedia project coordination wiki

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.