Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better rendering of awesome-gno #24

Open
moul opened this issue Jan 30, 2023 · 4 comments
Open

Better rendering of awesome-gno #24

moul opened this issue Jan 30, 2023 · 4 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@moul
Copy link
Member

moul commented Jan 30, 2023

What can we make to make the awesome-gno easier to browse, especially when it will have much more content?

I'm thinking about creating a webpage updated after each merge.
Or to use a tool to generate richer markdowns, with sections, previews, and stats.

@moul moul added good first issue Good for newcomers help wanted Extra attention is needed labels Jan 30, 2023
@moul
Copy link
Member Author

moul commented Feb 9, 2023

By switching to a new model, we could ask people to register new entries in csv/yaml files so we can have tags; then everything markdown is managed by the engine, not by humans.

If we do this, I expect that links could be linked to "tags/categories" with things like "staff picks", but also to "questions", so we can create an automated FAQ.

@solofomo
Copy link

this tool can be used to build the awesome page
https://github.com/anuraghazra/github-readme-stats

for the tags/categories part, need to do more research, working on it

@poroburu
Copy link

My approach is to generate a awesome-lint compatible README from a markdown template.
This allows a HTML template to include the rich descriptions stats and media, and be hosted on a GitHub Page or externally.
The awesome-gno content is sourced from a YAML file converted from the previous markdown README.

@thehowl
Copy link
Member

thehowl commented Sep 23, 2024

@poroburu I'd ideally prefer working directly on the markdown rather than editing a yaml. There can be syntaxes understood by the linter and marshalers, but IMO the source of truth should be the markdown.

Counter-arguments welcome. My preference is that 1. i don't particularly like modifying very large yaml files over time and 2. we should be able to add more information and adjust the README dynamically, rather than having to modify a generator in order to change the markdown. -> README is source of truth, rest is derivation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants