---
# System prepended metadata

title: CentOS docs platform replacement

---

# CentOS docs platform replacement

We use Material for Mkdocs. It is unmaintained. It doesn't meet all needs of all SIGs.
Shaun tested GitBook, which was ok, but not open source, and not self-hosted.
We are considering [Zensical](https://zensical.org/) and Docusaurus, but open to other solutions. Shaun is looking into the zensical which is the project supported now by the _Material for MKDocs_ and is meant to maintain the same methods. Another option is the [docusaurus](https://docusaurus.io/), but the consensus is that managing typescript and node environments is not manageable. There is also some concern around the package maintenance upstream as there is only one significant maintainer. Zensical has both of our most required features, so we are going to investigate how far out those are on the roadmap to determine if there is a way that we can identify how much effort we need to apply. If there is too much effort, then we may need to move in a different direction, but Shaun pointed out that they will include the ability to reference the aggregated documents without referencing the aggregate, but the original source and versioning per doc. 

We can setup the RHEL documentation pull and that is considered to be the 
bookwar: we need a version and we need a retirement model for the documentat. 
davide: we should point to upstream documentation
spotz: 
shaun: does this fit into quickdocs? 
davide: the quickdocs were folded into the documents. 
bookwar: most of the RHEL docs now are how-tos. 
farrotin: when there is a new release, the documentation can be missing.  
bookwar: that's why pulling fro the rhel docs is backwards. The docs for RHEL should be centos docs.
general group: what is the likelihood that will work.
bookwar: I have to deal with fedora docs better in order to better address the requirements. 
farrotin: we can use the zensical from the docker image to validate. 
davide: I am less concerned about the evaluation and more concerned about having it packaged in fedora
shaun: using zensical requires a backlog event and design documents. we might need to do something to make it more functional for the project. 
davide: determining if they can do the work is worth it. 
davdunc: I want to choose a tool instead of plan for what documentation we need. The tool is an easier choice and the documentation 
Tomaz: Do we know what users want? 
davdunc: how would we know? What is our data source. 
bookwar: I think we should look at some examples of user collected documentation and the [document created by the Russian Fedora Community](https://russianfedora.github.io/FAQ/) is a great example of what users are discussing and the problems they are resolving. 
spotz: do we need a guide for how to create a new SIG? 
farrotin: we need a guide for how to close an abandonded SIG.
spotz: we need to link to that from the SIGs landing page. 
bookwar: we need documentation on why you want a sig, why you don't want to start a sig. What do we do with the servers, what do we do with the artifacts that were created for the group. 





## Requirements

* markdown
* search bar (global? per doc?)
* multiple documents from multiple repositories (currently using git submodules)
* multiple versions per doc (currently no, only used by automotive)
* links to gitlab per doc (currently no)

## Non-requirements

* translations?
*