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.

[sancarn]

Not sure why this was closed down... I need to do this

[sancarn]

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

@DecimalTurn you are correct, this is a valid point.

[DecimalTurn]

Not sure why this was closed down

I discovered recently that if you write "Fixes" or "Closes" in front an issue inside the description of a PR, GitHub will link them together and close the issue when the PR is merged. EDIT: This also applies to commit message of commits inside the branch for the PR.

PS: I re-read my last message and realized my last message was missing a negative in "wouldn't mind", but the setup of the sentence made it clear what I meant luckily.

[sancarn]

Not sure why this was closed down

I discovered recently that if you write "Fixes" or "Closes" in front an issue inside the description of a PR, GitHub will link them together and close the issue when the PR is merged. EDIT: This also applies to commit message of commits inside the branch for the PR.

Correct, I did know about this, total oversight from my part because "fixes" in that sentence implies something else to me xD

I altered the awesome list with the aforementioned changes of moving symbology to footnotes last night, and prepared a fork @ https://github.com/sancarn/awesome

[DecimalTurn]

I altered the awesome list with the aforementioned changes of moving symbology to footnotes last night, and prepared a fork @ sancarn/awesome

Nice. Only need to adjust the TOC and I think we are good to go!

[sancarn]

Closeout in progress sindresorhus/awesome#3153

[DecimalTurn]

FYI, regarding the Symbology section, I just noticed that this awesome list has a legend section right after the TOC, so we could ask if we can do the same.

[Greedquest]

Glancing at the Linter validation rules I think moving the symbols to the end of the line will fix the linting issues, it looks like it wants the structure {link} - {description}. where the first is a non dead url

[sancarn]

Glancing at the Linter validation rules I think moving the symbols to the end of the line will fix the linting issues, it looks like it wants the structure {link} - {description}. where the first is a non dead url

Indeed. I don't think that is the right course of action though... I think the linter needs a PR to allow it to consider this option. What are your thoughts?

[DecimalTurn]

Symbols at the start seems preferable for me as well. For the linter, I'm guessing we'd have to do the PR ourselves otherwise it won't happen.

[sancarn]

Symbols at the start seems preferable for me as well. For the linter, I'm guessing we'd have to do the PR ourselves otherwise it won't happen.

Probably, yes 😅. Looks like it would be modifying this file: https://github.com/sindresorhus/awesome-lint/blob/d83d0361be944593b27d3060942a6a7dce33216d/rules/list-item.js#L141

[sancarn]

Actually I think the problem is more here:

https://github.com/sindresorhus/awesome-lint/blob/d83d0361be944593b27d3060942a6a7dce33216d/rules/list-item.js#L111-L116

So currently it continuously discards till it hits a link. Better would be looping through until we hit a -. Also I assume the problem case is really links with tooltips?

[DecimalTurn]

Btw, If we have to drop the wrapper around images ([...](#-)) that I've added to prevent images from linking anywhere, I can live with it. The only thing that will happen when people click on the image is that they'll be redirected to the page of the image itself, but they can easily go back anyways.

Note to self

Replace: \[(!\[.+?\])\]\(#-\)
With: $1

[DecimalTurn]

By doing that and some other changes, I managed to make a few changes that made the linter checks pass.

I'll make a PR later this weekend unless you think I shouldn't.

[sancarn]

Btw, If we have to drop the wrapper around images (...) that I've added to prevent images from linking anywhere, I can live with it

I can live with it but it's less awesome 😅 Not really sure if we should make concessions for something which decreases quality of the list...