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?
> 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?
> 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?
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.
On Tue, Jan 13, 2009 at 1:01 PM, Chris Conrey <con...@chrisconrey.com> wrote:
> 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
> On Tue, Jan 13, 2009 at 11:58 AM, 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?
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?
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.
On Tue, Jan 13, 2009 at 12:06 PM, Theodore Mills <twmi...@gmail.com> wrote:
> 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.
> On Tue, Jan 13, 2009 at 1:01 PM, Chris Conrey <con...@chrisconrey.com>
> wrote:
> > 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
> > On Tue, Jan 13, 2009 at 11:58 AM, 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?
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?
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...
> 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
> On Tue, Jan 13, 2009 at 12:06 PM, Theodore Mills <twmi...@gmail.com> wrote:
>> 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.
>> On Tue, Jan 13, 2009 at 1:01 PM, Chris Conrey <con...@chrisconrey.com>
>> wrote:
>> > 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
>> > On Tue, Jan 13, 2009 at 11:58 AM, 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?
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.
> 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?
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
On Tue, Jan 13, 2009 at 2:15 PM, 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?
On Tue, Jan 13, 2009 at 7:20 PM, Thomas Meeks <tho...@thomasmeeks.com> wrote:
> 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
> On Tue, Jan 13, 2009 at 2:15 PM, 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?
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...)
> 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
> On Tue, Jan 13, 2009 at 2:15 PM, 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?
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.
> 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.
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.
> 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.
> 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.
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...
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.
On Tue, Jan 13, 2009 at 11:57 AM, Matt Jones <al2o...@gmail.com> wrote:
> 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
> On Jan 13, 2009, at 2:38 PM, Dana Jones wrote:
> > 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?
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
> On Tue, Jan 13, 2009 at 11:57 AM, Matt Jones <al2o...@gmail.com> wrote:
> > 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
> > On Jan 13, 2009, at 2:38 PM, Dana Jones wrote:
> > > 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?
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.
On Tue, Jan 13, 2009 at 12:35 PM, robokos <zol...@gmail.com> wrote:
> 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
> > On Tue, Jan 13, 2009 at 11:57 AM, Matt Jones <al2o...@gmail.com> wrote:
> > > 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
> > > On Jan 13, 2009, at 2:38 PM, Dana Jones wrote:
> > > > 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?
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.
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.
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.
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.
> 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.
> 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.
|
