www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D Wiki

reply Brad Roberts <braddr puremagic.com> writes:
This has come up before and never really gone anywhere.  I've considered setting
up a new, modern, wiki for us to migrate to.  Prowiki has a number of
limitations that annoy me at least.  The biggest is it's history management
sucks.  Looking at what changed over time is either too hard for the likes of me
to figure out, or it's broken, or it just isn't available.

That said, I've only ever run one wiki package, mediawiki, and it was a pain in
the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
manage just off the official releases.

Anyone have a wiki package they've actually run (not just used via the web
interface) that they can recommend?  An obvious one is likely to be Trac via
dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).

Would any of you guys volunteer to help migrate content to it if one should
spring up?  I'd be willing to be one of those volunteers, but there's a lot of
content and it really shouldn't be moved over exactly as is.  A lot of
re-organization should be done.

My thoughts were to put it at d.puremagic.com to subsume the entire site, with
the exception of /issues which would continue to be the bugzilla installation.

Thoughts?

Later,
Brad
Jun 07 2009
next sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.

Excellent idea! +1
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.

I've also only run one wiki package too, mediawiki. From my experience it was good wiki software, but far too bloated. I'd also recommend installing whatever software you decide on from source rather than using the debian repositories, from my experience life is a lot easier as you actually know what's going on with the software :P
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).

All I can do is give you http://en.wikipedia.org/wiki/Comparison_of_wiki_software to flick through, to see which packages do what you need, then have a play with some of them.
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.

Volunteered.
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.

Sounds good to me. If you need somewhere to mirror it I also don't mind volunteering for this.
 Thoughts?

While we're revamping the wiki, it might be a good idea to come up with a list of pages we want including in there. My ideas: * Tutorials * What compiler to use on what system/how to set it up ( http://docs.google.com/Doc?id=dghphd83_43ffpdbtcc could help with this) * Build tools (rebuild, dsss, xfbuild etc) * Editor/IDE support * Phobos vs Tango ( http://docs.google.com/Doc?id=dcswwfd8_48hq4fdwhd could help) * D1 vs D2 * Links/resources (dsource, the spec etc) * FAQs * Language comparison (D vs *) * Benchmarks maybe? * Getting support (Newsgroups, IRC etc) I could go on, that's probably enough to keep us going for a while though :P
 
 Later,
 Brad

Jun 08 2009
parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Mon, 8 Jun 2009, Robert Clipsham wrote:

 Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
 setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes
 of me
 to figure out, or it's broken, or it just isn't available.

Excellent idea! +1

One thing I'm particularly interested in gathering is reasons NOT to start fresh on a new site. A lot of +1's is interesting so far as to gather some sort of majority (as if the posters here are actually the majority), but real justifications either way are more valuable to me.
 That said, I've only ever run one wiki package, mediawiki, and it was a pain
 in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.

I've also only run one wiki package too, mediawiki. From my experience it was good wiki software, but far too bloated. I'd also recommend installing whatever software you decide on from source rather than using the debian repositories, from my experience life is a lot easier as you actually know what's going on with the software :P

I have no trouble understanding how software works regardless of who packages it, be it the original distributor or a distribution's maintainer. That's irrelevant. What's relevant is which is easier to maintain in a real running situation over a broad span of time.
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
 (sorry).

All I can do is give you http://en.wikipedia.org/wiki/Comparison_of_wiki_software to flick through, to see which packages do what you need, then have a play with some of them.

Again, I really desire facts from experience, not a grid of feature comparisons. I've done that reading, several times at various points over the years, it's useless for the questions that are really important to me.
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot
 of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.

Volunteered.

Excellent.
 My thoughts were to put it at d.puremagic.com to subsume the entire site,
 with
 the exception of /issues which would continue to be the bugzilla
 installation.

Sounds good to me. If you need somewhere to mirror it I also don't mind volunteering for this.

Offsite backups are likely to be the only real requirement, and I've got that covered already. Thanks, Brad
Jun 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Again, I really desire facts from experience, not a grid of feature 
 comparisons.  I've done that reading, several times at various points over 
 the years, it's useless for the questions that are really important to me.

This might be a good question to ask on stackoverflow.com or slashdot. P.S. As a user, I like mediawiki the best.
Jun 08 2009
parent BCS <none anon.com> writes:
Hello Walter,

 Brad Roberts wrote:
 
 Again, I really desire facts from experience, not a grid of feature
 comparisons.  I've done that reading, several times at various points
 over the years, it's useless for the questions that are really
 important to me.
 


is it is more of an IT'ish question, serverfault.com might be better.
 P.S. As a user, I like mediawiki the best.
 

Jun 08 2009
prev sibling next sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
On Sun, 07 Jun 2009 23:29:46 -0700, Brad Roberts wrote:

 This has come up before and never really gone anywhere.  I've considered
 setting up a new, modern, wiki for us to migrate to.  Prowiki has a
 number of limitations that annoy me at least.  The biggest is it's
 history management sucks.  Looking at what changed over time is either
 too hard for the likes of me to figure out, or it's broken, or it just
 isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a
 pain in the rear.  The debian packaging of it sucks.  I dunno if it's
 any easier to manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the
 web interface) that they can recommend?  An obvious one is likely to be
 Trac via dsource.  I've considered it, but personally I'm really not
 fond of trac (sorry).
 
 Would any of you guys volunteer to help migrate content to it if one
 should spring up?  I'd be willing to be one of those volunteers, but
 there's a lot of content and it really shouldn't be moved over exactly
 as is.  A lot of re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire
 site, with the exception of /issues which would continue to be the
 bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

I was planning to do major reorganization of the prowiki content once I was done with classes. I personally hate wikis, but would be willing to contribute since there really isn't a good alternative. I also believe all obsolete content should be removed, there is little reason to preserve a versioned content.
Jun 08 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jesse Phillips wrote:
 I also believe 
 all obsolete content should be removed, there is little reason to 
 preserve a versioned content.

The reason to keep a versioned content is when people argue about when an idea first appeared and who gets the credit for it. It happens often enough, and has saved my legal bacon on multiple occasions. Besides, storage is so cheap these days that can't be an issue. I was stunned to find 1Tb drives for $89.99. I might even re-rip my CD collection to FLAC <g>.
Jun 08 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright wrote:
 Jesse Phillips wrote:
 I also believe all obsolete content should be removed, there is little 
 reason to preserve a versioned content.

The reason to keep a versioned content is when people argue about when an idea first appeared and who gets the credit for it. It happens often enough, and has saved my legal bacon on multiple occasions. Besides, storage is so cheap these days that can't be an issue. I was stunned to find 1Tb drives for $89.99. I might even re-rip my CD collection to FLAC <g>.

I think he meant to say that there is no need to have obsolete content in the *latest* version if the content is versioned and can be retrieved from the history. I also hate wiki systems. I think even just plain old HTML with a git backend would be orders of magnitude better. other alternatives that come to mind: 1) A CMS - depends on what package you choose but some are very good at organization of content and also no need to deal with different home-grown wiki dialects (I never understood what's the point of replacing HTML. NIH syndrome or something?) 2) google wave server would be extremely awesome once it's released later this year. --yigal
Jun 08 2009
next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Mon, 8 Jun 2009, Yigal Chripun wrote:

 Walter Bright wrote:
 Jesse Phillips wrote:
 I also believe all obsolete content should be removed, there is little
 reason to preserve a versioned content.

The reason to keep a versioned content is when people argue about when an idea first appeared and who gets the credit for it. It happens often enough, and has saved my legal bacon on multiple occasions. Besides, storage is so cheap these days that can't be an issue. I was stunned to find 1Tb drives for $89.99. I might even re-rip my CD collection to FLAC <g>.

I think he meant to say that there is no need to have obsolete content in the *latest* version if the content is versioned and can be retrieved from the history. I also hate wiki systems. I think even just plain old HTML with a git backend would be orders of magnitude better. other alternatives that come to mind: 1) A CMS - depends on what package you choose but some are very good at organization of content and also no need to deal with different home-grown wiki dialects (I never understood what's the point of replacing HTML. NIH syndrome or something?) 2) google wave server would be extremely awesome once it's released later this year. --yigal

The killer feature of wiki's are that they're inline editable. No need to work with multiple systems, just click, edit, view. Yes, you can build that on top of almost any scm. It's really not at all an interesting back end problem. The challenge is ease of use. Later, Brad
Jun 08 2009
prev sibling next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Yigal Chripun wrote:
 ...
 
 I also hate wiki systems. I think even just plain old HTML with a git
 backend would be orders of magnitude better.
 other alternatives that come to mind:

That's pretty much what a Wiki is, except that it has a web frontend to edit the content. Also, there are issues with using plain old HTML (see below).
 1) A CMS - depends on what package you choose but some are very good at
 organization of content

A wiki *is* a CMS.
 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)

<p>Because <tt>HTML</tt> can be <em>damned</em> verbose (and ugly, to boot) at times. Not to mention <strong>hard to read</strong>.</p> Because ``HTML`` can be *damned* verbose (and ugly, to boot) at times. Not to mention **hard to read**. That said, there are some wiki formats that can FRO [1]. They're generally still nicer to use than raw HTML once you know what the hell's going on. I personally prefer reStructuredText over pretty much everything else.
 2) google wave server would be extremely awesome once it's released
 later this year.
 
 --yigal

I doubt that. The demo was very good at being cool, but notice how it *never* showed more than about five people in a conversation at once? How exactly are you going to scale that up to an entire community? Plus, having to manually add everyone to every conversation every time you make a new page would be a tremendous pain in the ass. It's a great replacement for personal email, not so much for ~(personal email). (I'm not saying having a Google Wave server of our own wouldn't be cool; it just isn't appropriate for this task.) [1] Uhh... "flip" right off.
Jun 08 2009
next sibling parent Leandro Lucarella <llucax gmail.com> writes:
Daniel Keep, el  9 de junio a las 08:07 me escribiste:
 That said, there are some wiki formats that can FRO [1].  They're
 generally still nicer to use than raw HTML once you know what the hell's
 going on.  I personally prefer reStructuredText over pretty much
 everything else.

reStructuredText is heaven. I'm writing my thesis using reST (via Sphinx). -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Wake from your sleep, the drying of your tears, Today we escape, we escape.
Jun 08 2009
prev sibling parent reply yigal chripun <yigal100 gmail.com> writes:
Daniel Keep Wrote:

 
 
 Yigal Chripun wrote:
 ...
 
 I also hate wiki systems. I think even just plain old HTML with a git
 backend would be orders of magnitude better.
 other alternatives that come to mind:

That's pretty much what a Wiki is, except that it has a web frontend to edit the content. Also, there are issues with using plain old HTML (see below).
 1) A CMS - depends on what package you choose but some are very good at
 organization of content

A wiki *is* a CMS.

no. I meant a CMS like joomla or something in that category.
 
 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)

<p>Because <tt>HTML</tt> can be <em>damned</em> verbose (and ugly, to boot) at times. Not to mention <strong>hard to read</strong>.</p> Because ``HTML`` can be *damned* verbose (and ugly, to boot) at times. Not to mention **hard to read**. That said, there are some wiki formats that can FRO [1]. They're generally still nicer to use than raw HTML once you know what the hell's going on. I personally prefer reStructuredText over pretty much everything else.

huh? when you compose an HTML message in gmail do you write all those tags?? when you write a word document do you know what is the encoding of the content is?? the format is an implementation detail that should *not* be exposed to the user. a proper CMS provides you with UI to enter your content while a wiki has NO proper UI. the only "advantage" a WIKI system has is that it uses a non standard encoding format that each time you switch to a different WIKI you need to convert all your content. the concept of a wiki is wrong by design.
 2) google wave server would be extremely awesome once it's released
 later this year.
 
 --yigal

I doubt that. The demo was very good at being cool, but notice how it *never* showed more than about five people in a conversation at once? How exactly are you going to scale that up to an entire community? Plus, having to manually add everyone to every conversation every time you make a new page would be a tremendous pain in the ass. It's a great replacement for personal email, not so much for ~(personal email). (I'm not saying having a Google Wave server of our own wouldn't be cool; it just isn't appropriate for this task.) [1] Uhh... "flip" right off.

about google wave, I think you missed the point of the presentation completely. the idea is that the system is extendable with plugins. you will not add people to conversations manually but rather we will have a forum like system built _on top_ of wave with plugins.
Jun 09 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
yigal chripun wrote:
 Daniel Keep Wrote:
 Yigal Chripun wrote:
 ...

 1) A CMS - depends on what package you choose but some are very good at
 organization of content


no. I meant a CMS like joomla or something in that category.

What's the quantifiable difference? The only one I can think of is that CMSes are designed for closed-authorship sites (you have to register and be approved) whereas Wikis are the other way around. But since you can change that, it doesn't seem like a reason to have a CMS, especially since we *want* an open-authorship site.
 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)

boot) at times. Not to mention <strong>hard to read</strong>.</p> ...

huh? when you compose an HTML message in gmail do you write all those tags?? when you write a word document do you know what is the encoding of the content is?? the format is an implementation detail that should *not* be exposed to the user. a proper CMS provides you with UI to enter your content while a wiki has NO proper UI. the only "advantage" a WIKI system has is that it uses a non standard encoding format that each time you switch to a different WIKI you need to convert all your content. the concept of a wiki is wrong by design.

I hate in-browser rich text editors; every single one I've ever used sucked massively. For example, when I was posting on Blogger, I had to write every post manually because their rich text editor was painful and crippled; it wouldn't allow me to do the things I wanted to do. Like use paragraphs. Or insert internal links to footnotes. You know, really bloody basic stuff. Until someone shows me a cross-browser rich text editor that doesn't both blow and suck, I'm sticking to simplified markup; it's the only way I get ANY control whatsoever.
 2) google wave server would be extremely awesome once it's released
 later this year.

 --yigal

*never* showed more than about five people in a conversation at once? How exactly are you going to scale that up to an entire community? Plus, having to manually add everyone to every conversation every time you make a new page would be a tremendous pain in the ass. It's a great replacement for personal email, not so much for ~(personal email). (I'm not saying having a Google Wave server of our own wouldn't be cool; it just isn't appropriate for this task.) [1] Uhh... "flip" right off.

about google wave, I think you missed the point of the presentation completely. the idea is that the system is extendable with plugins. you will not add people to conversations manually but rather we will have a forum like system built _on top_ of wave with plugins.

No, I saw that. I *did* watch it. My point is that Wave is exclusive communication, not inclusive. You start a wave by adding the people you're interested in, then they can add to it. A wiki, on the other hand, lets anyone edit it without explicit permission. Now, maybe you could write a plugin to publish waves to a wiki or something... but at that point, why the hell aren't you just using the wiki itself?
Jun 09 2009
next sibling parent reply yigal chripun <yigal100 gmail.com> writes:
Daniel Keep Wrote:

 
 
 yigal chripun wrote:
 Daniel Keep Wrote:
 Yigal Chripun wrote:
 ...

 1) A CMS - depends on what package you choose but some are very good at
 organization of content


no. I meant a CMS like joomla or something in that category.

What's the quantifiable difference? The only one I can think of is that CMSes are designed for closed-authorship sites (you have to register and be approved) whereas Wikis are the other way around. But since you can change that, it doesn't seem like a reason to have a CMS, especially since we *want* an open-authorship site.

the difference is in the UI (which a wiki doesn't provide) and the format used, i.e. not some wiki format.
 and also no need to deal with different
 home-grown wiki dialects (I never understood what's the point of
 replacing HTML. NIH syndrome or something?)

boot) at times. Not to mention <strong>hard to read</strong>.</p> ...

huh? when you compose an HTML message in gmail do you write all those tags?? when you write a word document do you know what is the encoding of the content is?? the format is an implementation detail that should *not* be exposed to the user. a proper CMS provides you with UI to enter your content while a wiki has NO proper UI. the only "advantage" a WIKI system has is that it uses a non standard encoding format that each time you switch to a different WIKI you need to convert all your content. the concept of a wiki is wrong by design.

I hate in-browser rich text editors; every single one I've ever used sucked massively. For example, when I was posting on Blogger, I had to write every post manually because their rich text editor was painful and crippled; it wouldn't allow me to do the things I wanted to do. Like use paragraphs. Or insert internal links to footnotes. You know, really bloody basic stuff. Until someone shows me a cross-browser rich text editor that doesn't both blow and suck, I'm sticking to simplified markup; it's the only way I get ANY control whatsoever.

what you're complaining is a bug in *implementation* whereas what I complain about is a bug in the *design*. the first I think is easier to fix. I'm sure there must be somewhere on the web a descent implementation of a rich text editor (google must have this somewhere). I'd even prefer a flash widget that would provide proper UI instead of coding in some obscure wiki syntax. IMHO the gmail rich-text editor is descent enough. but if that's not good enough it's always possible to create something better.
 
 2) google wave server would be extremely awesome once it's released
 later this year.

 --yigal

*never* showed more than about five people in a conversation at once? How exactly are you going to scale that up to an entire community? Plus, having to manually add everyone to every conversation every time you make a new page would be a tremendous pain in the ass. It's a great replacement for personal email, not so much for ~(personal email). (I'm not saying having a Google Wave server of our own wouldn't be cool; it just isn't appropriate for this task.) [1] Uhh... "flip" right off.

about google wave, I think you missed the point of the presentation completely. the idea is that the system is extendable with plugins. you will not add people to conversations manually but rather we will have a forum like system built _on top_ of wave with plugins.

No, I saw that. I *did* watch it. My point is that Wave is exclusive communication, not inclusive. You start a wave by adding the people you're interested in, then they can add to it. A wiki, on the other hand, lets anyone edit it without explicit permission. Now, maybe you could write a plugin to publish waves to a wiki or something... but at that point, why the hell aren't you just using the wiki itself?

the current wiki requires to enter a name before you can edit any pages. the reason specified for that is to prevent spam. with wave, the design would be something like a main wave that contains sub-waves. The video shows how to organize multiple waves inside another wave with a list of links to waves in the "main" wave. so for editing the "wiki" you'd just need to add yourself to the main wave and that will allow you to edit any of the sub-waves. I don't see any drastic differences between this and the above description of the current wiki.
Jun 09 2009
next sibling parent reply grauzone <none example.net> writes:
 I'd even prefer a flash widget that would provide proper UI

Oh god... oh god no... I'm going to have nightmares again...
Jun 09 2009
next sibling parent reply BCS <none anon.com> writes:
Hello grauzone,

 I'd even prefer a flash widget that would provide proper UI
 


yah, ditto, OTOH that was in a tone of "if all else fails"....
Jun 09 2009
parent reply grauzone <none example.net> writes:
BCS wrote:
 Hello grauzone,
 
 I'd even prefer a flash widget that would provide proper UI


yah, ditto, OTOH that was in a tone of "if all else fails"....

OK. But you know... someone might actually go and do it. Nooooooooooooooooo!
Jun 09 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
Danny Wilson wrote:
 Op Tue, 09 Jun 2009 18:38:36 +0200 schreef grauzone <none example.net>:
 
 BCS wrote:
 Hello grauzone,

 I'd even prefer a flash widget that would provide proper UI



OK. But you know... someone might actually go and do it. Nooooooooooooooooo!

Oh noes! The horrors of beautiful text! http://labs.adobe.com/technologies/textlayout/ *ducks for cover*

awesome! and they support non latin scripts - RTL is finally supported by flash!
Jun 09 2009
prev sibling parent "Danny Wilson" <bluezenix gmail.com> writes:
Op Tue, 09 Jun 2009 18:38:36 +0200 schreef grauzone <none example.net>:

 BCS wrote:
 Hello grauzone,

 I'd even prefer a flash widget that would provide proper UI



OK. But you know... someone might actually go and do it. Nooooooooooooooooo!

Oh noes! The horrors of beautiful text! http://labs.adobe.com/technologies/textlayout/ *ducks for cover*
Jun 09 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello Yigal,

 Daniel Keep Wrote:
 
 yigal chripun wrote:
 
 Daniel Keep Wrote:
 
 Yigal Chripun wrote:
 
 ...
 
 1) A CMS - depends on what package you choose but some are very
 good at organization of content
 



that CMSes are designed for closed-authorship sites (you have to register and be approved) whereas Wikis are the other way around. But since you can change that, it doesn't seem like a reason to have a CMS, especially since we *want* an open-authorship site.

format used, i.e. not some wiki format.

One major *advantage* of wikies is that the UI is a browser. If I need to install anything (even a plugin, and lets pretend I don't have flash already) I'm not going to be contributing anything.
Jun 09 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:
 Hello Yigal,
 
 Daniel Keep Wrote:

 yigal chripun wrote:

 Daniel Keep Wrote:

 Yigal Chripun wrote:

 ...

 1) A CMS - depends on what package you choose but some are very
 good at organization of content



that CMSes are designed for closed-authorship sites (you have to register and be approved) whereas Wikis are the other way around. But since you can change that, it doesn't seem like a reason to have a CMS, especially since we *want* an open-authorship site.

format used, i.e. not some wiki format.

One major *advantage* of wikies is that the UI is a browser. If I need to install anything (even a plugin, and lets pretend I don't have flash already) I'm not going to be contributing anything.

no. wikies are text based and have *NO* UI. the flash widget was, as you said, "if all else fails" and we do not need to go to that extreme. why is a standards based rich text editor so hard to envision? are we considering supporting all browsers since explorer 1.0 and that's why it's so hard? IMO, this is doable. I am able to compose rich text messages in gmail without the need to learn some obscure wiki format. so maybe gmail doesn't provide support for all possible combinations of html tags but neither is the wiki format. all i'm trying to say is that it's more productive IMO to try to fix the few problems that the current rich text editors have (according to other people's replies) than to give up and just use the wrong design.
Jun 09 2009
parent reply BCS <none anon.com> writes:
Hello Yigal,

 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.
 


No, I understand how wikies work, you use a web browser to edit text content that is then rendered as HTML. The UI is implemented via a web server and a web browser. Saying it has no UI is nonsensical as clearly the system interfaces with a user so it /must/ have a UI of some kind.
 the flash widget was, as you said, "if all else fails" and we do not
 need to go to that extreme.

I hope your right there.
 why is a standards based rich text editor so hard to envision?

Envision? Easy. Implement? Hard. Heck, it's not that easy to do even under something like winforms.
 are we
 considering supporting all browsers since explorer 1.0 and that's why
 it's so hard?

I'm with you on that one.
 IMO, this is doable. I am able to compose rich text messages in gmail
 without the need to learn some obscure wiki format. so maybe gmail
 doesn't provide support for all possible combinations of html tags but
 neither is the wiki format.
 
 all i'm trying to say is that it's more productive IMO to try to fix
 the few problems that the current rich text editors have (according to
 other people's replies) than to give up and just use the wrong design.

In general, you may be correct, but for programmers, the cost of using non WYSIWYG is a lot smaller as we tend to be more practiced at reading around markup of different kinds and the cost of WYSIWYG (loss of flexibility) is much more noticeable because we tend to know and use more of the things that get lost.
Jun 09 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:
 Hello Yigal,
 
 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.


No, I understand how wikies work, you use a web browser to edit text content that is then rendered as HTML. The UI is implemented via a web server and a web browser. Saying it has no UI is nonsensical as clearly the system interfaces with a user so it /must/ have a UI of some kind.

I meant a graphical UI, as in a rich text editor. :) obviously a wiki must have some kind of a UI, as you said.
 
 the flash widget was, as you said, "if all else fails" and we do not
 need to go to that extreme.

I hope your right there.
 why is a standards based rich text editor so hard to envision?

Envision? Easy. Implement? Hard. Heck, it's not that easy to do even under something like winforms.

it's not impossible. and if there is one good enough open implementation it can be re-used.
 
 are we
 considering supporting all browsers since explorer 1.0 and that's why
 it's so hard?

I'm with you on that one.
 IMO, this is doable. I am able to compose rich text messages in gmail
 without the need to learn some obscure wiki format. so maybe gmail
 doesn't provide support for all possible combinations of html tags but
 neither is the wiki format.

 all i'm trying to say is that it's more productive IMO to try to fix
 the few problems that the current rich text editors have (according to
 other people's replies) than to give up and just use the wrong design.

In general, you may be correct, but for programmers, the cost of using non WYSIWYG is a lot smaller as we tend to be more practiced at reading around markup of different kinds and the cost of WYSIWYG (loss of flexibility) is much more noticeable because we tend to know and use more of the things that get lost.

we have a wiki at work (which I despise) and it always confuses me with it's weird syntax: =text= vs. ==text== i can never remember which one is the main title and which is the sub-title. I honestlly prefer html tags over this. I also hate that you need to enter the text, than click preview, then fix the problems, then preview and so on. it feels like i'm debugging my content which is annoying and a waste of time compared to a work flow where you just see the end result in front of you in real time like in MS Word. consider that this is why lyx (gui for latex) renders math in real-time. it's so much easier to write equations when you see what you entered instead of some obscure code to render it. besides, I don't see why programmers must be punished by forcing them to use an inferior UI.
Jun 10 2009
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 10 Jun 2009 10:01:12 +0300, Yigal Chripun wrote:

 we have a wiki at work (which I despise) and it always confuses me with 
 it's weird syntax:
 =text= vs. ==text==
 i can never remember which one is the main title and which is the 
 sub-title. I honestlly prefer html tags over this.
 
 I also hate that you need to enter the text, than click preview, then 
 fix the problems, then preview and so on. it feels like i'm debugging my 
 content which is annoying and a waste of time compared to a work flow 
 where you just see the end result in front of you in real time like in 
 MS Word.
 
 consider that this is why lyx (gui for latex) renders math in real-time. 
 it's so much easier to write equations when you see what you entered 
 instead of some obscure code to render it.
 
 besides, I don't see why programmers must be punished by forcing them to 
 use an inferior UI.

A wiki engine is a text to HTML translator. I've written one, based on the Creole markup syntax, so I sort know what's involved. There are situations in which writing raw HTML is not the better option, such as embedded documentation within source code. Ddoc is a kind-of wiki engine in this regard. There is nothing intrinsically wrong with using a simplified markup syntax via text UI, because it can be better, or the only, solution in some common cases. In order to write a wiki page I do not need any sophisticated software to help me ... I can just do it with the simplest of text editors. By the way, if one can't remember that '=' is a 1st level heading, and "==" is a 2nd level heading and "===" is a 3rd level heading, etc ... then I'm don't know how one can remember all the equivalent HTML tags. I really would not like depending solely on a GUI application to write source code that has embedded documentation. There is a valid place for both models of creating a HTML page. -- Derek Parnell Melbourne, Australia skype: derek.j.parnell
Jun 10 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
Derek Parnell wrote:

 A wiki engine is a text to HTML translator. I've written one, based on the
 Creole markup syntax, so I sort know what's involved. 
 
 There are situations in which writing raw HTML is not the better option,
 such as embedded documentation within source code. Ddoc is a kind-of wiki
 engine in this regard. There is nothing intrinsically wrong with using a
 simplified markup syntax via text UI, because it can be better, or the
 only, solution in some common cases.
 
 In order to write a wiki page I do not need any sophisticated software to
 help me ... I can just do it with the simplest of text editors.
 
 By the way, if one can't remember that '=' is a 1st level heading, and "=="
 is a 2nd level heading and "===" is a 3rd level heading, etc ... then I'm
 don't know how one can remember all the equivalent HTML tags.

it's simple, HTML clearly denotes what's the markup and what's the content and provides clear structure for the document. Wiki formats are fuzzy to me. there's no clear distinction between markup and content.
 
 I really would not like depending solely on a GUI application to write
 source code that has embedded documentation.

that's a completely different use case. we were discussing writing content for the web, not writing D programs.
 
 There is a valid place for both models of creating a HTML page.
 

of course I'd want to be able to paste D snippets and have the system highlight it and parse the inline documentation. however, when people write non-code content they shouldn't be forced to write it in DDOC, should they?
Jun 10 2009
prev sibling parent reply BCS <none anon.com> writes:
Hello Yigal,

 BCS wrote:
 
 Hello Yigal,
 
 BCS wrote:
 
 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.
 


content that is then rendered as HTML. The UI is implemented via a web server and a web browser. Saying it has no UI is nonsensical as clearly the system interfaces with a user so it /must/ have a UI of some kind.


Yup, that sounds reasonable. OTOH I wouldn't use a non-web based GUI for a wiki.
 as in a rich text editor. :)

have you seen the editor used by stackoverflow.com? It has realtime preview and even code highlighting.
Jun 10 2009
parent Yigal Chripun <yigal100 gmail.com> writes:
BCS wrote:
 Hello Yigal,
 
 BCS wrote:

 Hello Yigal,

 BCS wrote:

 One major *advantage* of wikies is that the UI is a browser. If I
 need to install anything (even a plugin, and lets pretend I don't
 have flash already) I'm not going to be contributing anything.


content that is then rendered as HTML. The UI is implemented via a web server and a web browser. Saying it has no UI is nonsensical as clearly the system interfaces with a user so it /must/ have a UI of some kind.


Yup, that sounds reasonable. OTOH I wouldn't use a non-web based GUI for a wiki.
 as in a rich text editor. :)

have you seen the editor used by stackoverflow.com? It has realtime preview and even code highlighting.

not like a batch C++ compiler but more like a python interpreter.
Jun 10 2009
prev sibling parent reply =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the form=

=20

page (*) are listed as having a stable WYSIWYG editor (some of the=20 others are listed as having an alpha or beta one)... Jerome (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jun 09 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Jérôme M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the 
 format used, i.e. not some wiki format.

(*) are listed as having a stable WYSIWYG editor (some of the others are listed as having an alpha or beta one)... Jerome (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software

if these wikies provide a wysiwyg editor than what's the point of not using the standard HTML format as the backend?
Jun 09 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Brad Roberts wrote:
 On Tue, 9 Jun 2009, Yigal Chripun wrote:
 
 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.

are listed as having a stable WYSIWYG editor (some of the others are listed as having an alpha or beta one)... Jerome (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software

the standard HTML format as the backend?

In an attempt to help this thread end... Thanks, the bicycle shed is a nice pretty new color and doesn't need any more paint. Sigh, Brad (Why is it that people can't stick to the original question and avoid the 100% pointless side discussion? No, really, don't answer that)

Consider yourself lucky. At least in this case people don't come with their *own* wiki format. Compare and contrast with the endless recent discussion on how switch should look like... Andrei
Jun 09 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:
 Compare and contrast with the endless recent 
 discussion on how switch should look like...

I think those people deserve some respect because despite the limits of their knowledge and cognition, they are implicitly trying to express the concept that the current design of switch is bug-prone, and that probably almost any alternative switch design is better than the current one. C compatibility is both the best and worst feature of D/C++. Bye, bearophile
Jun 09 2009
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 Compare and contrast with the endless recent 
 discussion on how switch should look like...

I think those people deserve some respect because despite the limits of their knowledge and cognition, they are implicitly trying to express the concept that the current design of switch is bug-prone, and that probably almost any alternative switch design is better than the current one. C compatibility is both the best and worst feature of D/C++.

Perhaps you and I are referring to different discussions. Andrei
Jun 09 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
bearophile wrote:
 Andrei Alexandrescu:
 Compare and contrast with the endless recent 
 discussion on how switch should look like...

I think those people deserve some respect because despite the limits of their knowledge and cognition, they are implicitly trying to express the concept that the current design of switch is bug-prone, and that probably almost any alternative switch design is better than the current one.

I like it.
Jun 09 2009
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
Brad Roberts wrote:
 On Tue, 9 Jun 2009, Yigal Chripun wrote:
 
 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.

are listed as having a stable WYSIWYG editor (some of the others are listed as having an alpha or beta one)... Jerome (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software

the standard HTML format as the backend?

In an attempt to help this thread end... Thanks, the bicycle shed is a nice pretty new color and doesn't need any more paint. Sigh, Brad (Why is it that people can't stick to the original question and avoid the 100% pointless side discussion? No, really, don't answer that)

this is not a pointless side discussion, you asked for alternatives for the current wiki and we were discussing such alternatives. There is no bicycle shed issue here - on the contrary, I'm arguing *against* trying to choose between different wiki formats and instead go for the web's standard format, [X]HTML. if that would have been done in the first place you wouldn't need volunteers to help you convert the content to the new wiki that you are going to choose.
Jun 09 2009
prev sibling next sibling parent Brad Roberts <braddr bellevue.puremagic.com> writes:
On Tue, 9 Jun 2009, Yigal Chripun wrote:

 J?r?me M. Berger wrote:
 yigal chripun wrote:
 the difference is in the UI (which a wiki doesn't provide) and the format
 used, i.e. not some wiki format.
 

are listed as having a stable WYSIWYG editor (some of the others are listed as having an alpha or beta one)... Jerome (*) http://en.wikipedia.org/wiki/Comparison_of_wiki_software

if these wikies provide a wysiwyg editor than what's the point of not using the standard HTML format as the backend?

In an attempt to help this thread end... Thanks, the bicycle shed is a nice pretty new color and doesn't need any more paint. Sigh, Brad (Why is it that people can't stick to the original question and avoid the 100% pointless side discussion? No, really, don't answer that)
Jun 09 2009
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Jarrett Billingsley wrote:
 On Tue, Jun 9, 2009 at 10:40 AM, Daniel Keep<daniel.keep.lists gmail.com>
wrote:
 I hate in-browser rich text editors; every single one I've ever used
 sucked massively.

 For example, when I was posting on Blogger, I had to write every post
 manually because their rich text editor was painful and crippled; it
 wouldn't allow me to do the things I wanted to do.

 Like use paragraphs.  Or insert internal links to footnotes.  You know,
 really bloody basic stuff.

 Until someone shows me a cross-browser rich text editor that doesn't
 both blow and suck, I'm sticking to simplified markup; it's the only way
 I get ANY control whatsoever.

QFT

Okay, but let's choose a wiki that has an _optional_ rich text editor for those of us who aren't technophobic.
Jun 09 2009
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Yigal Chripun" <yigal100 gmail.com> wrote in message 
news:h0jtd5$cnv$1 digitalmars.com...
 2) google wave server would be extremely awesome once it's released later 
 this year.

I'm probably completely out of my league as I haven't been keeping remotely up-to-date with Google happenings, but after trying to deal with Google Code for one program I use, I don't think I have much faith in any other such thing from Google. (But again, I probably don't know what I'm talking about.)
Jun 09 2009
prev sibling next sibling parent eris <jvburnes gmail.com> writes:
Brad Roberts Wrote:

 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.

Brad, I've used MediaWiki, ZWiki and MoinMoin. Despite its silly name, I think I liked MoinMoin the best. It has an ample user base, is written in Python, has reasonable performance, has plugins, doesn't need a database backend and is simple to admin. eris
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

Jun 08 2009
prev sibling next sibling parent reply eris <jvburnes gmail.com> writes:
Brad Roberts Wrote:

 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.

Brad, I've used MediaWiki, ZWiki and MoinMoin. Despite its silly name, I think I liked MoinMoin the best. It has an ample user base, is written in Python, has reasonable performance, has plugins, doesn't need a database backend and is simple to admin. eris
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

Jun 08 2009
parent eris <jvburnes gmail.com> writes:
eris Wrote:

 Brad Roberts Wrote:
 
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.

Brad, I've used MediaWiki, ZWiki and MoinMoin. Despite its silly name, I think I liked MoinMoin the best. It has an ample user base, is written in Python, has reasonable performance, has plugins, doesn't need a database backend and is simple to admin.

MoinMoin also has extensive page revision history support. It will allow you to view/rollback to the previous 100 versions. You can go back further than that, but it thats what the view provides. eris
Jun 08 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Jun 9, 2009 at 10:40 AM, Daniel Keep<daniel.keep.lists gmail.com> w=
rote:
 I hate in-browser rich text editors; every single one I've ever used
 sucked massively.

 For example, when I was posting on Blogger, I had to write every post
 manually because their rich text editor was painful and crippled; it
 wouldn't allow me to do the things I wanted to do.

 Like use paragraphs. =A0Or insert internal links to footnotes. =A0You kno=

 really bloody basic stuff.

 Until someone shows me a cross-browser rich text editor that doesn't
 both blow and suck, I'm sticking to simplified markup; it's the only way
 I get ANY control whatsoever.

QFT
Jun 09 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Mon, 08 Jun 2009 12:40:33 -0700, Walter Bright wrote:

 Jesse Phillips wrote:
 I also believe
 all obsolete content should be removed, there is little reason to
 preserve a versioned content.

The reason to keep a versioned content is when people argue about when an idea first appeared and who gets the credit for it. It happens often enough, and has saved my legal bacon on multiple occasions. Besides, storage is so cheap these days that can't be an issue. I was stunned to find 1Tb drives for $89.99. I might even re-rip my CD collection to FLAC <g>.

That wasn't very clear, my point was, why keep outdated content visible on the page when the entire page is versioned.
Jun 09 2009
prev sibling next sibling parent Nick B <nick.barbalich gmail.com> writes:
Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

Brad You might want to check out silverstripe. Its very good. Go here for the home page: http://www.silverstripe.com/ 100,000 users Go here for the community showcase : http://www.silverstripe.org/community-showcase?start=0 cheers Nick B
Jun 10 2009
prev sibling next sibling parent Helmut Leitner <leitner wikiservice.at> writes:
Dear Brad (and others),

as you know (or maybe not) I've installed the wiki4d as a part of my enthusiasm
for D. There was an older wiki that didn't really work, was unsupported and
slow.

The *real* work was done by Justin Calvarese and all the others contributing.

I did not invest in special adaptations that are typical for such projects
but I supported and kept the it running since March 2003. Last year I moved
it to a new server and the performance is good again.

My personal D-relationship went through ups and lows, but whatever the current
state is, I'll support this wiki as long as it is wanted or needed.

I'm not pissed off, if the community decides to switch. But you should think
about what you really need and not jump on something superficial.

Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.

Sorry, this sounds fuzzy to me. What problem do you actually have? There is a complete RCS-history of each page from day 1, e.g. 140 FrontPage-versions. You have to store your user name with your "Preferences" to access this "Archive", because ProWiki prefers not to expose it to search engine robots. If you are unable to access it, we can probably add/improve some help text.
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.

There are many people who like mediawiki, some dilike it, but all agree that it is easy to get up and running, let's say in 5-30 minutes. You only would need to worry if you want to run the server. Honestly, from what you are writing, I do not think that you are up to this task. The problems always start, when one wants it not to act or look like a flat mediawiki encyclopedia. Or do something beyond the standard features. Basically it should be sufficient for what the D-community needs.
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?

I think the main point is not to decide on some shiny new wiki package but to have someone who guarantees the server, it's performance and support, for the next few years, whatever system it is runnning. Wiki4D has been an easy burden because the people using it have been very nice and intelligent, needing a minimum of external support. Nevertheless I wouldn't mind stopping it, because of the resources it needs. Walter just needs to tell me when to switch the OFF-button. Kind regards, Helmut P.S. Please send me an e-mail in case of something I should react to, because I check this news feed only every other month.
 Later,
 Brad

Jun 16 2009
prev sibling parent =?UTF-8?B?QWxleGFuZGVyIFDDoW5law==?= writes:
Brad Roberts wrote:
 This has come up before and never really gone anywhere.  I've considered
setting
 up a new, modern, wiki for us to migrate to.  Prowiki has a number of
 limitations that annoy me at least.  The biggest is it's history management
 sucks.  Looking at what changed over time is either too hard for the likes of
me
 to figure out, or it's broken, or it just isn't available.
 
 That said, I've only ever run one wiki package, mediawiki, and it was a pain in
 the rear.  The debian packaging of it sucks.  I dunno if it's any easier to
 manage just off the official releases.
 
 Anyone have a wiki package they've actually run (not just used via the web
 interface) that they can recommend?  An obvious one is likely to be Trac via
 dsource.  I've considered it, but personally I'm really not fond of trac
(sorry).
 
 Would any of you guys volunteer to help migrate content to it if one should
 spring up?  I'd be willing to be one of those volunteers, but there's a lot of
 content and it really shouldn't be moved over exactly as is.  A lot of
 re-organization should be done.
 
 My thoughts were to put it at d.puremagic.com to subsume the entire site, with
 the exception of /issues which would continue to be the bugzilla installation.
 
 Thoughts?
 
 Later,
 Brad

At my company, we have been using Redmine for a year now. Redmine is comparable to Trac, but with a lot less effort to maintain, since almost everything is configurable through the web interface *out of the box*. It’s basically a project management application, but the wiki is a crutial part of it, using textile as markup language. And before anyone comes up with another bikeshed-argument: textile is in use by all employees of this company, *especially* non-IT people. We also use it in our home-grown blog software, and not even users submitting blog posts ever had a problem with using it. Most people even really like it because it’s so simple and intuitive! :) I would help setting up a Redmine installation and content migration, too, of course. It’s using Ruby on Rails, btw., and can be either deployed with a mongrel cluster or via mod_passenger (though I don’t have any experience with the latter). ad Helmut: I think Brad knows quite well how to keep a server running and maintain a community website. :)
Jun 17 2009