best-of-lists / best-of-generator Goto Github PK

Marking a project as "dead" because of a lack of activity is IMO a bad approach for a best-of list.
There can (and will) be cases where a project simply doesn't require that much maintenance. Either because the project doesn't have a lot of code to maintain (or none at all if it is about markdown or similar), the code is simple enough to not have a large chance of bugs appearing, or any used APIs/upstream stuff is stable enough to not cause too many bugs (and in most cases only bugs the upstream needs to fix).

Even if you now give the argument that issues and discussion activity are included in the repo being "active" is this still bad.
Projects may have different places where they collect issues and discussions, be it because it's more central (Allowing multiple projects they have to keep one central issue tracker) or because it's what they used before.
I myself saw a few projects that redirect issues through a separate page, so this isn't uncommon.

So, with this issue would I like to do two things:

• Propose the addition of options to either disable the "inactive" and "dead" checks completely, or change the displayed output (the emoji) and/or description.
• Start a discussion about the proposed idea and what possible alternatives are.

Right now are you calling projects "dead" based on some arbitrary number that may not count towards all projects... And that should be changed in some way.

Feature description:

The proposal is to be able to add organizations in addition to projects to the .yml file, and a a score that combines the score of its own projects in a unique score evaluating the organization "reputation".

The expected behavior would be to be able to add a section configurations to the projects.yaml file. The schema would be equivalent to the one for projects. The only difference would be how the score is calculated.

Problem and motivation:

When evaluating tools and projects, it is common to also evaluate organizations, companies, foundations, etc. behind the project. You can have a very trendy project but that is developed by a single person with no track record. When adopting technology, the following evidences use to be taking into account:

• track record of the organization
• number of contributors (total and long-term)
• active projects
• high quality projects
• etc.

For instance, for two similar projects in term of by-project quality, I might trust better a project belonging to apache foundation that a single-developer endeavour.

Is this something you're interested in working on?

Yes, I could collaborate in the definition, and testing.

Describe the bug:

If a project's description is not English, best-of will think it's all of special characters and remove anything.

(see remove_special_chars called in process_description)

Expected behaviour:

• Ideal behaviour: Only remove emoji and leave any other non-ASCII character as it is. — I guess it's too hard… (NLP needed?)
• acceptable behaviour: Provide an option to disable remove_special_chars. (I can try to make a PR if you'd like)

Steps to reproduce the issue:

Original description: (from BIThesis)

📖 北京理工大学非官方 LaTeX 模板集合，包含本科、研究生毕业设计模板及更多。🎉 （更多文档请访问 wiki 和 release 中的手册） 

Result: (in best-of-bits)

LaTeX wiki release.

Technical details:

• Host Machine OS: Ubuntu in GitHub Actions.

Possible Fix:

Additional context:

Feature description:

Custom URLs in the license field should be allowed as discussed in this PR.

Problem and motivation:

The motivation is that there are licenses that are not as well known as the "standard" licenses such as MIT, BSD, Apache 2.0. etc. and in those cases, an acronym might not be helpful. So, an URL directly linking to the specific license (text) might be the best solution.

Describe the bug:

The "back to top" indicator (small gray arrow) points to #content but this anchor doesn't exist if TOC is turned off.

Expected behaviour:

Should still go back to top, maybe insert anchor regardless of TOC or link to title instead.

Steps to reproduce the issue:

In projects.yaml:

configuration:
  generate_toc: False

projects:
  - name: Any repo
    homepage: https://github.com/best-of-lists/best-of-generator
    github_id: best-of-lists/best-of-generator

Technical details:

• Host Machine OS (Windows/Linux/Mac): Mac

Possible Fix:

Additional context:

Feature description:
Add a max_description_length configuration option, i.e.

configuration:
   max_description_length: 100

The code change should be minimal here. Since we are already passing a configuration dictionary into generate_project_md(), we could just replace 55 with configuration.max_description_length. In addition to this, we would also have to add the following to prepare_configuration:

if "max_description_length" not in config:
    config.max_description_length = 55

You could also consider allowing for None, which would remove the limit. I don't think that there is a (reasonable) limit to GitHub's description field. Therefore, I would vote for not doing this and instead requiring an explicit int limit.

Problem and motivation:

Currently, the default is value is 55. From the source code: The goal is that it fits into one row in most cases..
I am OK with this as a default as I agree that it is aesthetically more pleasing. However, I believe it would be a nice feature to add a configurable maximum value. Currently, I have some projects with a custom description (overwriting the default description from GitHub). It's a bit annoying that this is not shown in the final render.

Is this something you're interested in working on?

Yes

Feature description:

Problem and motivation:

Is this something you're interested in working on?

Problem and motivation:

The scientific community / research software development (RSE) community also makes extensive use of awesome-like lists. These typically collect publications, repositories, general resources, or a mix of those. Here are four random examples to showcase some of the commonly used list setups. graph-based-deep-learning-literature, https://github.com/neurreps/awesome-neural-geometry, awesome-materials-informatics, AI4Science resources.

These project's READMEs are static rather than CI-based and metrics-ordered, the distinguishing feature of best-of lists. For some, but not all such scientific lists, the best-of approach would be beneficial. Here are some random examples. best-of-atomistic-machine-learning.

It has become standard in many scientific fields that code and data associated with a preprint or publication are made available as repositories. So, the current project quality score already serves as a useful indicator in one dimension. However, another dimension even more important to the scientific community is missing sor far: the publication metric.

If the best-of project quality score would take into account publication metrics for any project with a linked publication, this would enhance software-focused scientific lists and open up the best-of template for publication lists, as well.

I propose to use this issue thread for discussion.

Feature description:

I can think of four main challenges to address.

• Challenge 01 Definition. Which publication metrics should enter a proposed 'publication quality score' and by which formulas should it be calculated?
• Challenge 02 Data collection. Which sources should be used to aggregrate these metrics?
• Challenge 03 Score combination. How should the 'publication score' be combined with the repo / package manager quality score into a combined project quality score?
• Challenge 04 Config format. How should the projects.yaml format implement publication metric support?
• Challenge 05 Implementation. How should the other challenges be implemented and documented?

I propose to use this issue thread for discussion of these challenges or add others.

Is this something you're interested in working on?

Yes

Note

Most GitHub projects use the Latin alphabet. So this issue can be given a low priority.

Describe the bug:

If I have a non-English category (e.g. 类), then the TOC will be generated as [类](#), whose href is empty.

Expected behaviour:

Render it as [类](#类) or [类](#category-id).

Steps to reproduce the issue:

(I've described it above)

👇 [网站](#).

👇 GitHub's anchor is #网站.

Technical details:

• Host Machine OS (Windows/Linux/Mac): Windows, GitHub Actions

Possible Fix:

Our process_md_link differs from GitHub's.

GitHub's algorithm is not documented, but people have discussed it at https://gist.github.com/asabaylus/3071099. In short, CJK and other Unicode characters matter.

https://gist.github.com/asabaylus/3071099?permalink_comment_id=1593627#gistcomment-1593627

The code that creates the anchors:

1. It downcases the string
2. remove anything that is not a letter, number, space or hyphen (see the source for how Unicode is handled)
3. changes any space to a hyphen.
4. If that is not unique, add "-1", "-2", "-3",... to make it unique

https://gist.github.com/asabaylus/3071099?permalink_comment_id=2563127#gistcomment-2563127

    text = text.lower().replace(" ", "-")
    text = re.compile(r"[`~!@#$%^&*()+=<>?,./:;"'|{}\[\]\\–—]").sub("", text)
    text = re.compile(r"[　。？！，、；：“”【】（）〔〕［］﹃﹄“”‘’﹁﹂—…－～《》〈〉「」]").sub("", text) # CJK punctuation
    return text

Additional context:

Relying on GitHub's tricky algorithm may be a bad idea, and we can use category IDs.

<h2 id='category-id'>Category Title</h2>

[Category Title](#category-id)

(<a id /> trick does not work.)

I tried to make a PR, but title_md_prefix: str = "##" is not compatible to <h2>. However, no code calls them with title_md_prefix. Can I make it private?

Describe the bug:

output_generator: markdown-gallery not work in current version (0.8.5).

Expected behaviour:

output_generator should support "markdown-gallery", not only "markdown-list" in this configuration: https://github.com/best-of-lists/best-of-generator#configuration-options

Steps to reproduce the issue:

Follow best-of-streamlit repo's projects.yml, and update github workflow best-of-update-action to version 0.8.5, when trigger action this bug happend.

Technical details:

• Host Machine OS (Windows/Linux/Mac):

Possible Fix:

Additional context:

markdown-gallery feature was introduced by this pr: #29

Feature description:

Allow multiple project artifacts from the same package managers. Some project have multiple distributions on the same package managers (for example PySimpleGUI). Also, combine all metrics (e.g. download count) from all distributions.

Describe the bug:

Setting hide_license_risk: True in the configuration doesn't seem to have any effect. The ❗️ before the license still shows up.

Expected behaviour:

As the docs state, the ❗️ indicator should disappear.

Steps to reproduce the issue:

In projects.yaml:

configuration:
  hide_license_risk: True

projects:
  - name: Repo without license
    homepage: https://github.com/jrieke/machine-intelligence
    github_id: jrieke/machine-intelligence

Output:

- <b><a href="https://github.com/jrieke/machine-intelligence">Repo without license</a></b> (🥇3 ·  ⭐ 1 · 💀) - Code for the class Machine Intelligence 1 at TU Berlin. <code>❗️Unlicensed</code>

Technical details:

• Host Machine OS (Windows/Linux/Mac): Mac

Possible Fix:

Additional context:

Feature description:

Support the download statistics for GitHub Releases.

Problem and motivation:

Some packages are distributed through GitHub Releases. It's nice to support the download statistics for it.

shield.io has supported it: https://shields.io/badges/git-hub-all-releases

Is this something you're interested in working on?

Yes, but need some instructions.

The best-of-update actions fails. Since the actions don't have issues, opening one here:

  E: Unable to locate package libappindicator1

  The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends gconf-service     libasound2 libatk1.0-0 libatk-bridge2.0-0 libc6 libcairo2 libcups2 libdbus-1-3     libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0     libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6     libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3     libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation     libappindicator1 libnss3 lsb-release xdg-utils wget     && apt-get clean     && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100

Error: Docker build failed with exit code 100

Feature description:

Would be great to be able to reference Dart and Flutter packages on pub.dev

Problem and motivation:

Not supported yet.

Is this something you're interested in working on?