I hope Wiki.js does not fail
-
@scottalanmiller said in I hope Wiki.js does not fail:
@Curtis said in I hope Wiki.js does not fail:
@scottalanmiller I thought everyone moved to bookstack?
A lot have, and BookStack is very nice. But my team was torn and decided, at least for now, to stay on wiki.js.
The only reason I chose Bookstack over Wiki.js is the WYSIWYG editor.
-
@wrx7m said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m said in I hope Wiki.js does not fail:
What is the prognosis for Wiki.js? Is it still only one dev?
Definitely very few, if not just one. But only so much development needed, I suppose. It's moving forward very slowly, but work on the 2 branch is moving forward.
Do you know anyone who is using it?
Well, WE do
-
@JaredBusch said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Curtis said in I hope Wiki.js does not fail:
@scottalanmiller I thought everyone moved to bookstack?
A lot have, and BookStack is very nice. But my team was torn and decided, at least for now, to stay on wiki.js.
The only reason I chose Bookstack over Wiki.js is the WYSIWYG editor.
That's awfully nice. I like that a lot in BookStack (we use BS a lot, too.) The table thing is really a big deal in wiki.js (it sucks.)
Also big is the ability to organize by books in BS.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@JaredBusch said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Curtis said in I hope Wiki.js does not fail:
@scottalanmiller I thought everyone moved to bookstack?
A lot have, and BookStack is very nice. But my team was torn and decided, at least for now, to stay on wiki.js.
The only reason I chose Bookstack over Wiki.js is the WYSIWYG editor.
That's awfully nice. I like that a lot in BookStack (we use BS a lot, too.) The table thing is really a big deal in wiki.js (it sucks.)
Also big is the ability to organize by books in BS.
@JaredBusch said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Curtis said in I hope Wiki.js does not fail:
@scottalanmiller I thought everyone moved to bookstack?
A lot have, and BookStack is very nice. But my team was torn and decided, at least for now, to stay on wiki.js.
The only reason I chose Bookstack over Wiki.js is the WYSIWYG editor.
If I ever get time, I will look at Bookstack again. I would love to have something better than some flat files (excel, word, pdf, visio) for documentation and the like.
-
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/ -
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
-
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/I use Asciidoctor. We did have a Hugo site but Asciidoctor has actual standards unlike markdown.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
-
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
-
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
Not "too hard". But given that the theory behind a wiki is the insane ease of editing, it kind of defeats that. The background concept states that links are supposed to automatically make new pages. Editing should be in place. Trying to get normal end users to start going to GitHub feels cumbersome even just to explain.
Easy enough for techs to do, but seems better suited to something edited occasionally rather than constantly.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
Not "too hard". But given that the theory behind a wiki is the insane ease of editing, it kind of defeats that. The background concept states that links are supposed to automatically make new pages. Editing should be in place. Trying to get normal end users to start going to GitHub feels cumbersome even just to explain.
Easy enough for techs to do, but seems better suited to something edited occasionally rather than constantly.
That's why I said if you're using it it's prob mostly technical people. We use Asciidoctor in a pipeline and it works really well. As soon as a commit is made Jenkins runs the pipeline to build the new site with Gradle. It builds an HTML version and a PDF version. So it's really easy for people that understand that workflow and then it's automatically versioned.
-
Coincidentally this is also how my site is built. It's a static site built with Hugo on GitLab pages. Once a commit is made the CI/CD process starts on my GitLab runner and builds my site for me.
-
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
Not "too hard". But given that the theory behind a wiki is the insane ease of editing, it kind of defeats that. The background concept states that links are supposed to automatically make new pages. Editing should be in place. Trying to get normal end users to start going to GitHub feels cumbersome even just to explain.
Easy enough for techs to do, but seems better suited to something edited occasionally rather than constantly.
That's why I said if you're using it it's prob mostly technical people. We use Asciidoctor in a pipeline and it works really well. As soon as a commit is made Jenkins runs the pipeline to build the new site with Gradle. It builds an HTML version and a PDF version. So it's really easy for people that understand that workflow and then it's automatically versioned.
Oh, if using a static generator. I get it. I thought you meant using a wiki. Makes sense.
-
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
Not "too hard". But given that the theory behind a wiki is the insane ease of editing, it kind of defeats that. The background concept states that links are supposed to automatically make new pages. Editing should be in place. Trying to get normal end users to start going to GitHub feels cumbersome even just to explain.
Easy enough for techs to do, but seems better suited to something edited occasionally rather than constantly.
That's why I said if you're using it it's prob mostly technical people. We use Asciidoctor in a pipeline and it works really well. As soon as a commit is made Jenkins runs the pipeline to build the new site with Gradle. It builds an HTML version and a PDF version. So it's really easy for people that understand that workflow and then it's automatically versioned.
Oh, if using a static generator. I get it. I thought you meant using a wiki. Makes sense.
Yeah it's a static documentation site. I guess you could say it's somewhat like a wiki, but it's not really. I don't like having to open a web interface, log in, click edit, blah blah when I can just edit it in a few seconds in vim and hit ctrl+g to commit.
-
@stacksofplates I love that flow of things. Where can I learn more about this and how it works?
-
@jmoore said in I hope Wiki.js does not fail:
@stacksofplates I love that flow of things. Where can I learn more about this and how it works?
I'll do a write up if I get a chance tonight. It's pretty simple to set up.
-
@stacksofplates Cool, thanks very much
-
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@stacksofplates said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@Emad-R said in I hope Wiki.js does not fail:
@scottalanmiller said in I hope Wiki.js does not fail:
@wrx7m both wiki.js and BookStack are nice. And in reality, DokuWiki isn't bad either. We use all three, in different situations.
I love MkDocs
https://docs.drush.org/en/master/cron/
https://www.mkdocs.org/A static generator? How do you handle constant updates from lots of users?
Pipelines in a CI/CD process. Treat it as code just like anything else
True, but I wonder how easy that is for non-tech staff to use.
I'm sure if you're using it you wouldn't have many non-technical people updating it. But theoretically it shouldn't be too hard through the GitLab web ui.
Not "too hard". But given that the theory behind a wiki is the insane ease of editing, it kind of defeats that. The background concept states that links are supposed to automatically make new pages. Editing should be in place. Trying to get normal end users to start going to GitHub feels cumbersome even just to explain.
Easy enough for techs to do, but seems better suited to something edited occasionally rather than constantly.
That's why I said if you're using it it's prob mostly technical people. We use Asciidoctor in a pipeline and it works really well. As soon as a commit is made Jenkins runs the pipeline to build the new site with Gradle. It builds an HTML version and a PDF version. So it's really easy for people that understand that workflow and then it's automatically versioned.
Oh, if using a static generator. I get it. I thought you meant using a wiki. Makes sense.
Yeah it's a static documentation site. I guess you could say it's somewhat like a wiki, but it's not really. I don't like having to open a web interface, log in, click edit, blah blah when I can just edit it in a few seconds in vim and hit ctrl+g to commit.
That makes more sense.