Add "What makes this submission awesome?" to PR template

[PrplHaz4]

Lots of abandoned or questionably awesome things showing up lately - this question should be easy enough to answer for anything making it on here and provides that first view of why it stands out from someone that uses it....

Thank you for taking the time to work on a PR for Awesome-Selfhosted!

To ensure your PR is dealt with swiftly please check the following:

• Submit one item per pull request. This eases reviewing and speeds up inclusion.
• Format your submission as follows, where Demo and Clients are optional.
  Do not add a duplicate Source code link if it is the same as the main link.
  Keep the short description under 250 characters and use sentence case
  for it, even if the project's webpage or readme uses another capitalisation
  such as title case, all caps, small caps or all lowercase.
  Demo links should only be used for interactive demos, i.e. not video demonstrations.
  - [Name](http://homepage/) - Short description, under 250 characters, sentence case. ([Demo](http://url.to/demo), [Source Code](http://url.of/source/code), [Clients](https://url.to/list/of/related/clients-or-apps)) `License` `Language`
• Additions that depend on proprietary services outside the user's control must be marked ⚠.
  - [Name](http://homepage/) `⚠` - Short description, under 250 characters, sentence case. ([Demo](http://url.to/demo), [Source Code](http://url.of/source/code), [Clients](https://url.to/list/of/related/clients-or-apps)) `License` `Language`
• Additions that are not Free software must be added to non-free.md and have the license set to ⊘ Proprietary
• Additions are inserted preserving alphabetical order.
• Additions are not already listed at any of awesome-sysadmin, awesome-analytics, staticgen.com, staticsitegenerators.net.
• The Language tag is the main server-side requirement for the software. Don't include frameworks or specific dialects.
• Any license you add is in our list of licenses.
• You have searched the repository for any relevant issues or PRs, including closed ones.
• Any category you are creating has the minimum requirement of 3 items.
  If not, your addition may be inserted into Misc/Other.
• Any software project you are adding to the list is actively maintained.
• The pull request title is informative, unlike "Update README.md".
  Suggested titles: "Add aaa to bbb" for adding software aaa to section bbb,
  "Remove aaa from bbb" for removing, "Fix license for aaa", etc.

[Ki-er]

I have been thinking of opening a PR like this, we will wait for nodiscc's feedback! I like this idea however id place this at the top under a form like below:

# Awesome Self Hosted
## Source Code link:

## Is this related to an issue?
<-- Add Closes #issue-number -->

## Why is this awesome?

---
<--Checklist-->

[nodiscc]

How does this improve the list or contribution process?

For me the awesome thing about software listed here, is that it does what the description says, and is Free Software. If you want to discuss adding quality requirements for new entries, please open a dedicated issue. But I think this just makes contributing unnecessarily harder. This is what used to be done on https://github.com/awesome-foss/awesome-sysadmin/pulls?q=is%3Apr+is%3Aclosed and I don't think it helped at all.

[PrplHaz4]

How does this improve the list or contribution process?

For me the awesome thing about software listed here, is that it does what the description says, and is Free Software. If you want to discuss adding quality requirements for new entries, please open a dedicated issue. But I think this just makes contributing unnecessarily harder. This is what used to be done on https://github.com/awesome-foss/awesome-sysadmin/pulls?q=is%3Apr+is%3Aclosed and I don't think it helped at all.

To me, the low barrier to entry is exactly the problem. Since this list is "awesome" I'd expect the software on it to be at least a basic level of functional, maintained and reliable.

To me, this list is becoming a copy of selfhosted reddit topics, many of which never see the light of day twice. If you can't easily identify one or two things that makes the product you're adding "awesome" (or at least differentiated in some way), then maybe it isn't.

I'm not familiar with the issues on awesome-sysadmin, and don't see a template there to compare to.

[nodiscc]

I'd expect the software on it to be at least a basic level of functional, maintained and reliable.

I have about the same expectation, do you have specific examples that do not fit these basic requirements?

Edit: being maintained is already a requirement, automatic checks at https://github.com/awesome-selfhosted/awesome-selfhosted-data will further simplify finding unmaintained projects. Usually projects being added are maintained at the time of the addition.

Edit2: usually we make sure setup instructions are available, which implies the software should at least install and run. If you have objective quality guidelines to suggest your advice is welcome, but I'm pretty sure just adding Why is this awesome? to the template won't help. Should we explicitly require install documentation?

Edit3: "it doesn't fit my use case" is not a valid reason to reject software.

[Ki-er]

I only suggested the above changes, Source Code link and Is this related to an issue? as this will make it easier for reviewing and keeping stale issues from remaining open however any more work that the user has to do will just make it harder to contribute, heck, some people dont even fill in the checklist 😆

basic level of functional, maintained and reliable.

Both automation and manual checks are being carried out to make sure that projects are 'awesome'

[Ki-er]

Should we explicitly require install documentation?

Id say yes but to a certain extent, some installation documentation should be required for installing from source as users may not understand how to install software with many steps. Docker installation guides are nice but they arent required as a simple docker command can be run.

[nodiscc]

Related, there is ongoing discussion at awesome-foss/awesome-sysadmin#357 to clarify what would constitute "good quality" guidelines.