| 8 Mar 2024 |
 danielsidhion | My approach to looking into other frameworks is based on a simpler thought: we currently have 5k lines of custom code to render the manuals into what we see online. As far as I know, there is currently not a lot of flexibility in the tool to produce things in different ways, which means that if we want to change something, we'll need to go change the code. This is a big overhead that makes it hard to add improvements to the manuals. So I decided to look into other frameworks to see how much of our needs they can satisfy out of the box, and how much extra effort would be needed to satisfy the other needs. Because honestly, I actually find borderline absurd to assume that nobody out there has been able to solve some of the same problems we have into a tool that's more popular, has people to maintain it, and has a bigger ecosystem of documentation/plugins/knowledge to source from | 10:11:24 |
 pennae | most people out there are not multiple distros in a trench coat | 10:12:29 |
| danielsidhion | But our documentation doesn't have to follow suit | 10:13:54 |
| pennae | we can only stress again: make sure you're familiar with the problem domain before trying to Be Like The Others. | 10:14:32 |
| pennae | apart from that, we're not picky about nrd being replaced if there's something better. it's on you to find that thing though, and if you do, awesome! just consider the amount of effort it all takes to migrate again, the regression it will come with, and whether perhaps the tooling we have isn't fine enough if you just take a day to understand how it works | 10:15:45 |
