Awesome list preperation

[sancarn]

PR Requirements

PR Title: "Add VBA"
PR addition: "VBA/VB6 - Visual Basic for Applications (VBA) is an implementation of Microsoft's event-driven programming language Visual Basic 6.0 (VB6) built into most desktop Microsoft Office applications"

• Include the word unicorn to PR description
• Add to bottom of category, (not alphabetical order)

Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file.

• Doesn't really apply to VBA

Author requirements

• Review open PRs (1) - Add Ukrainian IT Communities sindresorhus/awesome#2541 (review)
• Review open PRs (2) - Add AI in Cybersecurity sindresorhus/awesome#3129 (review)

Requirements

• Has been around for at least 30 days.
• Don't open a Draft / WIP pull request while you work on the guidelines. A pull request should be 100% ready and should adhere to all the guidelines when you open it. Instead use #2242 for incubation visibility.
• Run awesome-lint on your list and fix the reported issues. If there are false-positives or things that cannot/shouldn't be fixed, please report it.
• The default branch should be named main, not master.
• Includes a succinct description of the project/theme at the top of the readme. (Example)
• It's the result of hard work and the best I could possibly produce. If you have not put in considerable effort into your list, your pull request will be immediately closed.
• The repo name of your list should be in lowercase slug format: awesome-name-of-list.
• The heading title of your list should be in title case format: # Awesome Name of List
• Non-generated Markdown file in a GitHub repo.
• The repo should have awesome-list & awesome as GitHub topics. I encourage you to add more relevant topics.
• Not a duplicate. Please search for existing submissions.
• Only has awesome items. Awesome lists are curations of the best, not everything.
• [N/A] Does not contain items that are unmaintained, has archived repo, deprecated, or missing docs. If you really need to include such items, they should be in a separate Markdown file
• Includes a project logo/illustration whenever possible
• Entries have a description, unless the title is descriptive enough by itself. It rarely is though
• Includes the Awesome badge
• Has a Table of Contents section
• Has an appropriate license >> (CC4)
• Has contribution guidelines >> (https://github.com/sancarn/awesome-vba/blob/main/Contributing.md)
• All non-important but necessary content (like extra copyright notices, hyperlinks to sources, pointers to expansive content, etc) should be grouped in a Footnotes section at the bottom of the readme. The section should not be present in the Table of Contents.
• Has consistent formatting and proper spelling/grammar
• Doesn't use hard-wrapping
• Doesn't include a Travis badge; You can still use Travis for list linting, but the badge has no value in the readme.
• Doesn't include an Inspired by awesome-foo or Inspired by the Awesome project kinda link at the top of the readme. The Awesome badge is enough

[sancarn]

Awesome-lint run

Fixed various issues. Many issues still remain but are invalid. Examples:

• Table of Contents must be the first section - The symbology is very important in the case of VBA.
• Titles should use ' as a quote - occurs when [xx][# "Tooltips"] are used
• ToC item "awesome-vba" does not match corresponding heading "Frameworks" - The ToC contains the header sections.
• Invalid list item link - I think this is because of the symbology, which again is a strict requirement.
• Text "StackOverflow" should be written as "Stack Overflow" - Disagree, StackOverflow.com is a website. This is not meant to indicate a stack overflow.
• • Invalid list item link URL - Tooltip misinterpreted as URL.

[DecimalTurn]

So, the only thing missing is the 2nd PR review, is that correct?

[sancarn]

So, the only thing missing is the 2nd PR review, is that correct?

Yes, I think so 🙂

[DecimalTurn]

The guidelines have the following statement regarding the table of contents: "Should only have one level of nested lists, preferably none."

Maybe we should remove the link to the top heading so we can shift up everything in the list.

[DecimalTurn]

Actually, that limitation would also cause problem with the "Data Formats" as well. If we follow the guidelines, JSON, CSV and XML would need to stand as their own subsection of the librairies section be removed from the table of contents even if those subsections exist in the document (same thing for Data structures).

[DecimalTurn]

Also, if you need some inspirations for a review, it seems like the recent PR named "Add Google Cloud" failed to apply the following rule (last 2 sentences):

Has contribution guidelines.
The file should be named contributing.md. The casing is up to you.
It can optionally be linked from the readme in a dedicated section titled Contributing, positioned at the top or bottom of the main content.
The section should not appear in the Table of Contents.

Basically, the contributing link should be in a seperate section named "Contributing" (not a subsection) and the section "About This Document" shouldn't be part of the Table of Contents and renamed to "Footnotes" based on the next section of the guildelines.

[sancarn]

Also iirc I think I held off applying because of the symbology. I think the symbology is theoretically not allowed...

[DecimalTurn]

It would be allowed at the end in the Footnotes section. Considering that the icons have a tooltip when hovering on them, I personally wouldn't mind putting the symbology at the end if that means that the list becomes eligible.

There's always the option to ask for an exception, but I doubt that we'd get it.