Skip to content

Restructure documentation for user-friendliness #1175

@dotsdl

Description

@dotsdl

The MDAnalysis documentation is structured in such a way that it contains scant information on the user interface and otherwise gives detail on the internal components of MDAnalysis that users should never really have to touch directly (parsers, readers and writers). We've seen usage on the mailing list from users in which they try e.g. to directly use a Reader object to parse a trajectory, and the docs don't make it clear that this isn't really the way to go about things.

I think the docs should be restructured to have three parts. The first part should read more like the MDAnalysis Tutorial, giving a friendly view as to how one uses MDAnalysis in practice. The second part should be an API reference, with the full sphinx autodoc output for the user interface components showed in part one. The last part should be the developer docs, which would include the reference docs for internal components, such as parsers, readers, and writers so that they are somewhere.

Thoughts?

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions