-
Notifications
You must be signed in to change notification settings - Fork 4
Description
a review as promised in gpds repo issue
this is very subjective since this is my view of what i expect from a projects documentation, and ofcourse there are different sizes, but if we never fix the questions, we will never get the right answers. if the answer is Unknown, then document that.
so the initial frontpage 'overview' information I'm looking for from a library documentation (on a website or pdf generated) is:
- what license does this library use?
- where in the lifecycle is this project currently?
- initial development v0.x
- stable major or minor
- single major/minor version or multiple ones maintained at once?
- what is the roadmap forward? [possible link to other page since the information might be substancial]
- features
- current
- planned
- wishlist
- planned next major or minor
- features
- when is end-of-life projected?
- thinking of the Qt5-LTS rules that changed during 5.12 to 5.15 from Qt Company when Qt6 was not yet production ready replacement of Qt5.
- thinking of the Qt5 -> Qt6 where KDE took over the maintence of 5.15, cause Qt Company dropped the ball on the last version of Qt5 just to get everyone on Qt6.
- what dependencies are required or optional?
- does the dependencies support a wide range of versions?
- prefeerably a link to the documentation of dependencies should be supplied, but not required.
ofcourse after that we got the deeper information, this part is to be viewed from two perspectives
- a how do i use this library? a few full examples that should be runable to show the basic functions/features, should be supplied as code in the repo, then a quick runthrough of the examples in the documentation.
- a pure reference of the supplied public interfaces of the library.
from this list there is alot of missing information on the testpage,
but as with everything, nothing starts out as done unless its a extremely small task.
a project that starts out as a small simple thing, might escalate and become very large.
from my knowledge the amount of projects that actually meet my critera of how a good documentation looks is about '0', not even my own internal projects meet that critera due to the massive effort it takes to update and the docs fast get out of sync with reality.
but it can alteast be a roadmap of what kind of information is wanted.
- next up is playing around with cpp-properties and see how the current state of the docs reflect the repository.
for a starter we got the same issue as with gpds with the external tinyxml2 and pkgconf, so i just disabled the tinyxml2 dependency on cpp-properties, since gpds should in my mind supply the missing xml support on my system since we fixed that.
next post will be made in a few hours when i have had time to do the legwork..