-
Notifications
You must be signed in to change notification settings - Fork 606
Improve API reference documentation #944
Copy link
Copy link
Open
Labels
documentation::referencerelated to the API and internals (information-oriented)related to the API and internals (information-oriented)epica highlevel collection of smaller related issuesa highlevel collection of smaller related issuessource::contributorcreated by a frequent contributorcreated by a frequent contributortype::documentationrequest for improved documentationrequest for improved documentation
Metadata
Metadata
Assignees
Labels
documentation::referencerelated to the API and internals (information-oriented)related to the API and internals (information-oriented)epica highlevel collection of smaller related issuesa highlevel collection of smaller related issuessource::contributorcreated by a frequent contributorcreated by a frequent contributortype::documentationrequest for improved documentationrequest for improved documentation
Why?
The current API reference documentation (entry point) offers some opportunity for improvements.
A few relatively simple steps can set us up to improve both developer and user experience.
User impact
Developers will find it easier to improve the documentation because fewer guesses on styles and associated resources will be necessary.
Users and developers will profit from an improved and improving documentation.
Goals
This epic will focus important decisions regarding documentation styles. While there likely different valid choices for any of those, making a decision and advertising it appropriately will increase homogeneity in the code base.
As such, the goals of this epic are twofold: First, take decisions on a few key aspects of documentation style; second, advertise them so that they will be taken into account in future developments.
This epic is blocked by
Nothing
This epic blocks
Nothing is directly blocked, but addressing this epic will make it easier to improve the documentation.
In particular, it will make it easier to address the fact that there is a relatively large number of warnings and some errors1 during the building of the docs, see, e.g., the latest log on readthedocs (click on the first
python -m sphinxcall to expand), which makes it harder to identify issues introduced by newly written documentation and also impedes the ability for incremental docs builds, resulting in an overall harder developer experience for writing docs.This is true for several projects in the conda ecosystem, but should be tracked with per-project issues.
Footnotes
Looks like most of the errors arise when conda classes don't have docstrings themselves, but are derived from other third-party classes. In that case, the docstring is taken from the parent class and often does not follow any of the supported docstring styles. This is also true for classes from the standard library. ↩