Implementing stricter guidelines regarding the age of a software? #4625

New Issue

GiteaMirror · 2025-11-26T21:06:11-06:00

GiteaMirror commented

2025-11-26 21:06:11 -06:00

Originally created by @Rabenherz112 on GitHub (Jun 8, 2023).

Since a PR (https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3822) might not be the best place for discussing potential changes to contribution guidelines, I created a separate Issue.

The suggestion revolves around enhancing the identification of "low-quality" projects and excluding them from the list by introducing a minimum lifespan requirement. This requirement would serve to filter out newly created projects that are more susceptible to bugs and may still be in the early development stages. Additionally, it would offer insights into the developers' dedication to maintaining and regularly updating their software.

In my opinion, it would be beneficial to implement a requirement of two months for the minimum lifespan of projects. This timeframe allows for a reasonable evaluation period to assess if developers are consistently working on their software. It strikes a balance between giving projects enough time to showcase their progress and preventing the exclusion of potentially awesome new software from the list.

What are your thought on this?

Originally created by @Rabenherz112 on GitHub (Jun 8, 2023). Since a PR (https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3822) might not be the best place for discussing potential changes to contribution guidelines, I created a separate Issue. The suggestion revolves around enhancing the identification of "low-quality" projects and excluding them from the list by introducing a minimum lifespan requirement. This requirement would serve to filter out newly created projects that are more susceptible to bugs and may still be in the early development stages. Additionally, it would offer insights into the developers' dedication to maintaining and regularly updating their software. In my opinion, it would be beneficial to implement a requirement of two months for the minimum lifespan of projects. This timeframe allows for a reasonable evaluation period to assess if developers are consistently working on their software. It strikes a balance between giving projects enough time to showcase their progress and preventing the exclusion of potentially awesome new software from the list. What are your thought on this?

GiteaMirror added the curation discussion labels 2025-11-26 21:06:11 -06:00

GiteaMirror closed this issue

2025-11-26 21:06:11 -06:00

GiteaMirror commented

2025-11-26 21:06:12 -06:00

@nodiscc commented on GitHub (Jul 6, 2023):

Sorry for the late reply, and thank you for raising this issue.

This requirement would serve to filter out newly created projects that are more susceptible to bugs and may still be in the early development stages. Additionally, it would offer insights into the developers' dedication to maintaining and regularly updating their software.

This is exactly what this is about.

I suggest adding the following requirement under Any software project you are adding to the list is actively maintained.:

Any software project you are adding to the list was first released more than 6 months ago

In my experience maintaining this list, interest in maintaining a piece of software tends to fade out after a few months. A two-month lifespan might not be enough to get enough users/testers on board, discover and fix most serious bugs, and judge whether maintenance is kept up or declining. If a project is still around and actively maintained after 6 months of existence, there are more chances that it will keep being maintained in the long term.
It also coincides with our definition of "unmaintained" (no changes in the last 6 months).
It would also filter out "weekend-project-quality" entries mentioned in https://github.com/awesome-selfhosted/awesome-selfhosted/issues/3589.

Nothing prevents submitting a Pull Request for a project that does not fit the "6 month minimum lifespan" requirement, it would just be put on hold until that threshold is reached. We could create a special label for such addition requests, and people interested in trying out new projects could look at these.

(@Rabenherz112 Note that you identified a submission (https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3876=) as not suitable for inclusion in the list - I agree with your review, however in this particular case the project is more than 6 months old. So adding this guideline would not filter out all occurences of low-quality or unsuitable software.)

What do you think?

@nodiscc commented on GitHub (Jul 6, 2023): Sorry for the late reply, and thank you for raising this issue. > This requirement would serve to filter out newly created projects that are more susceptible to bugs and may still be in the early development stages. Additionally, it would offer insights into the developers' dedication to maintaining and regularly updating their software. This is exactly what this is about. I suggest adding the following requirement under ` Any software project you are adding to the list is actively maintained.`: > Any software project you are adding to the list was first released more than 6 months ago - In my experience maintaining this list, interest in maintaining a piece of software tends to fade out after a few months. A two-month lifespan might not be enough to get enough users/testers on board, discover and fix most serious bugs, and judge whether maintenance is kept up or declining. If a project is still around and actively maintained after 6 months of existence, there are more chances that it will keep being maintained in the long term. - It also coincides with our definition of "unmaintained" (no changes in the last 6 months). - It would also filter out "weekend-project-quality" entries mentioned in https://github.com/awesome-selfhosted/awesome-selfhosted/issues/3589. Nothing prevents submitting a Pull Request for a project that does not fit the "6 month minimum lifespan" requirement, it would just be put on hold until that threshold is reached. We could create a special label for such addition requests, and people interested in trying out new projects could look at these. (@Rabenherz112 Note that you identified a submission (https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3876=) as not suitable for inclusion in the list - I agree with your review, however in this particular case the project **is** more than 6 months old. So adding this guideline would not filter out all occurences of low-quality or unsuitable software.) What do you think?

GiteaMirror commented

2025-11-26 21:06:12 -06:00

@Rabenherz112 commented on GitHub (Jul 6, 2023):

First of all, thank you nodiscc for your response and valuable insights on this topic.

Any software project you are adding to the list was first released more than 6 months ago

While I highly respect your experience as the primary maintainer (please understand that I mean no disrespect), I believe that a 6-month timeframe is too strict. Although I agree that it aligns with our definition of unmaintained projects, it could exclude already excellent software from the list. For example, in the past few weeks, we have approved software such as #3849, #3857, #3921, #3798 that would not meet the new requirement. While it would only mean for these software, that they have to wait until they have matured enough (and pass the check that they are still actively maintained), it would still prevent them in the meantime from being discovered.

[...] We could create a special label for such addition requests, and people interested in trying out new projects could look at these.

While I think adding an additional label to communicate with other contributors is a great idea to indicate which projects have not yet met the minimum lifespan requirement, I doubt that it would be discovered by "people interested in trying out new projects". In my experience, not many individuals who are not actively planning to contribute or add something to a project look at pull requests.

So adding this guideline would not filter out all occurences of low-quality or unsuitable software.

Of course, if it seemed like I implied that implementing such a guideline would completely eliminate low-quality or unsuitable software through PRs, then I am sorry. I also acknowledge that it is impossible to entirely exclude such instances, regardless of how strict the addition requirements may be. But it would (hopefully) ensure a standardized level of quality and alleviate some of the workload from the reviewers.

Considering the points raised, would it be worth discussing and considering a slightly lower timeframe, maybe something like 4 months? This could maybe strike a balance between allowing newer but promising software to be included while still ensuring a certain level of maturity and active maintenance. It could potentially address the concern of excluding valuable projects and having the list not become too "static" without compromising the overall goal of maintaining quality standards.

Let me know what you think of this.

@Rabenherz112 commented on GitHub (Jul 6, 2023): First of all, thank you nodiscc for your response and valuable insights on this topic. > Any software project you are adding to the list was first released more than 6 months ago While I highly respect your experience as the primary maintainer (please understand that I mean no disrespect), I believe that a 6-month timeframe is too strict. Although I agree that it aligns with our definition of unmaintained projects, it could exclude already excellent software from the list. For example, in the past few weeks, we have approved software such as #3849, #3857, #3921, #3798 that would not meet the new requirement. While it would only mean for these software, that they have to wait until they have matured enough (and pass the check that they are still actively maintained), it would still prevent them in the meantime from being discovered. > [...] We could create a special label for such addition requests, and people interested in trying out new projects could look at these. While I think adding an additional label to communicate with other contributors is a great idea to indicate which projects have not yet met the minimum lifespan requirement, I doubt that it would be discovered by "people interested in trying out new projects". In my experience, not many individuals who are not actively planning to contribute or add something to a project look at pull requests. > So adding this guideline would not filter out all occurences of low-quality or unsuitable software. Of course, if it seemed like I implied that implementing such a guideline would completely eliminate low-quality or unsuitable software through PRs, then I am sorry. I also acknowledge that it is impossible to entirely exclude such instances, regardless of how strict the addition requirements may be. But it would (hopefully) ensure a standardized level of quality and alleviate some of the workload from the reviewers. Considering the points raised, would it be worth discussing and considering a slightly lower timeframe, maybe something like 4 months? This could maybe strike a balance between allowing newer but promising software to be included while still ensuring a certain level of maturity and active maintenance. It could potentially address the concern of excluding valuable projects and having the list not become too "static" without compromising the overall goal of maintaining quality standards. Let me know what you think of this.

GiteaMirror commented

2025-11-26 21:06:12 -06:00

@Rabenherz112 commented on GitHub (Jul 6, 2023):

(Please note that the PRs I mentioned as examples were only selected for illustrative purposes. They may still be excluded even if the guidelines would be lower than 6 Months. So don't think too much of them.)

@Rabenherz112 commented on GitHub (Jul 6, 2023): (Please note that the PRs I mentioned as examples were only selected for illustrative purposes. They may still be excluded even if the guidelines would be lower than 6 Months. So don't think too much of them.)

GiteaMirror commented

2025-11-26 21:06:12 -06:00

@nodiscc commented on GitHub (Jul 10, 2023):

I agree. I proposed this change in https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3999

@nodiscc commented on GitHub (Jul 10, 2023): I agree. I proposed this change in https://github.com/awesome-selfhosted/awesome-selfhosted/pull/3999

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/awesome-selfhosted#4625