Continuing from #264 (comment).
In hope of expanding fmf beyond tmt context, I am proposing some restructuring of the documentation section to be more generic and easier to follow as a passer-by (what is this fmf thing about), basic-user (how do I write my first fmf tree), power-user (what's new in fmf, where's the reference guide), external developer (how do I work with fmf as a library), internal developer (python api, contribution guide).
One restructuring I am thinking of is having the following pages:
- "What is fmf": a simple explanation of fmf as yaml + file structure with inheritance.
- "Features": all the capabilities and definitions of fmf
- "Advanced designs": suggestions for how to structure the fmf tree, advanced in-tree control parameters like
/.inherit, advanced tree control parameters in .fmf/config, full list of operators (just because can't find a better place)
- "Developer corner": what to expect from
.fmf/version, how to expand fmf and more such topics
The concept page is too tmt specific and it's hard to parse outside of it. I think most of the content could be converted to a "what/why fmf".
Continuing from #264 (comment).
In hope of expanding fmf beyond tmt context, I am proposing some restructuring of the documentation section to be more generic and easier to follow as a passer-by (what is this fmf thing about), basic-user (how do I write my first fmf tree), power-user (what's new in fmf, where's the reference guide), external developer (how do I work with fmf as a library), internal developer (python api, contribution guide).
One restructuring I am thinking of is having the following pages:
/.inherit, advanced tree control parameters in.fmf/config, full list of operators (just because can't find a better place).fmf/version, how to expand fmf and more such topicsThe concept page is too
tmtspecific and it's hard to parse outside of it. I think most of the content could be converted to a "what/why fmf".