At work we have most of our technical documentation in Confluence which is a tool made by Atlassian that is similar to Wikipedia. As a software developer, I've always gravitated towards having docs in your repository as markdown files. I find this approach to be easier to manage but it hasn't always been obvious to me why.
At first glance, having docs committed as part of your source code just seems like it would raise the barrier to entry to writing docs. You have to use git. You have to write your docs in a markup language. You need to get your docs code reviewed. You need to deploy your docs. Whereas using a tool like Confluence just seems simpler since you can just edit in a WYSIWYG editor and hit save.
There are some more subtle issues to using a wiki to store docs however. For example, the docs can be editable by anyone. This seems like an advantage at first, but it causes issues when the doc you write is part of the customer experience you are trying to curate, such as a Getting Started guide. When your docs live in a wiki thats editable by lots of developers, your docs will slowly change to represent the path of least resistance instead of the happy path that you've designed for customers. If readers of your docs are straying from your happy path, as a product owner you want to know why, address the issue for them, and potentially even update the docs. Granted, in some wiki tools, it is possible to configure access control for certain doc pages, but often it defaults to being editable by everyone.
When you have your docs in source control, anyone can edit docs, but they have to go through code review. You can have a discussion about whether this change should be part of the happy path, or whether it is actually just a bug that needs to be fixed. You can also enforce writing style which is an under-appreciated aspect of doc writing that can help the doc feel professional and trust-worthy. Anyone can propose changes, but not everyone can edit docs.
I also think there is a mental shift to writing docs in the code repository rather than in a wiki. Having docs in code makes you think of docs as part of the product you are building if you combine your feature changes with doc changes. Docs can be made part of the development process and enforced during code reviews. Whereas updating wiki docs often just becomes an afterthought after the product development cycle is over and you don't feel the same sense of progress as committing to a repository.
There are many more things to dissect here on wiki vs. code but these were just some preliminary thoughts.
At first glance, having docs committed as part of your source code just seems like it would raise the barrier to entry to writing docs. You have to use git. You have to write your docs in a markup language. You need to get your docs code reviewed. You need to deploy your docs. Whereas using a tool like Confluence just seems simpler since you can just edit in a WYSIWYG editor and hit save.
There are some more subtle issues to using a wiki to store docs however. For example, the docs can be editable by anyone. This seems like an advantage at first, but it causes issues when the doc you write is part of the customer experience you are trying to curate, such as a Getting Started guide. When your docs live in a wiki thats editable by lots of developers, your docs will slowly change to represent the path of least resistance instead of the happy path that you've designed for customers. If readers of your docs are straying from your happy path, as a product owner you want to know why, address the issue for them, and potentially even update the docs. Granted, in some wiki tools, it is possible to configure access control for certain doc pages, but often it defaults to being editable by everyone.
When you have your docs in source control, anyone can edit docs, but they have to go through code review. You can have a discussion about whether this change should be part of the happy path, or whether it is actually just a bug that needs to be fixed. You can also enforce writing style which is an under-appreciated aspect of doc writing that can help the doc feel professional and trust-worthy. Anyone can propose changes, but not everyone can edit docs.
I also think there is a mental shift to writing docs in the code repository rather than in a wiki. Having docs in code makes you think of docs as part of the product you are building if you combine your feature changes with doc changes. Docs can be made part of the development process and enforced during code reviews. Whereas updating wiki docs often just becomes an afterthought after the product development cycle is over and you don't feel the same sense of progress as committing to a repository.
There are many more things to dissect here on wiki vs. code but these were just some preliminary thoughts.