Suggestions

[mizzunet]

Last commit date, number of stars, number of downloads: somehow display these data in the bracket maybe from the specified repo, possible?

[offa]

Good question whether F-Droid provides those informations; Github infos could be available through 3rd party services. On the other hand, the list should remain simple and I don't know how much value they provide for users.

[mubashir-rehman]

The simple list is best option. If it has to be added then table format would be better with columns of app name, github stars, number of downloads.

[mubashir-rehman]

github stat example https://github.com/Sangwan5688/BlackHole#dont-forget-to-star-the-repo.

[shuvashish76]

Last commit date, number of stars, number of downloads: somehow display these data in the bracket maybe from the specified repo, possible?

Not in favor of number of stars, downloads and other related badges. I don't think popularity equals usefulness of the project for everyone's usecase. Also we've to keep it simple for maintenance and new contributors.

I propose to add following

1. Add Last commit badge https://shields.io/search/?q=last+commit This helps us to visually recognize which projects needs to be removed. We remove projects with last commit more than 3years ago. No badges if the project hosted on some other sites for which shield badges are not available. Again at least we can recognize them visually for manual checks.
2. Replace with F-Droid (https://shields.io/badges/f-droid-version) & IzzyOnDroid (https://gitlab.com/IzzyOnDroid/repo/-/wikis/API) badges. Helps to check if something moved from IzzyOnDroid repo to F-Droid visually.

Note:

• Always use default parameters i.e. no optional parameters for "Last commit badge" to keep it simple.
• For F-Droid/IzzyOnDroid we'll use our recommendation parameters in Contribution guide. Because in addition to default we want 2 additional logo & include_prereleases parameters for F-Droid. No need to use logo parameter for IzzyOnDroid as the official one is too long.

e.g.

Details

### • Dictionaries * [**Aard 2**](https://github.com/itkach/aard2-android)  [](https://f-droid.org/app/itkach.aard2) * [**Collins Dictionary**](https://github.com/Konyaco/CollinsDictionary)  [](https://f-droid.org/app/me.konyaco.collinsdictionary) * [**freeDictionaryApp**](https://github.com/yamin8000/freeDictionaryApp)  [](https://f-droid.org/app/io.github.yamin8000.owl) * [**Notification Dictionary**](https://github.com/tirkarthi/NotificationDictionary)  [](https://f-droid.org/app/com.xtreak.notificationdictionary) * [**QDict**](https://github.com/marmistrz/QDict)  [](https://f-droid.org/app/com.annie.dictionary.fork) * [**SilverDict**](https://github.com/Crissium/SilverDict-mobile)  [](https://f-droid.org/app/com.gmail.blandilyte.silverdict) Izzy repo e.g. * [**Paperize**](https://github.com/Anthonyy232/Paperize)  [](https://apt.izzysoft.de/fdroid/index/apk/com.anthonyla.paperize)

Looks like they show in different colors according to time by default which is nice. @offa What do you think? Useful information but does it look bit spammy to new users?

[offa]

@offa What do you think? Useful information but does it look bit spammy to new users?

To be honest, the entries seem a bit overloaded, and the important information almost gets lost.

The much more important point was already mentioned by you in the PR: we should support new, emerging projects and promote their use. The number of commits, stars, or forks can be misleading here. The fact that a project on the main branch has few commits does not necessarily provide a reliable indication of its quality (I am guilty of this as well).

[shuvashish76]

The much more important point was already mentioned by you in the PR: we should support new, emerging projects and promote their use.

ThankYou for your opinion. Promoting new projects is the main idea yes, it's just the burden on us to keep track of abandoned/inactive projects for users 🙈

The fact that a project on the main branch has few commits does not necessarily provide a reliable indication of its quality (I am guilty of this as well).

I agree. Still if possible I'll try to maintain it in a different branch in my fork so that I can track them when necessary. Don't expect it to be uptodate as always. The only purpose is to improve the original list. 👍🏿