update readme to md and add filter example

[RickeyMessick]

No description provided.

[Lewiscowles1986]

Thanks so much @RickeyMessick.

I take it, https://johnblackbourn.com/readme-md-plugin-on-wordpress-org/ might be a good resource to catch people up on markdown readme files, if anyone stumbles into this. But I am guessing as to your motivations as there is not any description provided or an issue raised to discuss this. I Too get excited with ideas for repo's; but if you could spare the time to explain what you think this would add, that existing documentation does not:

• More playback choices possible? #5
• https://wordpress.org/support/topic/can-the-available-speed-values-be-customized/

Unfortunately, it is not GitHub flavored markdown;, so tilde, instead of backticks are used for code indentation tonsky/FiraCode#439; and I think there might be more work than this. @johnbillion actually links an example https://github.com/johnbillion/user-switching/blob/develop/readme.md in that article, which translates to https://wordpress.org/plugins/user-switching/

I Really like that John puts those under a frequently asked questions section, where the code is never visible by default on the plugin repo, which would be a similar treatment to what I'd want here to accept readme changes with code.

In any case, again, thank you, I Hope you are having a great 2022.

[RickeyMessick]

It would help to be easily spelled out. Instead of having to put these 2 articles together just have the full example in the docs.
https://wordpress.org/support/topic/can-the-available-speed-values-be-customized/
#5

[Lewiscowles1986]

@RickeyMessick if you want this merged, it's going to need code changes.

It's also going to need, an adaptation in communication style and approach.

1. I'm aware the documentation can always be improved, and that a diverse range of voices needs to create documentation.
2. I Applaud that you wish to change documentation, and contribute to a community project.
3. If you want the docs changed, I ask that you commit to that intention, by communicating less tersely, and thinking of other users.
4. So far this is an opinion piece of specific and poorly formatted code.
   a. The indentation and whitespace is not in keeping with the code or it's examples.
   b. The markdown seems to be in the wrong format.
   c. This only benefits the legacy implementation of shortcode-based speed controls.
   d. There is no change management, or quality management, for me to know this documentation works.

Right now, I Feel like it would be better in a GitHub issue, or a support forum post communicating something like "Hey, here is the thing I needed in one place". That then gives me an idea via reactions, follow-up posts, thanks and reviews to know "This is a thing the people need".

1. That meets your stated objective.
2. It does not complicate the documentation with details most people don't need.
3. It gives you credit for your hard work.
4. It avoids any need for friction, or what might be seen as opinion here.