wiki software

[Matt Aimonetti]

While this is probably not a crucial move, I'd like to start talking about the technical solution to use.

Because we are a bunch of developers we might spend quite a long time figuring out what tools we want to use.
I strongly believe that people working on the wiki should use a tool that they feel comfortable with.

Here are some missing features that I would like to see:

- code highlighter
- different layouts/style (ideally, I'd like to have different sections color coded)
- ACL so we can lock some key pages and let the moderators manage them (that's what's done on the merb wiki and most popular wikis)
- active development and support
- proven solution already used by many other sites

Any other features you think is needed?

I'm afraid the existing solution is very limited, so we might want to look at other solutions.

Another question that should be addressed is:  does it have to be a ruby based wiki.
I personally think we should choose the best tool for the work we have to do, but what do you think?

- Matt

[Chris Conrey]

Ideally the best tool would also be ruby based, but if it is not then I don't think we should limit ourselves to ruby.  

Chris Conrey
chrisconrey.com

[carlopecchia]

On technical standpoint I think DokuWiki - already used for Merb wiki
- is a nice tool.
Personally I don't mind it's NOT ruby based...


Matt Aimonetti ha scritto:

[Theodore Mills]

I believe it must be a RoR solution.

If we are to truly advocate for Ruby on Rails it seems we should eat
our own dog food. If a an adequate RoR solution doesn't totally meet
our needs, then we improve upon one that already exists or we create a
new solution. Either way we end up contributing back to the RoR
community.

[Will Weidendorf]

I think that in an ideal situation, we would use the best tool for the job.  However, I think it would be a little bit discouraging to new developers in that their first stop for rails information is not powered by ruby let alone rails.  I think this is a scenario where we have to eat our own dog food.

-Will

[Chris Conrey]

In the long term I agree - we should most assuredly eat our own dogfood.   But for the initial pass at this - if RoR doesn't do the job the best, then we should get something up and running first - then iterate to RoR as we get something built.

Chris Conrey
chrisconrey.com

[Matt Aimonetti]

In theory I agree with using Ruby whenever we can, but I'm not willing to write a wiki and maintain it just for the website. I would also want to avoid half baked products which lack serious support.
Merb switched to dokuwiki and I never heard a single complain or a newbie saying he won't use merb because merb's wiki runs on a  PHP solution.

Heck, Rubyforge is a PHP solution (and a pretty awful one) and nobody complains or offer to write a newer/better version in Ruby.

- Matt

[Carlo Pecchia]

I agree with Chris: in the long term - and only in the long term - we
should focus on a RoR based solution.
For now let's use something nice coded, with which people should feel
comfortable and well tested (and DokuWiki, AFAIK, is a great
solution...).

If we spend too much time coding a nice RoR wiki - with all needed
feature - we can waste precious time...


2009/1/13 Chris Conrey <con...@chrisconrey.com>:

--
Carlo Pecchia
email: c.pe...@gmail.com

[Shane]

While re-inventing the wheel may not be ideal in every situation, I
think this is one that may be useful. Especially if the code is well
written, well documented and made available to the public. I don't
think it needs to be all things to all people, just a simple well
thought out wiki with relevant and useful information for people.

[Chris Conrey]

Dokuwiki seems to be a great fit from the research I've done so far.... plus merb is already using it and so are others mentioned above.

Chris Conrey
chrisconrey.com
Human->Geek Relations at Integrum
@conrey on Twitter

[Thomas Meeks]

I'm fine with using a non-rails solution so long as it already has everything we need. We shouldn't get into the situation of slapping more functionality onto a non-rails wiki, it would defeat the point.

If we decide to do a non-rails wiki now & write a rails one going forward, everyone needs to keep in mind the massive pain data migration is going to be. Always is. Though it would be interesting to write the wiki as a big example app for rails.

Anyone have experience with instiki?

Thomas

[Pratik]

If you guys are serious about a Rails based solution, check out
http://github.com/jeremymcanally/perwikity/tree/master I love the idea
behind it.

--
Cheers!
- Pratik
http://m.onkey.org

[Carlo Pecchia]

Instiki - in my little experience - is not so good for a widely used
wiki, it's more tailored for small team and small set of pages (export
too it's not - were not - so impressive...)

2009/1/13 Thomas Meeks <tho...@thomasmeeks.com>:

[Dana Jones]

I'm on the side of using whatever is the best tool for the job,
whether it is Ruby-based or not. I believe developers are used to
working with a variety of products and technologies - from Javascript
to Photoshop to screencasting software - and really wouldn't much care
what the wiki is written in. The big story will be the stuff on the
shelves, not the shelves themselves.

My .02.

Dana

[Damir Zekić]

One could also argue that there is no point in developing new rails
wiki solution at this exact moment. If the development would start
right now (just for the sake of eating our own dog food) then it
should be really based on rails edge, for it would only make sense if
it was RoR 3.0 ready.

Personally, I don't think that we need such a hassle.

+1 for the best existing solution.

Damir

[Dana Jones]

Good point, Damir. But maybe that's a project the Activists could put
on their radar, as a way of further advocating Ruby/Rails/Merb?

Dana

[Matt Jones]

While there are some solid existing solutions, I think that it could
be really helpful
to have a Rails-based wiki, as an detailed example for large-scale
apps in Rails.
Far too often, the only examples available for most technologies are
tiny, "toy"
applications; a real-life codebase would give Rails quite a boost. It
could also be viewed
as a giant-sized integration test for the whole framework, or as a
basis for doing more
optimization of the Rails core.

But now is the perfect time to migrate to *something* new, as
significant amounts of old
content are going to need to be revised/changed/totally rewritten for
Rails 3 anyway...

--Matt

[Matt Aimonetti]

While writing a new Rails3 based wiki is an interesting project, I think it might not be part of the scope of our current project.
We need the wiki to be totally awesome by RailsConf which is in May.

If people are interested in leading the dev of a kick ass Rails 3 based wiki, we will certainly encourage them but we can't wait for that to happen before we get started.

Let's keep on arguing tho, I want to hear all the opinions, maybe someone knows a RoR based wiki that's awesome and we could use right away.

- Matt

[robokos]

I must say I agree with Theodore and Wills assertions that we must eat
our own dog food when it comes to the wiki. For one of the first
tangible outcomes of the Rails Activists to be a relaunched Ruby On
Rails wiki written in something other than Ruby On Rails would quiet
frankly *be seen* to be a lack of faith in our framework (even if this
isn't a factual observation).

Just wanted to highlight the potential PR implications of a non-Ruby
On Rails solution. Remember, this group will have high visibility and
the commentators will be quick to attack.

Perhaps the best solution for expediency would be to have a certain
part of the site in ruby on rails and then migrate other parts over
time.

-Rob

On Jan 14, 7:04 am, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> While writing a new Rails3 based wiki is an interesting project, I think it
> might not be part of the scope of our current project.
> We need the wiki to be totally awesome by RailsConf which is in May.
>
> If people are interested in leading the dev of a kick ass Rails 3 based
> wiki, we will certainly encourage them but we can't wait for that to happen
> before we get started.
>
> Let's keep on arguing tho, I want to hear all the opinions, maybe someone
> knows a RoR based wiki that's awesome and we could use right away.
>
> - Matt
>

[Matt Aimonetti]

Rob,

 Are you volunteering to write a Rails wiki? How long do you think it will take to finish it so we can start working on it? What about migration to Rails3 and on going support?

I would honestly prefer to have a Rails based wiki, or even a ruby based wiki if it would fit our needs, but so far, the only suggestions were:
- let's write a rails wiki
- let's look at a recent, unfinished experimentation in Ruby (see Pratik's email)

The wiki needs to come back to life pretty quickly and I unless we find a Rails based solution, I'm afraid we will have to get started on something else until someone writes something we can move the wiki to.

- Matt

[Dave Newton]

Matt Aimonetti wrote:
> Are you volunteering to write a Rails wiki? How long do you think it
> will take to finish it so we can start working on it? What about
> migration to Rails3 and on going support?

<ObLurker>

Writing an RoR wiki when the "deadline" for better wiki *content* is
March (by my calculations < 2 mos) is a Really Bad Idea.

Focus on content. *Then* focus on platform. Content migration is a far
smaller (while still irritating) problem when compared to writing a
full-featured wiki. Put a disclaimer in if you're really offended by
running on a non-RoR wiki, or use a lame RoR wiki and suck it up until
it's fixed or a new one exists.

YMMV.

Dave

[Chris Conrey]

And we have a winner.   Content first - Platform a distant 2nd.
So now which non-ruby Wiki do we want to use?   

DokuWiki, MediaWiki, Insitki?

Chris Conrey
chrisconrey.com
Human->Geek Relations at Integrum
@conrey on Twitter

[Matt Aimonetti]

We decided to use DokuWiki for merb because it had the features we need and we had someone who knew the system and set it up for us.
It's an ok solution with really nice code highlight and a simple ACL. Templating the wiki is a total pain but that shouldn't be a major drawback. (or maybe I just suck at dokuwiki)
The wiki app is pretty well supported and used by a lot of people. The fact that it doesn't use a DB makes it easy to export/backup.

JQuery uses mediawiki and their integration looks really nice.

I don't want to push one specific software, we need people who are going to support the wiki setup and write content to choose.

Hopefully, someone is going to write a Rails3 wiki and we'll be able to migrate smoothly later on.

- Matt

[BJ Neilsen]

I've worked with DokuWiki and MediaWiki. DokuWiki is more geared towards developers, while media wiki aims at bringing the same experience as wikipedia. Frankly I don't like the navigation from either, but if I had to choose I'd pick dokuwiki because of it's extensive plugin repository. Instiki is out of the question (in my humble opinion), since it seems intent on making sure that navigation is an after thought. If we truly want the information accessible, we need to make sure people can navigate to it properly. I do agree that content is a first, platform a possible second. I find it interesting that no one has flamed merb for using a php solution, unless I'm just missing something here.

I also would like to put in a plug that I always thought it was a shame that the plugins page in the RoR wiki didn't even have search capabilities. I know that agile takes care of it, but it seems semi-trivial once the list is compiled. 

Just my two cents.

BJ Neilsen

rand9.com

[Thomas Meeks]

DokuWiki sounds like the right choice to me. Tossing my vote that way.

[Thomas Meeks]

Also, unless if all the sysadmin stuff is already lined up, I'm willing to set it up/maintain/monitor/do the sysadmin stuff for DokuWiki. Found myself a knack for it.

Thomas

[Dana Jones]

I haven't had to implement a wiki before, so I'm willing to follow the
decision of those with more experience on which specific software to
use.

Dana

[Kevin Moore]

My only request while looking at Wiki implementations is an eye towards data portability. I've heard horror stories about MediaWiki's format (a lot of weird PHP-specific nuances).

The more 'standard' or at least simple the wiki format, the easier it will be to migrate to some future, wonderful rails based solution.

[Elomar França]

+1 vote for dokuwiki. I have no experience implementing a wiki, I just use them a lot and I think dokuwiki is more user-friendly.

The guys wanting to eat our own dogfood can take a look at Wagn [http://wagn.org/Wagn.org]. Wagn is a Rails Wiki under GPL. If it is something close to what we need we can dive into the project and help it to get better, in order to migrate the Rails Wiki to it _after_ we clean the content.

Best,

Elomar França
elo...@maisweb.org
maisweb.org/blogdoelomar
Mozilla Campus Rep.

[Brian Rose]

+1 for DocuWiki.

Just because we're advocating a software language/framework doesn't
mean we can't step outside those bounds in order to get the best tools
in front of our users. It's more important to have a fully-baked
solution in PHP than a half-baked solution in Rails. Besides, users
should be so happy with the content of the wiki that the software
package itself will be unimportant to them.

Brian

On Jan 13, 1:09 pm, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> We decided to use DokuWiki for merb because it had the features we need and
> we had someone who knew the system and set it up for us.
> It's an ok solution with really nice code highlight and a simple ACL.
> Templating the wiki is a total pain but that shouldn't be a major drawback.
> (or maybe I just suck at dokuwiki)
> The wiki app is pretty well supported and used by a lot of people. The fact
> that it doesn't use a DB makes it easy to export/backup.
>
> JQuery uses mediawiki and their integration looks really nice.
>
> I don't want to push one specific software, we need people who are going to
> support the wiki setup and write content to choose.
>
> Hopefully, someone is going to write a Rails3 wiki and we'll be able to
> migrate smoothly later on.
>
> - Matt
>
> On Tue, Jan 13, 2009 at 1:02 PM, Chris Conrey <con...@chrisconrey.com>wrote:
>
> > And we have a winner.   Content first - Platform a distant 2nd.
> > So now which non-ruby Wiki do we want to use?
>
> > DokuWiki, MediaWiki, Insitki?
>
> > Chris Conrey
> > chrisconrey.com
> > Human->Geek Relations at Integrum
> > @conrey on Twitter
>

[Liam Morley]

I've heard a lot that DokuWiki is "developer-focused", which is great
(as we're developers), but I've never heard what that really *means*
in terms of features. I know it has code highlighting, but what else?
Let's get a feature grid going-- features we want, matched up to which
wiki solutions support those features.

Here's what I'm hearing so far:

- code highlighter
- different layouts/style (color-coded sections?)

- ACL so we can lock some key pages and let the moderators manage them

- active development and support
- proven solution already used by many other sites

- data portability
- separate area for discussing the page for a topic
- stored in files outside of a database? managed in a git repository?

It's tough to represent a features matrix over email, so in true meta
form, I've added a page to the existing Rails wiki at
http://wiki.rubyonrails.org/rails/pages/FutureWikiSolutions to discuss
the future wiki solution. The page isn't linked from anywhere on the
wiki, so you folks are the only ones that know about it. Can people
familiar with these solutions add whether these features are
supported?

Liam

> > On Tue, Jan 13, 2009 at 1:59 PM, Dave Newton <newton.d...@yahoo.com>  

[Liam Morley]

"separate area for discussing the page for a topic"

I added a feature to the list but left out any clarification on what
I'm talking about.

One thing I've always liked about wikipedia-styled wikis is that, for
each topic, they have a tab for discussing the topic.

Often times on the Rails wiki (implemented in Instiki), I've seen
discussion on a particular topic interlaced with the content for that
particular topic. This damages the readability of the content, as well
as the authority of the content.

However, this discussion can often times be very useful. Say for
example if you have a page that shows an implementation of a
particular Rails feature, it's helpful for people to be able to talk
about that implementation. Maybe somebody doesn't know what a
particular line is doing and they want to ask, or maybe somebody spots
a potential bug or a code smell but wants a second opinion before they
blow away the existing code.

I know that on the Merb wiki, there have been times where I've wanted
to add/remove content on a topic, but I've been unsure as to whether
my changes would be helpful, so I've held back.

I think that *because* we want the Rails wiki to be an authoritative
source, and at the same time a wiki that anybody can edit, it's
important that we make it a comfortable place for making change. I
think that discussion pages for each topic are a good solution to this
issue. Thoughts?

Liam

On Jan 13, 6:14 pm, Liam Morley <imo...@gmail.com> wrote:
> I've heard a lot that DokuWiki is "developer-focused", which is great
> (as we're developers), but I've never heard what that really *means*
> in terms of features. I know it has code highlighting, but what else?
> Let's get a feature grid going-- features we want, matched up to which
> wiki solutions support those features.
>
> Here's what I'm hearing so far:
>
> - code highlighter
> - different layouts/style (color-coded sections?)
> - ACL so we can lock some key pages and let the moderators manage them
> - active development and support
> - proven solution already used by many other sites
> - data portability
> - separate area for discussing the page for a topic
> - stored in files outside of a database? managed in a git repository?
>
> It's tough to represent a features matrix over email, so in true meta

> form, I've added a page to the existing Rails wiki athttp://wiki.rubyonrails.org/rails/pages/FutureWikiSolutionsto discuss

[Doug Johnston]

On Jan 13, 3:14 pm, Liam Morley <imo...@gmail.com> wrote:
> It's tough to represent a features matrix over email, so in true meta

> form, I've added a page to the existing Rails wiki athttp://wiki.rubyonrails.org/rails/pages/FutureWikiSolutionsto discuss

> the future wiki solution. The page isn't linked from anywhere on the
> wiki, so you folks are the only ones that know about it. Can people
> familiar with these solutions add whether these features are
> supported?
>
> Liam

Thanks for creating that page, Liam...on the current wiki! Gave me a
laugh. I've already started adding some info.

I've used both DokuWiki and MediaWiki and feel that both would be good
choices. I agree that a Rails-based wiki would be preferred, but I
don't know of one that is feature-rich enough to do what we want out
of the box. It's similar to the Mephisto vs. Wordpress debate.
Sometimes, it just makes sense to go with a more actively developed
and supported product, regardless of platform.

DokuWiki and MediaWiki are both proven solutions and MediaWiki, in
particular, has the added benefit of being the engine behind
Wikipedia. So, it would be instantly recognizable to most Rails
developers and would likely be more widely used and adopted by the
Rails community.

- Doug

[Lindsay Holmwood]

On Jan 14, 8:09 am, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> We decided to use DokuWiki for merb because it had the features we need and
> we had someone who knew the system and set it up for us.

Being the person that set up Merb's DokuWiki, I am very happy to set
up a copy for Rails. :-)

There's a bunch of minor customisations I made that i'd also like to
apply to the Rails DokuWiki to make it a bit more usable.

> Hopefully, someone is going to write a Rails3 wiki and we'll be able to
> migrate smoothly later on.

Also, I'm pretty familiar with DokuWiki's markup and am willing to
write code to transform it to whatever dogfood solution comes up later
on.

Lindsay

[Matt Aimonetti]

DokuWiki seems to get most of the votes and we seem to get some experts, anyone with a strong argument against DokuWiki, please speak now. (We'll wait 24 hours so all the TimeZones will have time to see this email)

Quick DokuWiki questions, does it have plugins to handle:

- version number (I could image we could tag a wiki entry as being valid for 2.3 but not 3.0)
- support for pages in multiple languages?

- Matt

[Pratik]

I don't think the number of votes should decide the software.

What are the advantages of docuwiki over 1) instiki and 2) wagn.org

Personally speaking, I'd just suggest using Github wiki or something
till the software gets finalized. Working on content and the software
can/should happen in parallel.

[Matt Aimonetti]

What are the advantages of docuwiki over 1) instiki and 2) wagn.org

DokuWiki is fully supported by a large community and it's still in development. It's known by many people in this mailing list who had to deal with setting it up and maintaining it.
DokuWiki has great plugins such as a really nice code highlighter, and apparently a translation module: http://www.dokuwiki.org/dokuwiki
DokuWiki has a full ACL system allowing for a more granular control of some specific pages.
DokuWiki has a simple export system that allows easy migration.

Personally speaking, I'd just suggest using Github wiki or something
till the software gets finalized. Working on content and the software
can/should happen in parallel.

I'm not sure what software you are referring to. I wouldn't want to wait until a new rails wiki is being written from scratch. But I totally agree that content and software can happen in parallel.

- Matt

[Pratik]

On Wed, Jan 14, 2009 at 12:58 AM, Matt Aimonetti
<mattai...@gmail.com> wrote:
>
> What are the advantages of docuwiki over 1) instiki and 2) wagn.org
>
> DokuWiki is fully supported by a large community and it's still in
> development. It's known by many people in this mailing list who had to deal
> with setting it up and maintaining it.

Maintaining/installing a wiki software is by no means any rocket science.

> DokuWiki has great plugins such as a really nice code highlighter, and
> apparently a translation module: http://www.dokuwiki.org/dokuwiki

Using Gist or something like
http://svn.danwebb.net/external/CodeHighlighter is even simpler.

> DokuWiki has a full ACL system allowing for a more granular control of some
> specific pages.

Ya ok. I'm not a control freak though. ACL defeats the purpose of the
wiki. Start calling it CMS.

> DokuWiki has a simple export system that allows easy migration.

Are there more than 0 useful pages on the current wiki ?

[Ted Han]

Perhaps Pratik is referring to the ability to display content in one's
account page? like mattetti.github.com ? i don't know.

On the flipside, what does instiki and wagn.org offer us? :P

[Ethan McCutchen]

Hi all,

I'm one of the guys developing Wagn - thanks for the invitation to
chime in.

We'd be happy to setup/host/maintain a wagn for you if that's the way
you decide to go. Tonight I'll go through the desirable feature list
you guys have been compiling. I don't know DokuWiki intimately, so I
couldn't do a great head-to-head, but I can let you know where Wagn
stands.

Your timing is good. After a long beta -- we first started work on
Wagn in early 2006 -- we're releasing a battle-tested Wagn 1.0 next
month, in time for Recent Changes Camp (2009rcc.org). There would
definitely be some trade-offs: we don't yet have a code highlighter,
for example, but the idea is to make it very easy for rails coders to
add that sort of thing, and in fact we're hoping to push the
boundaries of what can be done with wikis quite a bit. I thought this
did a good job of explaining what we're up to:
http://www.railsinside.com/misc/177-wagn-a-revolutionary-open-source-wiki-on-rails.html

Looking forward to the new wiki, whatever the engine.

- ethan

On Jan 13, 5:34 pm, Pratik <pratikn...@gmail.com> wrote:
> I don't think the number of votes should decide the software.
>
> What are the advantages of docuwiki over 1) instiki and 2) wagn.org
>
> Personally speaking, I'd just suggest using Github wiki or something
> till the software gets finalized. Working on content and the software
> can/should happen in parallel.
>
> On Wed, Jan 14, 2009 at 12:29 AM, Matt Aimonetti
>
>
>
> <mattaimone...@gmail.com> wrote:
> > DokuWiki seems to get most of the votes and we seem to get some experts,
> > anyone with a strong argument against DokuWiki, please speak now. (We'll
> > wait 24 hours so all the TimeZones will have time to see this email)
>
> > Quick DokuWiki questions, does it have plugins to handle:
>
> > - version number (I could image we could tag a wiki entry as being valid for
> > 2.3 but not 3.0)
> > - support for pages in multiple languages?
>
> > - Matt
>

[Ted Han]

Why don't we demand that whatever the software is, we can export it
easily, and thus make migration possible? :p that'll make this choice
somewhat less annoying, as much as i enjoy bikeshedding.

-T

[Matt Aimonetti]

Hi Ethan,

 Great to have you here. It would be great if you could give us your opinion and see how Wagn would work out for us.

- Matt

[Ethan McCutchen]

Thanks, Matt.

Looking through the list I see lots of feature priorities but not a
lot about what you hope the wiki accomplishes. That may be because
you were already clear on that, or because you feel like it's obvious
based on similar wikis, or whatever. But anything you can show or
tell me on the subject could help.

A lot of Wagn's biggest selling points are things that aren't likely
to be on your feature lists, because we haven't come to expect them
from wikis yet. For example, the way we handle nested text (or
"embedding", or "inclusions" or, for the geekier, "transclusions") is
pretty cool because you can edit granular content in place. That
ended up being the basis for our formatting system, which invites you
to develop a lot more patterned content on Wagn then on other wikis.
It's been used for things like companies, user profiles, software
tickets, receipt tracking, etc. So one question would be whether you
foresee a lot of patterned content on the wiki.

Granularity is a big thing separating Wagn from most wikis (which is
why we break content into "cards", not "pages"). Take permissions,
for example. There seemed to be some different ideas on the list about
how you might want to use permission systems, but Wagn's is again more
granular than most. If I were shy about my age, for example, I could
list it on my personal page and make my personal page publicly
viewable but restrict view permissions on my birthday.

Another consequence of our inclusions is that it helps wikizens
embrace a deeply embedded rails virtue: don't repeat yourself (dry).
We end up using and re-using content much more than most wikis because
it's so easy.

As you would guess with all of this emphasis on patterns and re-use,
structure starts to emerge. So Wagn actually has its own query
language (WQL) and its own simple tuple structure (plus cards), which
allow you to build pretty cool things together. I don't usually talk
much about WQL to most groups, but I have the sense this group could
really make great use of it.

Happy to go into that more, but you already had a feature list :).
There are several potential criteria you mentioned valuing that you
should know Wagn doesn't yet fully meet. In order from clearest to
least clear fail:

1. being based on flat files rather than a database. fail: we use a
relational database underneath, which helps us make Wagn serve as a
database itself. We mostly use postgres, though mysql works, and some
have had success with SQLite (we haven't tested it).
2. language support. We have a good ways yet to travel here. It's
important to us, and we've been putting time into early design
discussions and getting some leads to help, but it's not something
we'd have at day 1.
3. Portability. We're still pretty early on in this realm, too,
though it's definitely coming soon. We've got some simple import
capability, but we still haven't had a big push for export. Not that
you'd couldn't get your data: we could easily do a data dump from the
database. It looks to me like portability is a big priority for the
group. If this were a deal-breaker, it's possible that we (or one of
you??) could code something up in a hurry.
4. Separate area for discussion. This is not built-in as it is in
MediaWiki, but (a) we do have workarounds, and (b) we've got cool
plans for making it easy to build any number of auxiliary cards. Our
approach to discussion in general is actually pretty cool. We add
discussion boxes that append content to the card itself. This makes
it look like a blog comment initially, while making it easy to refine
into the main wiki content, which we think is very wiki (all about
refining together, not adding more cruft), while also lowering
barriers. Many who won't edit feel comfortable commenting.
5. Proven solution. Not on the scale of MediaWiki. (What is?) I
don't know about DokuWiki, but I gather they're pretty established.
We've been running sites on Wagn for quite a while. Many are private,
mostly organizational wikis. Connectipedia.org and 2009rcc.org are a
couple of public examples. Wagn isn't half-baked, but I would stop
short of calling it a proven solution. It's been pounded on, and
we're putting out solid releases that we're proud of, but Wagn 1.0 is
inevitably going to have some 1.0 bugs.

There are several others where Wagn would score highly:

1. written in rails. check.
2. different layouts: yes, Wagn's great at that if you mean content
layouts within the page. If you're wanting lots of different page
layouts, we're still early on (though our route ahead is really
promising)
3. ACL - our permissioning is more nuanced than most
4. active development and support. very active: 1.0 is en route,
1.1 is mapped. We're just now getting patches submitted, and we're
working hard to fund a bigger team. Re support, we're small, but we
usually have at least 4 or 5 available on IRC, and we're putting in
good hours on docs

I suspect I missed some features, but I've got to take off for
volleyball :). Happy to respond to questions/ideas/etc when I get
back. btw, thanks Liam and Doug for working on the matrix, and
"lifo" (whose name I haven't decoded yet) for inviting me here.

Sorry for the book. Obviously I'm kind of excited about the idea that
you guys might use Wagn. Would love to give something back to this
community.

- ethan

On Jan 13, 6:18 pm, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> Hi Ethan,
>
>  Great to have you here. It would be great if you could give us your opinion
> and see how Wagn would work out for us.
>
> - Matt
>
> On Tue, Jan 13, 2009 at 5:14 PM, Ethan McCutchen

> <ethan.mccutc...@gmail.com>wrote:

>
>
>
> > Hi all,
>
> > I'm one of the guys developing Wagn - thanks for the invitation to
> > chime in.
>
> > We'd be happy to setup/host/maintain a wagn for you if that's the way
> > you decide to go.  Tonight I'll go through the desirable feature list
> > you guys have been compiling.  I don't know DokuWiki intimately, so I
> > couldn't do a great head-to-head, but I can let you know where Wagn
> > stands.
>
> > Your timing is good.  After a long beta -- we first started work on
> > Wagn in early 2006 -- we're releasing a battle-tested Wagn 1.0 next
> > month, in time for Recent Changes Camp (2009rcc.org).  There would
> > definitely be some trade-offs: we don't yet have a code highlighter,
> > for example, but the idea is to make it very easy for rails coders to
> > add that sort of thing, and in fact we're hoping to push the
> > boundaries of what can be done with wikis quite a bit.  I thought this
> > did a good job of explaining what we're up to:
>

> >http://www.railsinside.com/misc/177-wagn-a-revolutionary-open-source-...

[Theodore Mills]

+1 for Pratik's idea of using the rails wiki on github and gists for
code samples:

http://wiki.github.com/rails/rails

If it's content we should be concentrating on, the github repository
seems to be an appropriate place to start adding it.

-Theo

[Matt Aimonetti]

Thanks Ethan for your detailed email. It looks like I really should
give wagn a try.

It's taco night, so I can't promise I'll give it a try tonight. Anyone
up to give us a quick report?

- Matt

Sent from my iPhone

On Jan 13, 2009, at 18:29, Ethan McCutchen <ethan.m...@gmail.com>
wrote:

[Jeremy McAnally]

A hosted solution might be nice in the sense that it would be minimal
effort on the part of the people involved, but it'd be difficult to
tweak things that we'd likely want to tweak and putting the data in
the hands of someone else may/may not be a good choice (as many of us
learned with Instiki). No offense at all to wagn, as they seem like
great, smart guys; I'm just addressing the general concerns about a
solution hosted by someone else.

Personally, I haven't had a great experience with DokuWiki. It's a
far cry from the terrible time I had with TWiki, but if we're doing
PHP, then why not MediaWiki? Or (x)Wiki? Maybe I'm missing part of
the case for Doku vs. MediaWiki vs. something else. But even further,
as others have mentioned, if we're going to do an installed solution,
doesn't it make sense to eat our own dogfood? That's partially why
development was switched from Trac to Lighthouse/Github. That's why
the main site is backed Radiant now. Why use something PHP when there
are perfectly fine Rails-based alternatives out there. As Pratik
mentioned earlier, I'd like to put forth my fledgling perwikity effort
as a possible candidate to hack into shape: http://github.com/jeremymcanally/perwikity
. It's not perfect or complete by any means, but I can spend a good
deal of time on it in the next week or so to get it in shape if it's
what we decide on.

I can hack the rest of your required features in (along with things
you didn't list like spam protection) by next week. From there we can
strategize about any modifications that need to be done, design, etc.

Just some thoughts.

--Jeremy

On Jan 13, 8:40 pm, Matt Aimonetti <mattaimone...@gmail.com> wrote:
> Thanks Ethan for your detailed email. It looks like I really should  
> give wagn a try.
>
> It's taco night, so I can't promise I'll give it a try tonight. Anyone  
> up to give us a quick report?
>
> - Matt
>
> Sent from my iPhone
>

> On Jan 13, 2009, at 18:29, Ethan McCutchen <ethan.mccutc...@gmail.com>  

[Dana Jones]

Matt,

You touched on something that I was thinking about earlier: version-
related issues. It's probably one of the top 3 questions that pops up
in the #rubyonrails IRC channel: "This worked in v.x but not in v.y."
I think it would be very useful if pages could have some way to mark
sections as being relevant to certain versions in a consistent way
across every page. This wouldn't have to be overly complex - color-
coding the border or background would do the trick. So for example,
everything "special-noted" related to v.2.0 could have a blue border,
everything specific to v.2.1 could have a red border, etc. I expect
most of the content will be version-agnostic, but it would be really
useful to tell at a glance if you're looking at various pages what
special "gotchas" there might be for the version you happen to be
running.

On a related note - and looking ahead a bit to actual wiki structure -
we should, I think, have some area for listing all of the release
notes for each version.

Dana

[Jeremy McAnally]

"...learned with Instiki."

I meant StikiPad. Oops!

--Jeremy

> ...
>
> read more »

[tomkarlo]

I'd like to put in a vote for MediaWiki. It seems like a better choice
for a wiki that will support a broad user-contributor base and I think
Mediawiki fits that a little bit better. I know we haven't decided
this but it seems to me the goal here should not just be a one-time
overhaul of the RoR wiki but more the germination of an initial effort
that will be translated into ongoing and broad-based contributions of
knowledge from the community.

I don't see the issue with not using a RoR solution for this any more
than I'd worry if my RoR book was written using a Ruby-based editor. I
think (hope) that the RoR community favors pragmatism over purism
where possible.

[Matt Jones]

+1 to Pratik's suggestion in the short term; it makes the wiki easy to
find, and seems like
a straightforward suggestion.

In the long term, a solid wiki built on Rails 3 would be desirable, as
many of the mature
solutions are carrying code from older Rails versions (not necessarily
a bad thing, but a fact).
Both instiki and wagn, for instance, have decidedly un-RESTful routes.
I'm not a REST purist,
but give the strong support for the philosophy by Rails (ie
ActiveResource etc), it would be nice
to have a wiki built on those ideas.

Finally, I would love to see an effort to annotate the wiki source
(compare the Linux Kernel Core
Commentary [http://www.scottmaxwell.org/lckc.html], for instance). I
think that some of the
underlying design ideas in Rails can't really be explained in a short
code example, and that a
fully-developed (and annotated) app would be a valuable resource for
beginners to study.

--Matt Jones

[Ted Han]

Investigate before posting! ;)

http://github.com/wagn/wagn/tree/master

[Jeremy McAnally]

Oh my open source. :P Very cool.

I'll definitely tinker tomorrow...

--Jeremy

--
http://jeremymcanally.com/
http://entp.com/
http://omgbloglol.com

My books:
http://manning.com/mcanally/
http://humblelittlerubybook.com/ (FREE!)

[Liam Morley]

If MediaWiki has an area for discussing the content on a page, that'd
be a big win for me. My vote would probably go to MediaWiki for this
feature. But I agree with Pratik, I'm not sure if voting is really
appropriate, as I'd like to see how other wiki solutions map to a
feature matrix.

liam

On Jan 13, 7:29 pm, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> DokuWiki seems to get most of the votes and we seem to get some experts,
> anyone with a strong argument against DokuWiki, please speak now. (We'll
> wait 24 hours so all the TimeZones will have time to see this email)
>
> Quick DokuWiki questions, does it have plugins to handle:
>
> - version number (I could image we could tag a wiki entry as being valid for
> 2.3 but not 3.0)
> - support for pages in multiple languages?
>
> - Matt
>

[Liam Morley]

Ethan, that all sounds pretty cool. The cards concept sounds like it
could be really neat.

I'm trying to think of how this would translate into satisfying Rails
community needs- I'm guessing that because I'm not familiar with these
features, I don't see how they'd make my life easier (although I think
I can see how they'd allow me to do some cool stuff). Do you guys have
some use cases lying around that map some of these awesome features to
user needs?

liam

[Liam Morley]

If you could have this rock-solid ready for whenever we need to start
using it (I imagine that a few of us would be willing to pitch in if
there are areas where others can contribute), and if it would have a
set of agreed-upon features that people are asking for on here, then
this would be a win for me.

I know we want a solution that's been market proven, and that's a
tough obstacle, but I wouldn't want to rule out an awesome rails
solution just because nobody is using it yet. If the Rails Wiki site
is not going to be the first customer of a Rails-based wiki, I'm not
sure why we'd expect anybody else to be. I think if we had a solid set
of tests and metrics, that to me would be enough. BUT we're obviously
going to want to try it out before we decide- if you say you can have
those features ready by next week or so, is it fair (Matt) to wait
that long to decide?

I added Perwikity and Wagn to http://wiki.rubyonrails.org/rails/pages/FutureWikiSolutions
if you guys would like to comment on how it matches up...

liam

> ...
>
> read more »

[Doug Johnston]

On Jan 13, 6:40 pm, "Theodore Mills" <twmi...@gmail.com> wrote:
> +1 for Pratik's idea of using the rails wiki on github and gists for
> code samples:
>
> http://wiki.github.com/rails/rails

This really is a decent option, especially if Tom & Co. would be
willing to show the wiki code some love over the next few months. And
really, aside from code highlighting (gists are a good start), are
features like ACLs and discussion areas really needed on day one?

If we're looking for a proven Rails solution, the github wiki (though
currently a bit feature poor) seems to have stood up pretty well so
far.

- Doug

[Matt Aimonetti]

github is not open source and I believe we can't easily export the wiki data (never tried tho, actually I don't even know how to style the wiki or insert an image).

I'm reluctant to get in bed with a system we don't control or have access to. There is also the fact that github lacks most of the features required.

However, I think gisthub can be a great way to store code and I'm a big fan of github in general. I talked with Chris few weeks ago to see if we could use GH to add comments to the merb book. While, I strongly believe that GH is an awesome tool I don't think their wiki is meant for what we are trying to do.

- Matt

[Dave Newton]

Dana Jones wrote:
> So for example, everything "special-noted" related to v.2.0
> could have a blue border, everything specific to v.2.1 could
> have a red border, etc. I expect most of the content will be
> version-agnostic, but it would be really useful to tell at a
> glance if you're looking at various pages what special "gotchas"
> there might be for the version you happen to be running.

IMO it's not sufficient to have this be at the page level; that whole
"card" thing of wagn leads me to think that a more granular versioning
solution is a better idea.

The problem is that as you say, much of the content will be
version-agnostic--but it's likely that there would be version-specific
information sprinkled between the agnostic bits.

Being able to tag page sections would allow for version-specific viewing
and export. (It would also allow interesting functionality like "guru
mode" that could delve deeply into things many people wouldn't care
about, "n00b mode" that stuck only to the basics and provided
information in a general, overview way, blah blah.)

On a somewhat-related note I'd *really* like to see the ability to grab
snippets out of a repository to allow for "live", up-to-date examples
for whatever is put on there that are "guaranteed" to work, since their
in the repo (and... uh... tested, right?!)

This all sure ties into a long-running project of mine that I don't have
any time to deal with right now :(

Dave

[Ethan McCutchen]

This page is a good example of something I might do a little differently on a wagn:

http://wiki.rubyonrails.org/rails/pages/RailsWebHosts

It's really long, and the information is really inconsistent and tough to search. There's nothing to say you can't do the same thing on Wagn, but you could also make a "Host" card type, and then create a new card for each host.  If you wanted, you could format it so that the same kind of information gets collected about each host.    Then you can show all the host cards on one page, each in a condensed view that shows just a line of info about each one.   You might decide to build other views, to show narrower lists (say by location, or by tags like PHP, ssh, whatever).   We find that we usually start without structure, in flat pages like this, but once patterns start emerging, it makes things a lot more useful to add a little structure.  It's still a very organic, wiki approach, but it grows a little further.

You could do similar things with job postings, plugin repositories, development firms, open source projects, user groups...  Actually, there are *tons* of things on the site that you could make a ton more approachable with some Wagn structure.

On Wagn.org we made Feature cards, for example, with structure that included examples.  One benefit is that it's easy to query for features that don't have examples yet.  It's often a big plus to be able to see what's not there.  This is an extension of Ward's idea with the original wiki of linking to pages that don't exist yet.  The "named void" idea gets expanded dramatically with structure.

It may also be that after using Wagn a bit, you start using it for things that you would never attempt with most wikis.  I can't imagine trying to build a ticketing system with most wikis, but that's how we track our dev.

By the way, Wagn.org is currently set up so you have to request an account to edit.  Happy to give anyone an account, but if anyone just wants to bang around, try sandwagn.wagn.org. 

- ethan

--
Ethan McCutchen
Executive Director, Grass Commons

GrassCommons.org, Wagn.org

skype: ethan.mccutchen
freenode: #grasscommons, #wagn
cell: (541) 521-0422

mean what you pay

[Pratik]

I suggested using Github only as an interim wiki. While people are
busy deciding the color of the software, motivated people ( those
motivated to contribute content and not just comments (-; ) can start
working on the real stuff straight away. This of course, makes sense
only if the new_wiki.ror.org is gonna take more than a week or
something.

[Ted Han]

I actually agree with pratik! /me is shocked.

I'd prefer just to start markdowning documents or whatever (markdown
just happens to be my system of choice), and start sticking content
into it in a way that will let us transition to whatever we determine
is best eventually.

-T

[Doug Johnston]

Essentially, there don't seem to be any Rails wikis that will suffice as-is.  Instiki is dead.  Github is limited and closed source.  Perwikity and wagn both have potential, but need some work.

It seems like we either need to choose a robust, non-Rails solution (DokuWiki, MediaWiki, etc) or form a team dedicated to enhancing one of the Rails options.  And maybe we can use github in the meantime to get some of our ideas out there.  It'd be great to start brainstorming ideas of what the actual wiki content and structure will be.

- Doug

[BJ Neilsen]

If indeed we are contemplating using an non-RoR solution, I think it would be a bad idea to go with DokuWiki (even though I recommended it earlier) because the storage format is file-based. Several people have chimed in that migration of the data later to a RoR solution will be painful, and it would be magnified 10 times if having to migrate from a file solution. Unless Jeremy can get his wiki off the ground within a week or so, my vote is MediaWiki at this stage. If we have a deadline to get this content ready for RailsConf, then the focus should be on content modification/creation. 

BJ

[Andrew Nordman]

I think Mike had a good idea in #rails-activism about possibly splitting into 'writing' and 'implementing' groups so that we can get concurrency going and increase the speed of decision making and delegation.  Regardless of what solution is decided, there's a lot of editing and writing that needs to be divvied up and that doesn't necessarily require the decision of wiki software for work to be done.

Andrew "Cadwallion" Nordman

[Ethan McCutchen]

Correction:  the open-edit wagn you might want to bang on is sandbox.wagn.org (not sandwagn.wagn.org, as I posted last night.  That's just a play copy of wagn.org).

[Darren Torpey]

I agree we need a very granular way to mark version-specific information.

MediaWikis (and Wikipedia, in particular) do stuff like this a lot
where they have specifically-style call-out boxes that note
version-specific information. These are good when the version-specific
info is small and one-off in nature.

Otherwise, you can break each set of examples up by version. This can
get verbose, but it works. Here's an example from MediaWiki's
documentation wiki:

http://www.mediawiki.org/wiki/Manual:User_rights_management

(1.11 and 1.12 are recent versions of MediaWiki)

-Darren

[Matt Jones]

The only problem I see with trying to mark version-specific content is
that
most of the content on the old wiki wasn't specifically written about
old versions
of Rails, it just got that way over time. So an example that was
version-agnostic
today might be '2.2 and below' tomorrow when some new hotness is added.

It would be really incredible if we could create a system where code
examples are
integrated into a working environment and actually *run* against
various Rails versions.
Sort of a CI process for wiki examples.

--Matt

[Jeremy McAnally]

The best way to do it is probably a flag in the wiki software and CSS
classes. So if you really WANT to see only content from Rails 2.3,
you'd have a URL like: http://railswiki/2.3/Blah

The software would pick that up and create a class like:

version-specific { display: none; }
2_3 { display: block; }

Or something. Simple.

That's a bit technical to be discussing at this point I suppose though.

--Jeremy

[David Trasbo]

I just finished reading all the posts of this thread. It's good to see
people's motivation about this, so I would like to point out/suggest
the following:

1. What a wiki is really about is content. So what about starting out
by writing that? Content has to written, updated, and extracted.
2. Start off with a proven solution (that doesn't have to be Rails (or
even Ruby) based).
3. Start the development of an open source Ruby on Rails wiki with all
needed features. Among the advantages is that it can serve as a
powerful example of Rails' flexibility.
4. Migrate the wiki to the Ruby on Rails solution. And yes, this is
easy to say but hard to do. Unless you make effort to choose a
solution that e.g. supports one of the database systems supported by
Rails (MySQL, SQLite3, etc.), and partly the same naming conventions
for database columns and so on.

I agree with the people here that think content is a first-priority,
backend is second-priority. I would like to get some feedback on this.
If anyone has comments, go ahead. :)

--
David Trasbo.
http://twitter.com/datra

[Jeremy McAnally]

You also have markup considerations when migrating; using a system
that uses a homegrown wiki parser then moving to something that uses
Markdown (or vice versa) is going to make things a lot more difficult.
:-/

--Jeremy

[Matt Aimonetti]

So here is where I stand. After reviewing the existing solutions I don't think they are ready to be used and I don't think we should wait for them to become ready. I'll try to be as explicit as I can without hurting anybody's feeling.

- wagn

   While wagn has some compelling features, I don't think it fits our needs. The card system is interesting but I don't see how it fits the big picture. I can however see how it can be nicely used as a link/company/developer/plugin directory. (especially the plugin directory, if we get a proper code highlighter)

- perwiki http://github.com/jeremymcanally/perwikity/tree/master

  While GH says the project started 5 days ago, my understanding is that it started a bit earlier. Perwiki is an interesting project but it will take a lot of work to be as feature full as mediawiki or dokuwiki. The code is clean but there isn't much to it yet. I'm worried this project would be yet another instiki and I don't think we should wait this side project to become mature enough that we can base the entire blog on it.
I would wait until the project matures, is being used by others and is migrated to Rails 3 and then we could re evaluate.

- Matt

[Ethan McCutchen]

Lewis Hoffman built a new card type this morning for highlighting ruby syntax:

http://sandbox.wagn.org/wagn/sample_code

You could add your own here:

http://sandbox.wagn.org/new/Ruby_Syntax

Then these cards are easily included inside documentation anywhere.

-ethan

[Jeremy McAnally]

I didn't start it "sometime before this." Unless you consider like
8-10 days ago a long time.

I'm confused as to why you think it will be another Instiki. Please do explain.

--Jeremy

[Gregg Pollack]

Just wanted to chime in with my opinion here.

From what everyone is saying, I think it's important we move forward
with an existing fully featured wiki, I don't care which.

Get something up really soon so we start generating content ASAP,
which I think should be our first priority.

Having a platform on Rails is secondary. I'd be afraid if we tried to
tackle this at our early stages, it would deter from what is MOST
important: Creating quality wiki content.

I love the idea of creating a fully featured open source Rails wiki
solution. However, this seems like a separate project to me.
Something that would need to evolve over the next few months. Once
it's fully featured and stable we could consider moving over the Rails
wiki to it.

Just my two bits, take em or leave em...

-Gregg

[Matt Aimonetti]

My bad, I thought it was an ENTP internal project or something like that.

I said it "might" become another instiki in the sense that the only major usage would be the rails wiki and the interest in the project might eventually die.

I think it's wiser to get started with a solution that's known to be working right now, let's focus on the content and the content structure while you work on the perwiki. Once the wiki will have all the features, be tested on few sites and will be able to import from the wiki solution we use, then we should migrate the site over to whatever solution that would satisfy our needs.

I think that the focus should really be on the content, and re-evaluating in 6 -9 months isn't a big deal.

- Matt

[Thomas Meeks]

Take a step back and look at this pragmatically.

The content is far more important than the language the wiki is written in. If DokuWiki or MediaWiki were written in rails, we wouldn't even be having this discussion. They might not be perfect, but each has a sane interface, the necessary features, and a ton of community support.

The current rails wikis just aren't there yet. It is something to work towards and I'm sure the rails wiki will switch over when something that is solid, proven, and has a good sized user base comes along.

Baby steps. Doing too much at one time is a recipe for long nights, burnout, and general mayhem. We'll end up with sustainable progress and a nicer solution if we take it slow.

Thomas Meeks

[Ethan McCutchen]

I think the emphasis on content and purpose is spot on.  It's vital with wikis (and software in general), that the tool not get in the way of the task.  It sounds to me like there's a good bit of skepticism about the rails wikis, so I'll just clarify a couple of points and considerations and step back unless you guys have specific questions for me.

The first is that I think Wagn has the features to do everything that I hear you saying you want to do now.  We often make discussion "plus cards" with our current features to accommodate background chats, the language features will almost certainly be in place by the time you need them, and as of this morning we now have code highlighting.

Second, Jeremy brought up some good points about portability: there is no lingua franca in the wiki world.  The closest thing is HTML, which is how Wagn stores everything except links and inclusions.  Most markup libraries don't handle transclusion at all, and there's no standard export or import format, so you have to expect to do some transformations.  So there are definitely arguments against planning to make a big switch in six months.  However, if we go that route, it's actually one of the better arguments for using a rails wiki: it will be easier (or at least less painful) to do manipulations of the data when you export.  So while it's true Wagn doesn't have a big fat "export" button, most anyone on this list could easily export all the data from a console.

And, finally, with a nod to Thomas' advocacy of "baby steps," I should make it clear that it's very straightforward to use Wagn like any normal wiki and not worry about card types or WQL or any of the magic.  I wanted to let you all know about all that stuff so you'd get a sense of all the places the wiki could eventually go if you picked Wagn, not to make you think you needed to do all of that to get started.  I'd recommend baby steps no matter the engine.

The biggest single concern that I can't really answer is the "proven" issue.  Wagn's been pounded on for years, but not by anyone with a high profile website.  We've been so cautious about 1.0 that we went 0.8, 0.9, 0.10, 0.11, but I know 1.0 still sounds scary.  I've got a lot to learn about marketing :).  I resonate with caution but also with Liam's comment: "If the Rails Wiki site is not going to be the first customer of a Rails-based wiki, I'm not sure why we'd expect anybody else to be." 

Thanks, all.

- Ethan

[Dana Jones]

+1.

Dana

[Carlo Pecchia]

+1

PS: nothing prevent a small group of activists to play and try with
Wagn in the meanwhile, reporting impressions and considerations to the
whole group... (my 0.02€)

2009/1/14 Gregg Pollack <greggp...@gmail.com>:

>
> Get something up really soon so we start generating content ASAP,
> which I think should be our first priority.
>
> Having a platform on Rails is secondary. I'd be afraid if we tried to
> tackle this at our early stages, it would deter from what is MOST
> important: Creating quality wiki content.
>

--
Carlo Pecchia
email: c.pe...@gmail.com

[Liam Morley]

I think Jeremy and Ethan make a very good point- if we want to move to
a Rails solution later on, data portability becomes a much higher
priority. And if you want to move over not only the pages but their
history as well (as the history of a wiki, I think, is important too),
you're talking some serious work.

If Matt isn't ready to commit to something that's a work-in-progress
(which is understandable), then which established solution is easiest
to move from?

And Matt, if we, the Rails community, got together and made a sweet
wiki based on either Perwikity or Wagn and these criteria (which would
be a big win for the Rails community) what would it take to blow you
away? Outside of being already in use by 2 or 3 other people. As I
don't think that being market-tested is as important as eating our own
dogfood, IF all other things are equal and all features are solid.

Liam

On Jan 14, 4:59 pm, "Ethan McCutchen" <et...@grasscommons.org> wrote:
> I think the emphasis on content and purpose is spot on.  It's vital with
> wikis (and software in general), that the tool not get in the way of the
> task.  It sounds to me like there's a good bit of skepticism about the rails
> wikis, so I'll just clarify a couple of points and considerations and step
> back unless you guys have specific questions for me.
>
> The first is that I think Wagn has the features to do everything that I hear

> you saying you want to do *now*.  We often make discussion "plus cards" with

> > On Wed, Jan 14, 2009 at 3:43 PM, Jeremy McAnally <jeremymcana...@gmail.com

> > > wrote:
>
> >> I didn't start it "sometime before this."  Unless you consider like
> >> 8-10 days ago a long time.
>
> >> I'm confused as to why you think it will be another Instiki.  Please do
> >> explain.
>
> >> --Jeremy
>
> >> On Wed, Jan 14, 2009 at 12:59 PM, Matt Aimonetti
> >> <mattaimone...@gmail.com> wrote:
> >> > So here is where I stand. After reviewing the existing solutions I don't
> >> > think they are ready to be used and I don't think we should wait for
> >> them to
> >> > become ready. I'll try to be as explicit as I can without hurting
> >> anybody's
> >> > feeling.
>
> >> > - wagn
>
> >> >    While wagn has some compelling features, I don't think it fits our
> >> needs.
> >> > The card system is interesting but I don't see how it fits the big
> >> picture.
> >> > I can however see how it can be nicely used as a
> >> > link/company/developer/plugin directory. (especially the plugin
> >> directory,
> >> > if we get a proper code highlighter)
>

> >> > - perwikihttp://github.com/jeremymcanally/perwikity/tree/master

>
> >> >   While GH says the project started 5 days ago, my understanding is that
> >> it
> >> > started a bit earlier. Perwiki is an interesting project but it will
> >> take a
> >> > lot of work to be as feature full as mediawiki or dokuwiki. The code is
> >> > clean but there isn't much to it yet. I'm worried this project would be
> >> yet
> >> > another instiki and I don't think we should wait this side project to
> >> become
> >> > mature enough that we can base the entire blog on it.
> >> > I would wait until the project matures, is being used by others and is
> >> > migrated to Rails 3 and then we could re evaluate.
>
> >> > - Matt
>
> >> > On Wed, Jan 14, 2009 at 9:57 AM, Jeremy McAnally <

> >> jeremymcana...@gmail.com>

> >> > wrote:
>
> >> >> You also have markup considerations when migrating; using a system
> >> >> that uses a homegrown wiki parser then moving to something that uses
> >> >> Markdown (or vice versa) is going to make things a lot more difficult.
> >> >> :-/
>
> >> >> --Jeremy
>

> >> >> On Wed, Jan 14, 2009 at 11:55 AM, David Trasbo <davidtra...@gmail.com>

[Matt Aimonetti]

Good points Liam.

Re: data portability, I agree, any future solution we might be using should be able to import data from the wiki system we are going to use.

DokuWiki has a very simple structured file system and I can provide anyone interested with a tar file of the data folder for the Merb wiki. Apparently the MediaWiki DB structure is a bit more challenging.


Re: committing to something that's a work-in-progress. After talking with the other activists, we all feel that this would not be a smart move right now.
As mentioned before, I'm familiar with the storage format for DokuWiki, not so much about the mediawiki solution. Regarding history, we can always keep and old version of the blog available for people wanting to check on the history. (I personally don't see that as something critical)


Re: Rails solution. I'm all for a Rails solution, wagn is interesting but I think it's a bit too "different" for a wiki like what we've been talking. As mentioned before, I think wagn's card concept could be very useful if we build a plugin directory or an interface where content is being reused.
Perwikity on the other hand seems to be the right track to be our next wiki solution.
As someone mentioned, we don't use editors/IDEs written in Ruby just because we are Ruby developers, we should use whatever tool is the most appropriate until a Ruby tool comes along and is as efficient or even more efficient than our current solution.

I'd like to get started on the content in the next few days, so we need to decide what technical solution we want.

Talking with Ryan, Mike and Gregg, we decided to go with a ready to go solution and that would be MediaWiki or DokuWiki.

I'm going to start a new thread so we can discuss the pros and cons of each solutions, wiki experts, we need your help.

- Matt

[Kosmas]

Just been reading through all the messages in this thread, and I still
have a question.

What's the main purpose of having the wiki?

I know it may sound obvious, but for me, and I hope for other people
as well, the point is to find information quickly when I need it.

Having used the old wiki, that was a big problem as most of the time
the information was either out of date or was not working.

From my experience, one of the best documentations I have seen is the
MySQL documentation and to a lesser extent the php.
Every time I had to find something about MySQL it was a case of a few
minutes.
As they have separated the documentation into different versions, the
first thing you would have to do is find your specific version, and
then look in the manual for your question.
There is also the option at the bottom for user comments or code
examples.

Is that something worth considering?

P.S. For anyone that hasn't seen it is here: http://dev.mysql.com/doc/

[Vikrant]

+1 for the best wiki solution, independent of language choice.
How would you react if you find Steve Jobs listening on Zune?
1. Where's you iPod, boss?
2. Oh, that's cool!
I'll choose option 2 at least.

On Jan 14, 12:15 am, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> In theory I agree with using Ruby whenever we can, but I'm not willing to
> write a wiki and maintain it just for the website. I would also want to
> avoid half baked products which lack serious support.
> Merb switched to dokuwiki and I never heard a single complain or a newbie
> saying he won't use merb because merb's wiki runs on a  PHP solution.
>
> Heck, Rubyforge is a PHP solution (and a pretty awful one) and nobody
> complains or offer to write a newer/better version in Ruby.
>
> - Matt
>
> On Tue, Jan 13, 2009 at 11:07 AM, Will Weidendorf <wweidend...@gmail.com>wrote:
>
> > I think that in an ideal situation, we would use the best tool for the
> > job.  However, I think it would be a little bit discouraging to new
> > developers in that their first stop for rails information is not powered by
> > ruby let alone rails.  I think this is a scenario where we have to eat our
> > own dog food.
>
> > -Will
>
> > On Tue, Jan 13, 2009 at 1:58 PM, Matt Aimonetti <mattaimone...@gmail.com>wrote:
>
> >> While this is probably not a crucial move, I'd like to start talking about
> >> the technical solution to use.
>
> >> Because we are a bunch of developers we might spend quite a long time
> >> figuring out what tools we want to use.
> >> I strongly believe that people working on the wiki should use a tool that
> >> they feel comfortable with.
>
> >> Here are some missing features that I would like to see:
>
> >> - code highlighter
> >> - different layouts/style (ideally, I'd like to have different sections
> >> color coded)
> >> - ACL so we can lock some key pages and let the moderators manage them
> >> (that's what's done on the merb wiki and most popular wikis)
> >> - active development and support
> >> - proven solution already used by many other sites
>
> >> Any other features you think is needed?
>
> >> I'm afraid the existing solution is very limited, so we might want to look
> >> at other solutions.
>
> >> Another question that should be addressed is:  does it have to be a ruby
> >> based wiki.
> >> I personally think we should choose the best tool for the work we have to
> >> do, but what do you think?
>
> >> - Matt

[Dave Newton]

Vikrant wrote:
> How would you react if you find Steve Jobs listening on Zune?
> 1. Where's you iPod, boss?
> 2. Oh, that's cool!
> I'll choose option 2 at least.

Sure, cool that alien life exists, and can take over human bodies.

Unless he was doing competitive analysis I'd be skeptical he could
tolerate the Zune for any protracted period of time.

Dave

[Ted Han]

Okay that's a useless diversion (although i'd ask about brain cancer
at that point :P ).

WIKI SOFTWARE, we're here to discuss wiki software!

The merb wiki runs on dokuwiki and it's pretty good. I'd personally
prefer markdown to dokuwiki syntax (which i hear dokuwiki can do).

my 2¢

-Ted

[Vikrant]

A bit of correction.
Bill Gates listening on iPod seems to be more obvious (comparatively
at least).
Steve Jobs on Zune is like PHP guys asking to use instiki for their
new wiki project ;)
Or may be that's a stupid correlation.
anyway, +1 again for the best wiki solution, independent of language
choice.

[Joseph]

Call me crazy, but what about starting from scratch and writing just enough to make the project happen?  As an experiment, I started playing around with a from-scratch wiki in Rails, and I was surprised just how little it took to get a basic wiki running.  Developing a from-scratch solution would serve multiple goals:

1. Build a system that can support everything the Rails community needs from a documentation wiki
2. Build a robust, open-source solution - in Rails
3. Guarantees that the Rails community will retain strict control over data formats, etc., to enhance portability
4. It's fun!

Just a thought.


Joseph

PS:
My toy wiki code is over on github.

[Matt Aimonetti]

Hi Joseph,

 Thanks for offering your help. As mentioned earlier the Activists decided to avoid having to deal with both the tool and the content. We decided to go with DokuWiki using the Markdown syntax with the understanding that we are hoping on migrating to a Rails based version in the next months.

DHH is setting up a server and we should get started pretty soon with the content.

This said, I think you have a great idea and I can only encourage to work with us and build an awesome replacement wiki solution.

Thanks,

- Matt

[Joseph]

Yeah.  I just caught up.  Whoops.

I actually need the wiki for a doc site I'm working on anyway, so I'll be building one for myself.  I'll make sure it stays on github.


~J

[Matt Aimonetti]

Awesome.

Keep us posted.

- Matt

[Josh Owens]

Guys,

I hate to point out the obvious, but why not use a Rails project that
is already built and pretty much ready to go?

http://github.com/queso/signal-wiki/tree/master.

Granted, I suppose I have a vested interest, I guess, because I would
like to see more activity on the project, and would welcome the help.
I already have OpenID support, restful auth login system, akismet
support for spam checking wiki posts, etc.

Feel free to check it out here: http://signalwiki.com/


Josh Owens | Handcrafted
m. 513-678-7081
twitter. @joshowens
www.GetHandcrafted.com

On Jan 13, 4:18 pm, "Thomas Meeks" <tho...@thomasmeeks.com> wrote:
> DokuWiki sounds like the right choice to me. Tossing my vote that way.
> On Tue, Jan 13, 2009 at 4:09 PM, Matt Aimonetti <mattaimone...@gmail.com>wrote:
>
> > We decided to use DokuWiki for merb because it had the features we need and
> > we had someone who knew the system and set it up for us.
> > It's an ok solution with really nice code highlight and a simple ACL.
> > Templating the wiki is a total pain but that shouldn't be a major drawback.
> > (or maybe I just suck at dokuwiki)
> > The wiki app is pretty well supported and used by a lot of people. The fact
> > that it doesn't use a DB makes it easy to export/backup.
>
> > JQuery uses mediawiki and their integration looks really nice.
>
> > I don't want to push one specific software, we need people who are going to
> > support the wiki setup and write content to choose.
>
> > Hopefully, someone is going to write a Rails3 wiki and we'll be able to
> > migrate smoothly later on.
>
> > - Matt
>
> > On Tue, Jan 13, 2009 at 1:02 PM, Chris Conrey <con...@chrisconrey.com>wrote:
>
> >> And we have a winner.   Content first - Platform a distant 2nd.
> >> So now which non-ruby Wiki do we want to use?
>
> >> DokuWiki, MediaWiki, Insitki?
>
> >> Chris Conrey
> >> chrisconrey.com
> >> Human->Geek Relations at Integrum
> >> @conrey on Twitter
>
> >> On Tue, Jan 13, 2009 at 1:59 PM, Dave Newton <newton.d...@yahoo.com>wrote:
>
> >>> Matt Aimonetti wrote:
> >>> >  Are you volunteering to write a Rails wiki? How long do you think it
> >>> > will take to finish it so we can start working on it? What about
> >>> > migration to Rails3 and on going support?
>
> >>> <ObLurker>
>
> >>> Writing an RoR wiki when the "deadline" for better wiki *content* is
> >>> March (by my calculations < 2 mos) is a Really Bad Idea.
>
> >>> Focus on content. *Then* focus on platform. Content migration is a far
> >>> smaller (while still irritating) problem when compared to writing a
> >>> full-featured wiki. Put a disclaimer in if you're really offended by
> >>> running on a non-RoR wiki, or use a lame RoR wiki and suck it up until
> >>> it's fixed or a new one exists.
>
> >>> YMMV.
>
> >>> Dave

[Andy Shen]

+1 for signalwiki, it looks good.

[Matt Aimonetti]

guys, we are not coming back on our decision, we are moving ahead with dokuwiki and markdown and will re evaluate in few months.

- Matt

[Josh Owens]

Oops,

Guess we missed the memo... So the post on the 15th asking for
involvement in this group (http://weblog.rubyonrails.org/2009/1/15/
rails-documentation-projects) was already too late for those wanting
to help.

It is sad to see something rejected just because the decision was made
4 days ago and proper input was not asked for publicly. Not all of us
have time to keep up to the minute on our feed readers, and it looks
like even if we did - it was too late.

SignalWiki has ACL support, has been fairly active in the past and
good test coverage. It has some anti-spam tools built-in, follows a
lot of rails best practices, etc. It has content flagging, page
caching, etc.

I get the impression I am beating a dead horse despite nothing being
setup yet. This should be an exciting process, and I realize we need
a strong leader for it, but let's not dictate things and shutdown
community involvement.

On Jan 19, 2:28 am, "Matt Aimonetti" <mattaimone...@gmail.com> wrote:
> guys, we are not coming back on our decision, we are moving ahead with
> dokuwiki and markdown and will re evaluate in few months.
>
> - Matt
>

[Gregg Pollack]

Josh,

The announcement of the wiki project was on my post, January 13th
on the blog:

http://weblog.rubyonrails.org/2009/1/13/activist-status-wiki-project

Not Mike's post. I feel like the opinion of the community was
asked for publicly, and Matt did a great job directing the
conversation. I'm sure you're not the only one frustrated we didn't
decide to move forward with your wiki solution. However, it was
concluded that we're better off focusing on content in an existing
fully featured system, rather then also having to deal with "building"
a wiki system. But you can't please everybody.

So after consulting with the community, we are moving forward with
Docuwiki so we can get quality content up as soon as possible. I
don't think it looks bad for the Ruby community to be using a Wiki
solution that has proven itself in production for a good while now.

However, it would be great to migrate to a fully Rails wiki
eventually, as Matt said. Hopefully you're not discouraged by this
choice, and you think of it as a challenge to build out the features
of your wiki, and create a clear migration path from docuwiki to
Signal wiki.

Just my two bits,

-Gregg

[Dave Newton]

Josh Owens wrote:
> I get the impression I am beating a dead horse despite nothing being
> setup yet. This should be an exciting process, and I realize we need
> a strong leader for it, but let's not dictate things and shutdown
> community involvement.

IMO it's not dictating or shutting down community involvement to stick
with a decision (not saying it can't be changed, just think the rhetoric
is a bit over-stated).

FWIW (which isn't much ;) DokuWiki looks to be more mature and
feature-complete. There's no reason wiki framework development can't
happen in parallel with content development--I'd look at it as an
opportunity to build Signal Wiki (or any other) up with exactly what's
needed. If the original decision is stuck to that would put a RoR wiki
(which we all agree is desirable) in a good position to take over the
mantle.

Dave

[Darren Torpey]

I believe it actually reflects *better* on us as a community that we
made a decision with highest regard for our immediate (and pressing)
needs.

Members of the Ruby and Rails community tend to fancy ourselves as
pragmatists and this decision is precisely that: pragmatic. I am glad
we were able to put (petty) language and platform pride aside to make
the right decision, even if ultimately we can't know for sure if it's
the best. We do know the trade-offs we're making, and we're betting
that we can best use a proven wiki solution to create an effective
addition to the Rails ecosystem as outlined by the Activists and as
will evolve throughout this project.

That said, I would also like to repeat the sentiments express here by
many others in saying that I strongly believe in the community's
ability to create first-class wiki software from a Rails foundation
and by using good Ruby practices.

-Darren

[Josh Owens]

Gregg,

On Jan 19, 10:09 am, Gregg Pollack <greggpoll...@gmail.com> wrote:
> Josh,
>
>     The announcement of the wiki project was on my post, January 13th
> on the blog:
>
> http://weblog.rubyonrails.org/2009/1/13/activist-status-wiki-project
>
>     Not Mike's post.  I feel like the opinion of the community was
> asked for publicly, and Matt did a great job directing the
> conversation.

Thanks for correcting me on when it was posted. Again, asking for
input and closing said input period within 24 hours seems unrealistic
to me.

> I'm sure you're not the only one frustrated we didn't
> decide to move forward with your wiki solution.  However, it was
> concluded that we're better off focusing on content in an existing
> fully featured system, rather then also having to deal with "building"
> a wiki system. But you can't please everybody.

I am not "frustrated" or "displeased" that signalwiki wasn't chosen, I
am frustrated to see the lack of interest in investing in our own
toolset. If everyone keeps choosing DokuWiki or MediaWiki, how we
will ever get Rails wiki's into production? Seems like a bit of a
chicken and an egg problem... Would Rails be where it is today if
only "production level" languages were consider during the early days?

>
>     So after consulting with the community, we are moving forward with
> Docuwiki so we can get quality content up as soon as possible.  I
> don't think it looks bad for the Ruby community to be using a Wiki
> solution that has proven itself in production for a good while now.

I guess we can agree to disagree on this point. Rubyforge uses PHP
and it is embarrassing - how do I evangelize Ruby or Rails when all
the tools are built in PHP?

>
>     However, it would be great to migrate to a fully Rails wiki
> eventually, as Matt said.  Hopefully you're not discouraged by this
> choice, and you think of it as a challenge to build out the features
> of your wiki, and create a clear migration path from docuwiki to
> Signal wiki.

I guess, if given a clear understanding of what it takes to meet the
criteria set forth, I would be willing to put in the time to make
SignalWiki meet the two or three things it doesn't meet now. But
again, I can't force people to use it in production, so one can never
meet that criteria, no?

[Josh Owens]

Dave,

On Jan 19, 10:10 am, Dave Newton <newton.d...@yahoo.com> wrote:
> IMO it's not dictating or shutting down community involvement to stick
> with a decision (not saying it can't be changed, just think the rhetoric
> is a bit over-stated).

I don't think I am over-stating anything here. Posting on the blog
about starting a process and then making a final decision within 24
hours seems like shutting out the community involvement here. Again,
I realize everyone is eager to get moving...

I am all for being pragmatic about getting something up, but at the
cost of shunning all the current Rails wiki offerings available?
Let's be pragmatic and choose a working Rails solution and make some
tweaks to it. I bet if we investigated more than 24 hours, we would
find more than 3 solutions available.

[Jeremy McAnally]

I think perhaps making a decision about a temporary blog solution
within a week is fairly reasonable.

We're not bound to DokuWiki.

--Jeremy