Another option is to setup a wiki so that the entire dbmail community can easily collaberate on developing comprehensive documentation.

PhpWiki (PHP): http://phpwiki.sourceforge.net/phpwiki/
TWiki (Perl): http://twiki.org/

jbw



Micah Stevens wrote:
I think this is a fine idea, I have quite a bit of experience with building PDF's on the fly with PHP. If this documentation is maintained in a database, casual surfers could peruse an HTML version, and a current PDF version could be generated with largely the same code on the spot. I'd be willing to donate time for this. I know there's current documentation software out there as well, I bet I could build dynamic PDF code for that too. I'd also be willing to write, which I'm not bad at if that's needed. I really like the ability for users to post comments such as is used on the php site and (badly IMHO) on the mysql site. I've got a server I could host this stuff on too if dbmail.org wants a doc subdomain, or a mirror.
-Micah


On Wed June 18 2003 4:54 am, Feargal Reilly wrote:

Since I started this thread, here's my thoughts.

Documentation is *always* the hardest thing to get people to do.

If somebody has decent coding ability, they'll prefer to contribute to a
project by fixing bugs, or adding features. (They will of course fail to
document these contributions too :) )

There are usually a slew of users who do not have the ability to
contribute in this way, but they do have the experience of MAKING IT
WORK. These are the people who think, "Wow! This really helped me out, I
wish I could give something back." They may be sysadmins who don't code,
but know how to read man pages. They may be C hackers who faint at the site
of Perl. Whatever. Given the opportunity to present their experiences
though, they will.

And since this is the hardest thing to get people to do, you have to make
it as easy as possible for them. Given this, as much as I love LaTeX, and
as useful CVS is, very few people will learn the unfamiliar just to
contribute a flag they found useful with procmail.

It was with this in mind, for another project that I hacked up a web
interface for people to use. I've thrown it up an example at
http://www.helgrim.com/dbmaildocs/

The interface is at http://www.helgrim.com/dbmaildocs/manage/ username and
password is 'guest'

Everything is stored in a database, HTML generated on the fly, PDFs
periodically. Since it's aimed at HTML, there'd be no problem generating
LaTeX files too.

There'd be no problem setting it as docs.dbmail.com, or for the dbmail guys
to grab the files periodically.

Comments?

-fr.

--
Feargal Reilly,
Codeshifter,
Chrysalink Systems.


On Wed, 18 Jun 2003 13:26:14 +0200

Magnus Sundberg <[EMAIL PROTECTED]> wrote:

lou wrote:

In some email I received from Roel Rozendaal - IC&S <[EMAIL PROTECTED]> on
Wed, 18 Jun 2003 12:17:08 +0200, wrote:

<snip>

I think so, easy to update, and add automatically date automatically
for the last update also it's very simple.
I also think LaTeX.

Any other ideas? Since we manage to agree on the future existence of
dbmail-doc. There're some more stuff to be discussed. Forms and stuff,
blahblah you know.

I disagree on the LaTex issue, I believe we should use the
infrastructure from the Linux Documentation Project. To make it
consistent with most other documentation.

Another approach is some kind of databse driven manual, something
like the online mysql manual with comments.

I doubt I will be writing any documents of the former type, but I
am quite shure I will contribute with comments to the later.

Magnus



_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail


_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to