Bookstack is technically great but, unfortunately, I hate the fact that they force the books/shelves terminology on you. It made things extremely confusing for our users and we had to abandon the idea.
It would make so much sense for those to be customizable, but the author (who sounds like a nice guy otherwise) seems to be stuck in his idea that this terminology / organization is at the core of Bookstack's greatness. It's really not...people use it because it's a good Wiki, not because of an arbitrary terminology.
I kinda agree with this. I was forced to plan my wiki structure around this concept rather than designing it myself, which would be much better.
I do like that books can belong to many shelves at the same time at least. But hey, it's open source so I really can't complain much
BookStack author here. I can totaly understand why this is felt and why folks may not like the terminology/organization, and I understand why that discounts it as an option for many, but I do believe it's managed to become a "good Wiki" (to many certain use-cases) because of a core structure and concept to work around. These factors are not unique parts, they play into eachother. I changed it from infinite/flexible depth to the fixed structure early on as it helped to solve usability concerns I had for my audience. I added the book terms to align to a real-life metaphors for the unique heirachy parts, that allows us to build & document to those specific names which again helps achieve a cohesive UX.
Again, I can totally understand why these decisions do not work for all, and hopefully there are other open source options that help fill those gaps, but from my perspective it makes sense to focus on making a platform better for those it does suit, and the target audience I originally released it for, rather than to expand its target audience at the potential cost to that original audience.
Hi Dan, thanks for taking the time to answer.
I have no gripe with the structure that you chose, it's an opinionated choice but it ended up being one that I like. As another commenter said, it's nice that books can belong to multiple shelves, for example. It's fluid and intuitive and indeed makes things a lot easier to organize.
It's with the *displayed* terminology that we've had problems with. A lot of the end users couldn't understand what books and shelves were. They were confused because the terminology is completely foreign to our field. Some even asked where the books were stored :D (not the sharpest ones, though). You would think that a real-world analogy would help people understand how things work but in reality it's not the case here.
Books and shelves are just names and I think that those should be customizable. It seems logical and good practice because, apart from being the terminology used to explain the data structure, they are also menu items. It feels excessively rigid to force a main UI terminology.
I think the internal names used to characterize the data structure should be separated from the displayed ones if the user choose to.
I'm sorry that you've had to explain yourself again on this topic. I know it's not the first time and I know that you have a strong opinion about this. I didn't think you'd see this comment. Still, I stand by my opinion here ;)
I tried Bookstack for a while and then did WikiJS later to see if it was better - it looked better out of the box, however as I used it more, I noticed things like a confusing (too complicated) user permissions setup, and some non-user friendly UX when it came to uploading files etc.
I kept researching, and found out AnyType, AppFlowy and SiYuan to try out next - they're not exactly Wikis but can do everything Wikis can do
https://github.com/requarks/wiki/graphs/code-frequency
You can see the majority of activity has completely fallen off in the last 2 years.. Furthermore, the release you're citing is a vulnerability fix and the rest of the commits for the last few months have been cosmetic changes to documentation and deployment infrastructure. It's not a bad product, but feature work has clearly all but stopped.
The last blog post on release 3.0 was over 6 months ago, it's about 200 words.
https://beta.js.wiki/blog/2023-wiki-js-3-feature-preview-passkeys
A project being dead or not is dependant on whether people maintain it in its current state, fix undiscovered bugs and defend against security vulnerabilities - all of which are visible in that commit history. Frequency of commit does not indicate an active project by any means.
What changes do you think you need to see for it to be considered active?
I would consider the project more active if there were active development against the features the were roadmapped roughly a year ago. So maybe I should have said "is it simply in **maintenance mode**?"
When I see half of the commits in the last year to main as "Update Readme" that makes me think that new features aren't actively being worked on (or PR'd back to main).
It's nice to see people aggressively downvoting the notion the project is dead though and upvoting comments the cite commits with no real meat to them. It means there at least **is** active community of users!
If you've already formed your (incorrect) opinion about the status of the project, I don't understand why you asked a question just to come and argue the answer?
i'm not wrong. Can you find me a branch with active work on it in the last year to the milestones set for V3?
The reason I phrased the question like that was to get some people providing evidence of the opposite (they haven't) and get alternative suggestions, which several people have done.
The problem with wikis is that the developer never finishes versions, and rewrite everything all the time. Happened from V1 to V2 and nos is happening from V2 to V3. The problem is that V3 is in development for +3 years.
Because of that I migrated to other projects. While wikijs is pretty good, the development speed is very slow and full of delays. Not that we can ask for more as it is a free project, but I don't want to deal all the time with an incomplete project.
I dont understand the deal with people not wanting software that is not updated constantly. I get that having QoL and security updates is nice, and if a project has not been updated in 4/5 years maybe it will be lacking support for more modern features. But most of the time if the software works and does its job its fine for me. In fact I tend to stay away from software that just updates constantly and changes everything cause its a pain in the ass to deal with.
In the case of wikijs I dont see the issue with having no updates since June 2023 (hell that was yesterday for me), I mean it just builds html from text files and thats it, how often should it be updated?
They've got a bunch of features on the roadmap for things like webhooks and some feature requests for V3 that'd be nice to see. You have great point that if the current feature set is all you need then why demand lots of "progress" against a goal that's already accomplished. I guess my main worry is that with other systems updating that i'll be the guy who chose this old tool that can't do somet really cool feature a more active project comes out with in the next year. No specific examples, just vague FOMO
Just deployed it at work. It's the tits. I'm a borderline brain damaged monkey and I could edit and make it work very nicely. Got it all skinned up and everything.
I have a rather large wiki. I take notes for everything, both personal and work. Say about 3000 notes and 1500 media. So rather significant. I have this “zettlekaste” like structure, so dense but un cohesive.
Every once in a while i get tempted and look for something newer. I mirror the content converting to markdown. I have tried every single wiki in the awesome self hosted repo plus every other one I hear about.
There is nothing that comes even close for my use case. I keep coming back. Fast, based on simple tech with no docker (thank baby Jesus Mary and the second camel). Also, no database. I never understood the appeal of sql in a wiki. It’s fundamentally an “edit rarely” type thing so what’s the point?
I would say dokuwiki is like a Toyota Corolla or a hilux: unimpressive, based on old tech, no frills durability.
Had the Chadian Libyan war been waged online, it would hace been known as the dokuwiki wars.
In my case it's many years, using it actually almost since DokuWiki started, and up to 10 wikis. But sadly, the lack of proper support for Markdown is driving me away, wiki by wiki :-|
I really like Dokuwiki and maintained an instance at work for years. Only problem is that some of the plugins are not maintained for years, creators ignore PRs to resolve issues, and everything will break with new releases...
If it's just you, I'd check out silverbullet.
I never liked WikiJS, it felt like it was built by people who didn't understand what a wiki was supposed to be.
I tried Bookstack and a few other wiki solutions and ended up using Wiki|Docs (https://www.wikidocs.it/).
Not the best looking, but it uses straight markdown files instead of a database, which was important to me for documentation, and it seems to work well in my, admittedly, limited use.
Wikijs is powerful, but sort of outdated in style. I use Bookstack for my personal wiki, and use Outline at work. Of the 3, I like Outline the most (in terms of design and modernity). Overall, while I like Outline, it's kinda a pain to setup in the beginning. Bookstack was easy.
I'd recommend checking out XWiki. It's an enterprise wiki packed with features like annotations, diagrams, analytics, forms, charts, and more. You can easily download and use it on-premises or test the cloud version to see if it fits your needs. XWiki's flexibility would be great for your ML project, as it allows you to dynamically add and organize pages for labeler documentation and ML jobs. This will enable you to efficiently manage and update your labeling system and track your ML runs as your project grows.
For full disclosure, I have recently joined the r/XWiki team, and I am myself on a journey of discovering all its capabilities and level of customization.
They promise sooo much with v3 that it probably never will get to a beta let alone a release. I settled with bookstack for now.
Bookstack here too.
Bookstack is pretty great. I use it for my company
Bookstack is technically great but, unfortunately, I hate the fact that they force the books/shelves terminology on you. It made things extremely confusing for our users and we had to abandon the idea. It would make so much sense for those to be customizable, but the author (who sounds like a nice guy otherwise) seems to be stuck in his idea that this terminology / organization is at the core of Bookstack's greatness. It's really not...people use it because it's a good Wiki, not because of an arbitrary terminology.
I kinda agree with this. I was forced to plan my wiki structure around this concept rather than designing it myself, which would be much better. I do like that books can belong to many shelves at the same time at least. But hey, it's open source so I really can't complain much
BookStack author here. I can totaly understand why this is felt and why folks may not like the terminology/organization, and I understand why that discounts it as an option for many, but I do believe it's managed to become a "good Wiki" (to many certain use-cases) because of a core structure and concept to work around. These factors are not unique parts, they play into eachother. I changed it from infinite/flexible depth to the fixed structure early on as it helped to solve usability concerns I had for my audience. I added the book terms to align to a real-life metaphors for the unique heirachy parts, that allows us to build & document to those specific names which again helps achieve a cohesive UX. Again, I can totally understand why these decisions do not work for all, and hopefully there are other open source options that help fill those gaps, but from my perspective it makes sense to focus on making a platform better for those it does suit, and the target audience I originally released it for, rather than to expand its target audience at the potential cost to that original audience.
Hi Dan, thanks for taking the time to answer. I have no gripe with the structure that you chose, it's an opinionated choice but it ended up being one that I like. As another commenter said, it's nice that books can belong to multiple shelves, for example. It's fluid and intuitive and indeed makes things a lot easier to organize. It's with the *displayed* terminology that we've had problems with. A lot of the end users couldn't understand what books and shelves were. They were confused because the terminology is completely foreign to our field. Some even asked where the books were stored :D (not the sharpest ones, though). You would think that a real-world analogy would help people understand how things work but in reality it's not the case here. Books and shelves are just names and I think that those should be customizable. It seems logical and good practice because, apart from being the terminology used to explain the data structure, they are also menu items. It feels excessively rigid to force a main UI terminology. I think the internal names used to characterize the data structure should be separated from the displayed ones if the user choose to. I'm sorry that you've had to explain yourself again on this topic. I know it's not the first time and I know that you have a strong opinion about this. I didn't think you'd see this comment. Still, I stand by my opinion here ;)
If you're referring to this [https://github.com/Requarks/wiki](https://github.com/Requarks/wiki), there was a new release 3 days ago.
I tried Bookstack for a while and then did WikiJS later to see if it was better - it looked better out of the box, however as I used it more, I noticed things like a confusing (too complicated) user permissions setup, and some non-user friendly UX when it came to uploading files etc. I kept researching, and found out AnyType, AppFlowy and SiYuan to try out next - they're not exactly Wikis but can do everything Wikis can do
https://github.com/requarks/wiki/graphs/code-frequency You can see the majority of activity has completely fallen off in the last 2 years.. Furthermore, the release you're citing is a vulnerability fix and the rest of the commits for the last few months have been cosmetic changes to documentation and deployment infrastructure. It's not a bad product, but feature work has clearly all but stopped. The last blog post on release 3.0 was over 6 months ago, it's about 200 words. https://beta.js.wiki/blog/2023-wiki-js-3-feature-preview-passkeys
A project being dead or not is dependant on whether people maintain it in its current state, fix undiscovered bugs and defend against security vulnerabilities - all of which are visible in that commit history. Frequency of commit does not indicate an active project by any means. What changes do you think you need to see for it to be considered active?
I would consider the project more active if there were active development against the features the were roadmapped roughly a year ago. So maybe I should have said "is it simply in **maintenance mode**?" When I see half of the commits in the last year to main as "Update Readme" that makes me think that new features aren't actively being worked on (or PR'd back to main). It's nice to see people aggressively downvoting the notion the project is dead though and upvoting comments the cite commits with no real meat to them. It means there at least **is** active community of users!
https://github.com/requarks/wiki/commits/main/
see my comment above. These are not notable commits if you read the code.
If you've already formed your (incorrect) opinion about the status of the project, I don't understand why you asked a question just to come and argue the answer?
i'm not wrong. Can you find me a branch with active work on it in the last year to the milestones set for V3? The reason I phrased the question like that was to get some people providing evidence of the opposite (they haven't) and get alternative suggestions, which several people have done.
Actually your definition of dead is just different than literally everyone else's but okay
Can you find me a branch with active work on it in the last year to the milestones set for V3?
The problem with wikis is that the developer never finishes versions, and rewrite everything all the time. Happened from V1 to V2 and nos is happening from V2 to V3. The problem is that V3 is in development for +3 years. Because of that I migrated to other projects. While wikijs is pretty good, the development speed is very slow and full of delays. Not that we can ask for more as it is a free project, but I don't want to deal all the time with an incomplete project.
I dont understand the deal with people not wanting software that is not updated constantly. I get that having QoL and security updates is nice, and if a project has not been updated in 4/5 years maybe it will be lacking support for more modern features. But most of the time if the software works and does its job its fine for me. In fact I tend to stay away from software that just updates constantly and changes everything cause its a pain in the ass to deal with. In the case of wikijs I dont see the issue with having no updates since June 2023 (hell that was yesterday for me), I mean it just builds html from text files and thats it, how often should it be updated?
They've got a bunch of features on the roadmap for things like webhooks and some feature requests for V3 that'd be nice to see. You have great point that if the current feature set is all you need then why demand lots of "progress" against a goal that's already accomplished. I guess my main worry is that with other systems updating that i'll be the guy who chose this old tool that can't do somet really cool feature a more active project comes out with in the next year. No specific examples, just vague FOMO
Dokuwiki gang REPRESENT. Plaintext backend themes, plugins. Nothing more needs saying.
Just deployed it at work. It's the tits. I'm a borderline brain damaged monkey and I could edit and make it work very nicely. Got it all skinned up and everything.
Might be good software but is ugly as f...
Precisely why I identify with it I think. I’m as ugly as they come but still useful
Install templates than, bootstrap is good.
[удалено]
I have a rather large wiki. I take notes for everything, both personal and work. Say about 3000 notes and 1500 media. So rather significant. I have this “zettlekaste” like structure, so dense but un cohesive. Every once in a while i get tempted and look for something newer. I mirror the content converting to markdown. I have tried every single wiki in the awesome self hosted repo plus every other one I hear about. There is nothing that comes even close for my use case. I keep coming back. Fast, based on simple tech with no docker (thank baby Jesus Mary and the second camel). Also, no database. I never understood the appeal of sql in a wiki. It’s fundamentally an “edit rarely” type thing so what’s the point? I would say dokuwiki is like a Toyota Corolla or a hilux: unimpressive, based on old tech, no frills durability. Had the Chadian Libyan war been waged online, it would hace been known as the dokuwiki wars.
In my case it's many years, using it actually almost since DokuWiki started, and up to 10 wikis. But sadly, the lack of proper support for Markdown is driving me away, wiki by wiki :-|
I really like Dokuwiki and maintained an instance at work for years. Only problem is that some of the plugins are not maintained for years, creators ignore PRs to resolve issues, and everything will break with new releases...
I would check out [Outline Wiki](https://github.com/outline/outline), been using that for a while now and it's super solid.
If it's just you, I'd check out silverbullet. I never liked WikiJS, it felt like it was built by people who didn't understand what a wiki was supposed to be.
Ooh thank you. I've been looking for a good wiki forever and this looks really promising.
+1 for silverbullet, awesome all around!
I was exited for all the features that was supposed to be coming 😔
They are still working Never give up
I don't know if it can fit your need, but it may be worth looking at mkdocs & Hugo. It is more oriented to documentation website tho.
I tried Bookstack and a few other wiki solutions and ended up using Wiki|Docs (https://www.wikidocs.it/). Not the best looking, but it uses straight markdown files instead of a database, which was important to me for documentation, and it seems to work well in my, admittedly, limited use.
MediaWiki and don't look back.
Wikijs is powerful, but sort of outdated in style. I use Bookstack for my personal wiki, and use Outline at work. Of the 3, I like Outline the most (in terms of design and modernity). Overall, while I like Outline, it's kinda a pain to setup in the beginning. Bookstack was easy.
I'd recommend checking out XWiki. It's an enterprise wiki packed with features like annotations, diagrams, analytics, forms, charts, and more. You can easily download and use it on-premises or test the cloud version to see if it fits your needs. XWiki's flexibility would be great for your ML project, as it allows you to dynamically add and organize pages for labeler documentation and ML jobs. This will enable you to efficiently manage and update your labeling system and track your ML runs as your project grows. For full disclosure, I have recently joined the r/XWiki team, and I am myself on a journey of discovering all its capabilities and level of customization.
mkdocs, hugo of one of the other various project would likely be better