Hope this is seen as a suggestion for improving the list and building a healthy community.
It seems to me there is an influx of new projects.
I've been subscribed to awesome-tuis for over the past few years, since I discovered it, and the tools I've learned about are all awesome.
With the new additions, though, it looks like awesome-tuis has gained an increased list of LLM generated projects, which all seem like potentially very useful, but lack the 'awesome' aspect that used to rule the list of the past. (I too create apps with LLM, but I will only share something I plan on actually maintaining - which is the hard part in FOSS)
Step #1 would probably be to define what 'awesome' should mean, some ideas:
Accepting a submission from maintainer shouldn't be the norm.
at least 2 of the following must be met:
More than X amount of stars
More than X amount of commits in the recent 3 months
More than X days since repo creation with at least X days since last commit
Those are for submissions to the awesome list.
And these rules are not intended to 'punish' those who want to show off their new projects, that's what step #2 would address.
Step #2 would be enabling the Discussion board:
It's clear that there is a live community following this list.
The Show and Tell discussion category, along with a minimal voting score could probably be one of the criteria to add to the list above.
The same scoring could be used with discussing removal of submitted projects that seem stale.
This would make the list a bit more community driven, and will release the burden of just allowing everything in.
Originally created by @Lockszmith-GH on GitHub (Jan 31, 2026).
Original GitHub issue: https://github.com/rothgar/awesome-tuis/issues/523
Hope this is seen as a suggestion for improving the list and building a healthy community.
It seems to me there is an influx of new projects.
I've been subscribed to awesome-tuis for over the past few years, since I discovered it, and the tools I've learned about are all awesome.
With the new additions, though, it looks like awesome-tuis has gained an increased list of LLM generated projects, which all seem like potentially very useful, but lack the 'awesome' aspect that used to rule the list of the past. (I too create apps with LLM, but I will only share something I plan on actually maintaining - which is the hard part in FOSS)
Step #_1_ would probably be to define what 'awesome' should mean, some ideas:
> Accepting a submission from maintainer shouldn't be the norm.
> at least 2 of the following must be met:
> * [ ] More than X amount of stars
> * [ ] More than X amount of commits in the recent 3 months
> * [ ] More than X days since repo creation with at least X days since last commit
Those are for submissions to the awesome list.
And these rules are not intended to 'punish' those who want to show off their new projects, that's what step #_2_ would address.
Step #_2_ would be enabling the Discussion board:
It's clear that there is a live community following this list.
The Show and Tell discussion category, along with a minimal voting score could probably be one of the criteria to add to the list above.
The same scoring could be used with discussing removal of submitted projects that seem stale.
This would make the list a bit more community driven, and will release the burden of just allowing everything in.
Thanks for the issue. I've had a hard time figuring out how to keep the list high quality without punishing apps and devs. I'm mostly worried about apps that prove some utility, get installed on systems, and then pivot to be malicious. It would be extremely difficult to track down all the things people have brew installed that could easily steal things like ssh keys when executed.
My initial thought was setting a time threshold. I was thinking the project needs to be at least 6 months old and should have a commit within the last 10% of it's lifetime. So that would mean a 6 month old project should have a commit in the past 15 days and something 4 years old could have a commit in the past 3 months. ofc all of these metrics can be gamed, but hopefully it would encourage people to come back after they've matured the project for a bit.
10% might be too difficult to calculate (and doesn't need to be a hard limit), but I think it avoids stuff people vibe coded one time and have no interest in maintaining and also allowing stuff that's been around for a long time and isn't requiring a lot of new features/maintenance.
I like your idea of pushing people towards discussions because they can share cool stuff they've built and it doesn't have to be on the list.
I also think I should probably have 1-2 additional maintainers because I don't have enough time to vet all of the projects. I always look through the submissions to make sure they meet my TUI definition, but there wouldn't be a backlog if the load was shared.
<!-- gh-comment-id:3830365569 -->
@rothgar commented on GitHub (Feb 1, 2026):
Thanks for the issue. I've had a hard time figuring out how to keep the list high quality without punishing apps and devs. I'm mostly worried about apps that prove some utility, get installed on systems, and then pivot to be malicious. It would be extremely difficult to track down all the things people have brew installed that could easily steal things like ssh keys when executed.
My initial thought was setting a time threshold. I was thinking the project needs to be at least 6 months old and should have a commit within the last 10% of it's lifetime. So that would mean a 6 month old project should have a commit in the past 15 days and something 4 years old could have a commit in the past 3 months. ofc all of these metrics can be gamed, but hopefully it would encourage people to come back after they've matured the project for a bit.
10% might be too difficult to calculate (and doesn't need to be a hard limit), but I think it avoids stuff people vibe coded one time and have no interest in maintaining and also allowing stuff that's been around for a long time and isn't requiring a lot of new features/maintenance.
I like your idea of pushing people towards discussions because they can share cool stuff they've built and it doesn't have to be on the list.
I also think I should probably have 1-2 additional maintainers because I don't have enough time to vet all of the projects. I always look through the submissions to make sure they meet my TUI definition, but there wouldn't be a backlog if the load was shared.
It's hard to keep up with discussions in many cases. Issues are generally related to a single application, which makes searching and participating easy enough. As someone who reads everything, it is a bit exhausting to see repeats of discussions that have already had an issue. If there's a link to the issue being duplicated, the conversation often continues in both places, and further confuses people searching in the future.
<!-- gh-comment-id:3837656859 -->
@Technetium1 commented on GitHub (Feb 2, 2026):
I think having some age thresholds are necessary. Some related conversation on guidelines: https://github.com/awesome-foss/awesome-sysadmin/issues/460
It's hard to keep up with discussions in many cases. Issues are generally related to a single application, which makes searching and participating easy enough. As someone who reads *everything*, it is a bit exhausting to see repeats of discussions that have already had an issue. If there's a link to the issue being duplicated, the conversation often continues in both places, and further confuses people searching in the future.
Thanks for entertaining this idea @rothgar, it does seem to be an overwhelming task at times.
@Technetium1 - I agree that opening an additional channel creates initial friction, but community rules are the way to resolve this.
If we create a culture where all new submissions either start as a discussion or an PR and issues are used to resolve issues in the list, I think we can create a healthy culture.
I follow quite a few repos on GH, and found the discussion board to bring value.
<!-- gh-comment-id:3860606104 -->
@Lockszmith-GH commented on GitHub (Feb 6, 2026):
Thanks for entertaining this idea @rothgar, it does seem to be an overwhelming task at times.
@Technetium1 - I agree that opening an additional channel creates initial friction, but community rules are the way to resolve this.
If we create a culture where all new submissions either start as a discussion or an PR and issues are used to resolve issues in the list, I think we can create a healthy culture.
I follow quite a few repos on GH, and found the discussion board to bring value.
Is there a way to enforce PRs need a discussion first? I have a feeling that's going to add extra review/management burden if it can't be automated.
<!-- gh-comment-id:3879527501 -->
@rothgar commented on GitHub (Feb 10, 2026):
Is there a way to enforce PRs need a discussion first? I have a feeling that's going to add extra review/management burden if it can't be automated.
There is no inbuilt functionality for discussion monitoring. It is possible to have PR template that requests related issues/discussion, however PR author would have to fill it themselves. Discussions do not support PR linkage, but issues do.
<!-- gh-comment-id:3897869040 -->
@Technetium1 commented on GitHub (Feb 13, 2026):
There is no inbuilt functionality for discussion monitoring. It is possible to have PR template that requests related issues/discussion, however PR author would have to fill it themselves. Discussions do not support PR linkage, but issues do.
- https://github.com/orgs/community/discussions/3548 + https://github.com/orgs/community/discussions/2971
- https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository#adding-a-pull-request-template
- https://github.com/embeddedartistry/templates/blob/master/oss_docs/PULL_REQUEST_TEMPLATE.md?plain=1
- https://github.com/dec0dOS/amazing-github-template/blob/main/.github/PULL_REQUEST_TEMPLATE.md?plain=1
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Lockszmith-GH on GitHub (Jan 31, 2026).
Original GitHub issue: https://github.com/rothgar/awesome-tuis/issues/523
Hope this is seen as a suggestion for improving the list and building a healthy community.
It seems to me there is an influx of new projects.
I've been subscribed to awesome-tuis for over the past few years, since I discovered it, and the tools I've learned about are all awesome.
With the new additions, though, it looks like awesome-tuis has gained an increased list of LLM generated projects, which all seem like potentially very useful, but lack the 'awesome' aspect that used to rule the list of the past. (I too create apps with LLM, but I will only share something I plan on actually maintaining - which is the hard part in FOSS)
Step #1 would probably be to define what 'awesome' should mean, some ideas:
Those are for submissions to the awesome list.
And these rules are not intended to 'punish' those who want to show off their new projects, that's what step #2 would address.
Step #2 would be enabling the Discussion board:
It's clear that there is a live community following this list.
The Show and Tell discussion category, along with a minimal voting score could probably be one of the criteria to add to the list above.
The same scoring could be used with discussing removal of submitted projects that seem stale.
This would make the list a bit more community driven, and will release the burden of just allowing everything in.
@rothgar commented on GitHub (Feb 1, 2026):
Thanks for the issue. I've had a hard time figuring out how to keep the list high quality without punishing apps and devs. I'm mostly worried about apps that prove some utility, get installed on systems, and then pivot to be malicious. It would be extremely difficult to track down all the things people have brew installed that could easily steal things like ssh keys when executed.
My initial thought was setting a time threshold. I was thinking the project needs to be at least 6 months old and should have a commit within the last 10% of it's lifetime. So that would mean a 6 month old project should have a commit in the past 15 days and something 4 years old could have a commit in the past 3 months. ofc all of these metrics can be gamed, but hopefully it would encourage people to come back after they've matured the project for a bit.
10% might be too difficult to calculate (and doesn't need to be a hard limit), but I think it avoids stuff people vibe coded one time and have no interest in maintaining and also allowing stuff that's been around for a long time and isn't requiring a lot of new features/maintenance.
I like your idea of pushing people towards discussions because they can share cool stuff they've built and it doesn't have to be on the list.
I also think I should probably have 1-2 additional maintainers because I don't have enough time to vet all of the projects. I always look through the submissions to make sure they meet my TUI definition, but there wouldn't be a backlog if the load was shared.
@Technetium1 commented on GitHub (Feb 2, 2026):
I think having some age thresholds are necessary. Some related conversation on guidelines: https://github.com/awesome-foss/awesome-sysadmin/issues/460
It's hard to keep up with discussions in many cases. Issues are generally related to a single application, which makes searching and participating easy enough. As someone who reads everything, it is a bit exhausting to see repeats of discussions that have already had an issue. If there's a link to the issue being duplicated, the conversation often continues in both places, and further confuses people searching in the future.
@Lockszmith-GH commented on GitHub (Feb 6, 2026):
Thanks for entertaining this idea @rothgar, it does seem to be an overwhelming task at times.
@Technetium1 - I agree that opening an additional channel creates initial friction, but community rules are the way to resolve this.
If we create a culture where all new submissions either start as a discussion or an PR and issues are used to resolve issues in the list, I think we can create a healthy culture.
I follow quite a few repos on GH, and found the discussion board to bring value.
@rothgar commented on GitHub (Feb 10, 2026):
Is there a way to enforce PRs need a discussion first? I have a feeling that's going to add extra review/management burden if it can't be automated.
@Technetium1 commented on GitHub (Feb 13, 2026):
There is no inbuilt functionality for discussion monitoring. It is possible to have PR template that requests related issues/discussion, however PR author would have to fill it themselves. Discussions do not support PR linkage, but issues do.
@Lockszmith-GH commented on GitHub (Apr 20, 2026):
#645
🎉