Objective: Pulp plugin documentation contains everything a Pulp user needs to set up and operate anything related to that plugin.
Melanie:
If we return to Ina's question from the end of last week and take a feature of the upcoming Pulpcore release, how would we approach documenting it?
Ina:
Each plugin is independent and autonomous.
Plugins require compatibility releases.
Perhaps docs are added as part of the compatibility release for the plugin?
Brian:
We should look at some short term objectives first, like implementing the CLI in our documentation. We have all these CLI commands but are not passing them on to our users.
Ina:
We need a clear definition of a long-term goal. From what we have now, it isn't clear how the CLI action item has any relation to what we want to achieve overall.
Fabricio:
I'm interested in working to improve the docs overall, especially the installation docs. The CLI objective makes less sense as an immediate step.
Problem statement:
Pulp users get things done in spite of our docs. We undoubtedly lose and confuse potential users along the way.
Overall goal:
Move towards having full workflow documentation and compatibility statements within each plugin doc.
Short term goal:
There are a number of steps we need to identify to achieve these goals.
In terms of an immediate, short term goal, while our CLI options have been developing, many plugin docs have not been updated.
The CLI greatly lowers the barrier of entry for users when compared with scripting against the API.
Ask at Open Floor that one person from each mini team reviews the plugin docs, and replaces all API calls with CLI where applicable.
Brian, Fabricio, Ina, Melanie
Plugin sites: key steps to doing everything
Melanie:
Long term goal would be to move to mkdocs and simplify the previewing process, therefore making it easier to contribute in general.
Brian:
Melanie:
Fabricio:
Ina:
Brian:
Melanie:
Brian:
The installation documentation is the same largely the same.
Ina:
Brian:
Ina: