auto generated docs for latest plugin versions #463
Conversation
|
@jsvd So is this the full list of changes we need to make to the repos, or is there still some stuff from earlier iterations that needs cleaning up (like the links)? Even if the script handles converting the link format from internal to external, we might want to update the links in the repos 'cause people have a way of looking at existing stuff for examples. We wouldn't have to make the changes before we publish the doc, tho. |
++ @dedemorton I'll dial down the corrections I perform automatically and recompute this PR |
jsvd
force-pushed
the
latest_broken_versioned_docs
branch
from
7605b7b to
fc3d177
Compare
|
@dedemorton skipping doc repair heuristics like the data types link conversion we see that 190 plugins need corrections |
|
@jsvd Is that all? haha. I'd make the data type conversions an exception, but then...if we do that, we're back to the original problem of people duplicating what they see in the existing dos. hmmm...so maybe we just leave the doc repair heuristics alone? |
jsvd
force-pushed
the
latest_broken_versioned_docs
branch
from
fc3d177 to
ec45574
Compare
|
@dedemorton I recomputed the PR to apply the data type conversions only. This shows 26 plugins whose latest release tag contains "broken" documentation. I think it's a reasonable goal to: WDYT? [edit] I created an example PR for 1 plugin that addresses only the data type conversions: logstash-plugins/logstash-output-elasticsearch#728 |
|
I'm going to close this PR. I opened issue #9048 to track the remaining tasks for the versioned plugin reference. |
@dedemorton this is the result of generating the docs for just the latest version of each plugin.
There are still some things I generate differently, mostly due to lack of information like the description.
My thinking is that we (I) should submit doc PR changes for these 11 plugins, and release new versions.
After this we can start relying on auto generation, or at least script-driven generation.