Hi All ! This is most likely a question to Ondrej. Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ? The disadvantage of BIRD in this moment is the lack of documentation/description. I/We could support BIRD by creating such things using the wiki. Big thanks in advance! -- Pozdrawiam! Maciej Drobniuch
Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ?
Great idea! :)
Maciej Drobniuch
-- . Przemyslaw Stanislaw Knycz, xmpp:djrzulf@kol.net.pl . | Wireless & IT specialist --- Mobile : +48 601391681 | | KIKE Founder & Member [GRAP] -- http://www.kike.pl/ | `- Futurama -- you can't prove it won't happen -'
Le 17/12/2010 08:48, Przemysław Knycz a écrit :
Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ?
Great idea! :)
+1 I could share my simple BGP config :) -- Laurent COUSTET http://ed.zehome.com/
It's great idea. The lack of examples is the biggest disadvantage of bird ;) I can share my config too. 2010/12/17 Laurent Coustet <ed@zehome.com>:
Le 17/12/2010 08:48, Przemysław Knycz a écrit :
Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ?
Great idea! :)
+1 I could share my simple BGP config :)
-- Laurent COUSTET http://ed.zehome.com/
Le 17/12/2010 08:48, Przemysław Knycz a écrit :
Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ?
What tool would you use ? Someting with "proprietary" syntax, like dokuwiki, mediawiki, or something with RestructuredText support ? or ? The advantage to use restructured text is that you can export wiki pages to pdf or many other formats. On the other way, I think http://wiki.postgresql.org/ is really a good wiki example. The wiki will be ok if there is a STRONG organisation to it I think. My 2 cents, -- Laurent Coustet http://ed.zehome.com/
Sorry, I am a bit of a lurker on this list but I must chime in. In the last 15 years I have watched many projects grow and let me say that community documentation is a good step. It is hard and can appear to fail while it is working well. I am setting up a wiki-farm for some internal projects and would suggest you look around for a large wiki-farm at a university that will exist long term. All major Wiki's and software does have an export path to PDF style documents. ~~~ Andrew "lathama" Latham lathama@gmail.com ~~~
On Fri, Dec 17, 2010 at 09:06:16AM -0300, Andrew Latham wrote:
Sorry, I am a bit of a lurker on this list but I must chime in. In the last 15 years I have watched many projects grow and let me say that community documentation is a good step. It is hard and can appear to fail while it is working well. I am setting up a wiki-farm for some internal projects and would suggest you look around for a large wiki-farm at a university that will exist long term. All major Wiki's and software does have an export path to PDF style documents.
If you want your documentation to exist long term, you shouldn't lock it up in some random wiki storing its pages in some random database format. ikiwiki stores your pages as regular files and uses git as the version control system instead of inventing some random VCS. ikiwiki also makes it easy for people to contribute to your wiki without ever opening some random browser. Some Random Nick -- Wanna turn ICANN into ICANNt? Join a darknet today: http://www.anonet2.org/darknet_comparison
Le 19/12/2010 08:44, Nick a écrit :
On Fri, Dec 17, 2010 at 09:06:16AM -0300, Andrew Latham wrote:
Sorry, I am a bit of a lurker on this list but I must chime in. In the last 15 years I have watched many projects grow and let me say that community documentation is a good step. It is hard and can appear to fail while it is working well. I am setting up a wiki-farm for some internal projects and would suggest you look around for a large wiki-farm at a university that will exist long term. All major Wiki's and software does have an export path to PDF style documents.
If you want your documentation to exist long term, you shouldn't lock it up in some random wiki storing its pages in some random database format. ikiwiki stores your pages as regular files and uses git as the version control system instead of inventing some random VCS. ikiwiki also makes it easy for people to contribute to your wiki without ever opening some random browser.
Some Random Nick
I agree about storing wiki data in flat files instead of databases. In this category, IMHO, DokuWiki[1] is a serious player. And sure, community documentation is a good step for Bird. Stéphane. [1]http://www.dokuwiki.org/dokuwiki
On Mon, Dec 20, 2010 at 02:36:11PM +0100, Stéphane Bunel wrote:
Le 19/12/2010 08:44, Nick a écrit :
On Fri, Dec 17, 2010 at 09:06:16AM -0300, Andrew Latham wrote:
Sorry, I am a bit of a lurker on this list but I must chime in. In the last 15 years I have watched many projects grow and let me say that community documentation is a good step. It is hard and can appear to fail while it is working well. I am setting up a wiki-farm for some internal projects and would suggest you look around for a large wiki-farm at a university that will exist long term. All major Wiki's and software does have an export path to PDF style documents.
If you want your documentation to exist long term, you shouldn't lock it up in some random wiki storing its pages in some random database format. ikiwiki stores your pages as regular files and uses git as the version control system instead of inventing some random VCS. ikiwiki also makes it easy for people to contribute to your wiki without ever opening some random browser.
Some Random Nick
I agree about storing wiki data in flat files instead of databases. In this category, IMHO, DokuWiki[1] is a serious player. And sure, community documentation is a good step for Bird.
Stéphane.
I can't access the dokuwiki manual for 2 days now, so I'm writing the response without all knowledge. It seems that dokuwiki invents some random VCS instead of using a real one. That makes plugins like conflictmerger useful, and necessary for any serious deployment. In: http://www.dokuwiki.org/plugin:conflictmerger the conflictmerger author says about his plugin: This plugin is the second or third time that I develop something in PHP, and although it passes all the acceptance tests I could think of, I didn't test it in a real wiki. So you may want to review its code first before using it ;) Also note that I have no further development plans, at least in the short term. Also most real wiki use is read-only, and ikiwiki lets the webserver serve static HTML pages instead of forcing it to execute a script at each pageload. Some Random Nick -- Wanna turn ICANN into ICANNt? Join a darknet today: http://www.anonet2.org/darknet_comparison
On Thu, Dec 16, 2010 at 10:54:14PM +0100, Maciej Drobniuch wrote:
Hi All ! This is most likely a question to Ondrej. Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ? The disadvantage of BIRD in this moment is the lack of documentation/description.
I agree that wiki for BIRD would be great. Although BIRD have IMHO pretty good reference documentation, it lacks things like examples, FAQs and Howtos. For these kind of texts, wiki style doc would be probably much better than current SGML/LinuxDoc based, release-cycle tied documentation. Although i do not have any administrative rights for bird.network.cz, i could try to convince appropriate people. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
On 17.12.2010 11:52, Ondrej Zajicek wrote:
On Thu, Dec 16, 2010 at 10:54:14PM +0100, Maciej Drobniuch wrote:
Hi All ! This is most likely a question to Ondrej. Could You create a wiki subdomain/directory so we could act like a community and create simple descriptions/manuals/howto ? The disadvantage of BIRD in this moment is the lack of documentation/description.
I agree that wiki for BIRD would be great. Although BIRD have IMHO pretty good reference documentation, it lacks things like examples, FAQs and Howtos. For these kind of texts, wiki style doc would be probably much better than current SGML/LinuxDoc based, release-cycle tied documentation. Although i do not have any administrative rights for bird.network.cz, i could try to convince appropriate people.
I will look at it. Ondrej
Am 20.12.10 13:00, schrieb Ondrej Filip:
I will look at it.
Much appreciated! I vote for a plain file format too and to make it "plain" available. For me DokuWiki is familiar, but you need to manage user access and some "stripping", if you want to export the plain files. Ikiwiki sounds great, regarding the usage of svn or git (pull requests) which might help to keep a certain control, but beeing able to keep "user local" documentation too. IMHO ikiwiki looks a little bit dusty, but ymmv. If there is anything anyone can support the rollout of a wiki for bird, feel free to ask. Rgds, Stefan
participants (10)
-
Andrew Latham -
Laurent Coustet -
Maciej Drobniuch -
Marek Wajdzik -
Nick -
Ondrej Filip -
Ondrej Zajicek -
Przemysław Knycz -
Stefan Jakob -
Stéphane Bunel