This brings repositories.txt into sync with the production file @60ebae3ec0715c211682820354ebb0dfc3de2436. Many libraries
have been added via the old process, and a couple renamed, since the time this repository's file was generated.
UI element label text mentions intermingled with prose text in documentation can harm readability, especially when
skimming. For this reason, I think it is helpful to add formatting to clearly distinguish this text visually.
The previous wording was verbose and unclear, the result of copy/paste-based writing.
A backwards compatibility anchor tag is not needed in this case because this documentation has not yet been published,
meaning that there has been no opportunity for the creation of external links pointing to the old ID.
These anchor tags provide compatibility with links created before the heading text was changed (anchors are automatically
generated for headings). Placing them below the headings caused the page to be scrolled to below the headings when
visited via their links.
Previously, the submission list and the Library Manager index source list were both named "repositories.txt". I found having two files with similar content, but different purposes makes the already complex system unnecessarily difficult to understand.
Unlike the index source list, the submission list is solely a list of repositories, so its current "repositories.txt"
name is appropriate. The index source list contains other information unrelated to the library repository, so the
"repositories.txt" name is not so appropriate. Since the repository is named "library-registry", the filename
"registry.txt" makes sense.
If the PR is detected as something other than a submission, review is requested from a maintainer. It might be that the
PR was intended to be a submission and the submitter is able to resolve whatever caused it to be detected as otherwise
on their own. In this case, the automated system can handle things and review is no longer needed.
Review requests to the PR author are not allowed. Previously, there would be a spurious workflow failure for every PR
from a user in the `env.MAINTAINERS` array.
When a maintainer is submitting a PR, they can request reviews as needed, so the automated review request can simply be
skipped in this case.
Previously, the submission system was configured to automatically request reviews from the `arduino/team_tooling` team.
This doesn't work, likely due to the access token provided by GitHub not having the necessary permissions. However,
requesting from individual users works fine and in the end bothering the whole Tooling Team is probably a bad idea.
The library folder name is a factor in the Arduino Lint results. Although the library.properties `name` value is used for
the Library Manager installation path, Arduino Lint rules also consider manual installation of libraries. These results
will be most accurate if the library is located in a folder named after the repository.
We are accustomed to using the `actions/checkout` GitHub Action action in workflows whenever a repository needs to be
installed into the runner. So it may be quite unexpected to see `git clone` used.
In this case, it was necessary to do so in order to clone the library repository to run Arduino Lint on it because
`actions/checkout` can only be used with GitHub repositories, whereas multiple major Git hosts are supported for
submissions to Library Manager. This might not be obvious to those working on the workflow in the future, so it's worth
leaving a comment to avoid confusion.
