The period to close the sentence might be interpreted as part of the example repository URL. Since it doesn't provide any
benefits for the readability of this sentence and might cause confusion, it's best to remove it.
It turns out there are a couple of extra steps in the workflow for submitting a PR via the GitHub web interface for those
who don't have write access in the repository. I missed these while developing the instructions due to having write
access.
The process is intended to be as simple, fast, and flexible as possible for the submitter. For this reason, there is
absolutely no expectation regarding where in `repositories.txt` the library repository URL should be added. The system
will work fine no matter if it's at the start, end, alphabetical order, or some random spot. If we do want to restore
alphabetical order periodically, a maintainer can easily do that.
For this reason, there was previously no mention of the proper location in the list for submitters to use, since there is
none. However, this ambiguity might actually make the process less friendly to those who are left wondering. So it's best
to explicitly state that the location doesn't matter.
This link was intended to provide readily accessible information on what the term "fork" means in this context. However,
it comes directly after mention a link, which is referencing the URL provided later in the sentence. This might result in
confusion about which of the two links is meant. Most library submitters will already know the meaning of the term "fork"
and those who don't will be able to find information about it easily enough, including by visiting the information about
pull requests linked to earlier in the document. So I think that it's better to remove this link.
The library submission instructions contained a step for selecting a radio button before committing. This radio button
only exists when editing a file in a repository you have write access to, which is why I encountered it while developing
the instructions.
Library submitters will not have these radio buttons and so instructions for using a non-existent UI element would
cause confusion.
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.
The official policy is that anyone is allowed to submit any library to Library Manager, regardless of whether they have
any involvement with the development and maintenance of the library.
As someone very much involved in the submission process, I have always wondered this myself. So it is very important to
clearly document this.
Some of the wording of the existing documentation implied that only the owner of the library could submit it, so this
text has been adjusted as well.
It will be helpful to the reader to be able to get an overview of the documentation content and quickly navigate to the
section of interest.
The table of contents are automatically generated using the markdown-toc tool.
Because it can be easy to forget to update the table of contents when the documentation content is changed, I have added
a CI workflow to check for missed updates to readme ToC. On every push or pull request that affects the repository's
documentation, it will check whether the table of contents matches the content.
It is essential to clearly communicate the Library Manager requirements to the submitters. Previously, these requirements
were scattered throughout the FAQ. Consolidating them into unified lists, then referencing that information from the
other parts of the documentation makes it easier for the user to learn what are the requirements and easier for the
documentation to be maintained.
An FAQ hosted in the `arduino/Arduino` repository's wiki:
https://github.com/arduino/Arduino/wiki/Library-Manager-FAQ
has long served as the canonical guide for the traditional process for submitting libraries to the Library Manager index.
Now that the submission process and support for the process has been moved from `arduino/Arduino` to this dedicated
repository, it makes sense to also host the FAQ content here.
This commit imports the exact unmodified content of the FAQ from
819425389e
Submissions of libraries to the Arduino Library Manager index can be done by submitting a pull request adding repositor
URLs to the list. The submissions are checked for compliance wih the requirements for addition to the index and as soon
as they are passing the pull request is merged and the entries are pushed to the index source file.
