General Discussion

[Rabenherz112]

To avoid cluttering the Issues Tab with general discussions, questions, or other topics, I created a separate space to facilitate easier discussions on various subjects.

[Rabenherz112]

How exactly do you plan to handle the non-free page?
As far as I can see in the current preview (https://nodiscc.github.io/awesome-selfhosted-html-preview/#) there is no direct button. While these pages stay for now on GitHub as a Markdown file, or do you plan to also add another page for non-free entries?

What exactly is the Date meant to represent? I thought it was the initial addition time, but that didn't make any sense. Is this the latest update of the software? If yes, explaining that at the start page would probably make sense.

The Author Button (https://nodiscc.github.io/awesome-selfhosted-html-preview/#authors) downloads atm the Author File. O_O

Can't clone the repo normally, thanks to https://github.com/awesome-selfhosted/awesome-selfhosted-data/blob/master/software/diaspora*.yml

git clone https://github.com/awesome-selfhosted/awesome-selfhosted-data
Cloning into 'awesome-selfhosted-data'...
remote: Enumerating objects: 83823, done.
remote: Counting objects: 100% (83823/83823), done.
remote: Compressing objects: 100% (4599/4599), done.
remote: Total 83823 (delta 80702), reused 82271 (delta 79155), pack-reused 0
Receiving objects: 100% (83823/83823), 6.73 MiB | 21.33 MiB/s, done.
Resolving deltas: 100% (80702/80702), done.
error: invalid path 'software/diaspora*.yml'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'

[nodiscc]

How exactly do you plan to handle the non-free page? As far as I can see in the current preview (https://nodiscc.github.io/awesome-selfhosted-html-preview/#) there is no direct button. While these pages stay for now on GitHub as a Markdown file

The non-free page will only be rendered in the markdown-based list (there is a link to it in the header of https://nodiscc.github.io/awesome-selfhosted-html-preview). I don't want to mix Free/non-Free items, and the only way to keep them clearly separated with the way the HTML site is built, would essentially be to duplicate the site, or duplicate pages. The markdown version will keep being updated, so this information stays available, but non-Free software has never been a major focus for this project (the project description itself states so). It is listed as a convenience, at the request of a few contributors/users.

What exactly is the Date meant to represent? Is this the latest update of the software?

Yes. Looking at it now, I can see this is not very clear...

If yes, explaining that at the start page would probably make sense.

What about using a tooltip when hovering the mouse over this span instead? You can see this mechanism is already used when hovering the Anti-features spans:

The tooltip would have the text Date of last update This would prevent adding too much information on-screen. Maybe dates rendered in range/red should have the tooltip Date of last update - this project has not received any update since {6,12} months! to clarify the purpose of the different background color.

The Author Button (https://nodiscc.github.io/awesome-selfhosted-html-preview/#authors) downloads atm the Author File.

Thanks for noticing, I will have a solution soon.

Can't clone the repo normally, thanks to diaspora*.yml

Which OS? Is that on Windows? If so, as a workaround, you could try to change the value of your core.protectNFTS git setting to false (git config --user core.protectNTFS false). But I think the * characted should be trimmed during import in https://github.com/nodiscc/hecat/blob/master/hecat/utils.py#L15, for consistence - I will look into it. However I cannot guarantee that another contributor won't commit a filename that is incompatible with NTFS in the future.

[Rabenherz112]

The non-free page will only be rendered in the markdown-based list (there is a link to it in the header of https://nodiscc.github.io/awesome-selfhosted-html-preview).

Ah, I completely missed that.

What about using a tooltip when hovering the mouse over the date? The tooltip would have the text 'Date of last update' or when rendered in range/red should have the tooltip 'Date of last update - this project has not received any update since {6,12} months!'

It seems like a promising suggestion, especially considering the existing system for Anti-features. Additionally, altering the text when it turns orange/red would help users comprehend the reason for the different colours. However, I'm slightly unsure about how many users will actually notice this change. Personally, while scrolling through the list, I wasn't aware that the anti-features tag had tooltips, as none of the other tags do. The idea of having tooltips for this specific tag didn't occur to me at the time.

Is that on Windows? If so, you can try the workaround.

Indeed, it is Windows. I came across the workaround you mentioned online, but I must admit I'm not fond of disabling this protection.

But I think the * character should be trimmed during import. However I cannot guarantee that another contributor won't commit a filename that is incompatible with NTFS in the future

That would be nice. I comprehend that it's something that might happen again in the future, and if it does, we'll likely need to deal with it once more. From what I can tell, occurrences like this are relatively rare.

[nodiscc]

tooltip when hovering the mouse over the date

done nodiscc/hecat@3c3d286

when rendered in orange/red should have the tooltip 'Date of last update - this project has not received any update since {6,12} months!'

Will be done later, the tooltip is sufficient for now.

Can't clone the repo normally, thanks to diaspora*.yml, the * character should be trimmed during import

fixed nodiscc/hecat@60760cd

The Author Button downloads atm the Author File

fixed nodiscc/hecat@fefbd7c, 2322f5c

-> preview updated https://nodiscc.github.io/awesome-selfhosted-html-preview/

[Rabenherz112]

Now this is annoying; I still have issues when I am trying to clone the repo, now however, because of :.
I will just use the fix to continue testing, so see this only as a fyi.

[Rabenherz112]

Could you please take a moment to check whether PR #36 was created by me? I want to make sure I didn't misunderstand anything (and understand who that all should work). I got a little confused with the depends_3rdparty field, as it is set to true by default, but the description says it is false by default.

By the way, I must admit that creating a PR is much easier now. The provided template makes the process a lot smoother. 👍

[nodiscc]

I still have issues when I am trying to clone the repo, now however, because of :

Should be fixed in 59ed57f (https://github.com/nodiscc/hecat/releases/tag/1.0.1) + 30fa8ee (reimport data)

Could you please take a moment to check whether PR #36 was created by me?

Look good, all syntax checks passing as well (https://github.com/awesome-selfhosted/awesome-selfhosted-data/actions/runs/5648100392/job/15299667081?pr=36)

I got a little confused with the depends_3rdparty field, as it is set to true by default, but the description says it is false by default.

It is shown in the template with the value true, however if the software does not depend on 3rd party services, this field should be removed (as it defaults to false) - this is what you did and it is correct. But you are right that it can be confusing, maybe the template could make this more explicit.

Thanks

[nodiscc]

Merged, should be built in a few moments (https://github.com/awesome-selfhosted/awesome-selfhosted-data/actions/runs/5648280194/job/15300165745) and pushed to https://github.com/nodiscc/awesome-selfhosted and https://nodiscc.github.io/awesome-selfhosted-html-preview/

[nodiscc]

• https://github.com/nodiscc/awesome-selfhosted#communication---email---mail-delivery-agents -> OK
• https://nodiscc.github.io/awesome-selfhosted-html-preview/#james -> OK

After the next automatic metadata update tonight (https://github.com/awesome-selfhosted/awesome-selfhosted-data/actions/workflows/daily-update-metadata.yml), we should see the updated stars count/last update date on the HTML site (actually I think there is a small bug/corner case, and we won't - but let's check tomorrow)

[Rabenherz112]

Should be fixed in 59ed57f (https://github.com/nodiscc/hecat/releases/tag/1.0.1) + 30fa8ee (reimport data)

Works like a charm, thanks!

Merged, should be built in a few moments

Looks also good, also good to know that everything was good in the PR itself.
Also, that's super cool that the changes are also applied to the markdown version like that!

actually I think there is a small bug/corner case, and we won't

😮

After implementing the last changes related to the Author File and other aspects, the website looks even better. I couldn't detect any other bugs. Again, you did an outstanding job! The only question I have is whether it was a deliberate decision to display ? for Projects where the Metadata cannot be retrieved (Projects not from GitHub), instead of simply not showing the tag at all?

[nodiscc]

whether it was a deliberate decision to display ? for Projects where the Metadata cannot be retrieved (Projects not from GitHub), instead of simply not showing the tag

Yes it was deliberate, it clearly shows that we are missing this information - it can still be added manually, or automation tools can be improved to retrieve it for non-Github projects.

[nodiscc]

Moved from awesome-selfhosted/awesome-selfhosted#4027

What are your plans for handling the migration itself?

• setup CI in https://github.com/awesome-selfhosted/awesome-selfhosted-data to push the markdown version to a
  temporary/testing repo (https://github.com/awesome-selfhosted/awesome-selfhosted-testing?)
• setup CI in https://github.com/awesome-selfhosted/awesome-selfhosted-data to push the HTML version to a temporary/testing repo (https://github.com/nodiscc/awesome-selfhosted-html-preview), use github pages to serve the preview website
• test and simplify contribution process, test automatic generation/automation/CI/CD
• get a cheap VPS (or possibly reuse my existing VPS), setup a static site virtualhost, setup cron to pull the new version of the HTML repo every hour or so
• get a domain name, point it at the VPS (or alternatively use github pages for hosting [1])
• do a final import of the original awesome-selfhosted markdown to this repository (make import update_metadata)
• transfer https://github.com/nodiscc/awesome-selfhosted-html-preview to https://github.com/awesome-selfhosted/awesome-selfhosted-html, update VPS cron job accordingly
• disable maintenance mode on the VPS/virtualhost (https://gitlab.com/nodiscc/toolbox/-/tree/master/ARCHIVE/ANSIBLE-COLLECTION/roles/awesome_selfhosted_html)
• switch https://github.com/awesome-selfhosted/awesome-selfhosted-testing for https://github.com/awesome-selfhosted/awesome-selfhosted as target for the markdown page deployment
• update https://github.com/awesome-selfhosted/awesome-selfhosted-data/blob/master/markdown/header.md with links to both markdown and HTML versions of the list markdown/header: add links to HTML and markdown versions #54
• update https://github.com/awesome-selfhosted/awesome-selfhosted/blob/master/.github/CONTRIBUTING.md and https://github.com/awesome-selfhosted/awesome-selfhosted/blob/master/.github/PULL_REQUEST_TEMPLATE.md to point to the new contribution process on https://github.com/awesome-selfhosted/awesome-selfhosted-data move issue tracking/contribution workflows/project management to awesome-selfhosted-data awesome-selfhosted#4083
• update the link in the https://github.com/awesome-selfhosted/awesome-selfhosted project description/sidebar to point to the HTML site
• post a release announcement on https://github.com/awesome-selfhosted/awesome-selfhosted/releases
• migrate open issues and PRs from https://github.com/awesome-selfhosted/awesome-selfhosted/issues to awesome-selfhosted-data manually (or ask the original poster to resubmit)
• start maintaining/curating https://github.com/awesome-selfhosted/awesome-selfhosted-data

The website is deployed using this ansible role and xsrv

[nodiscc]

https://awesome-selfhosted.net is now live.

Please check the release announcement for more details.

[Rabenherz112]

@nodiscc Congrats on the release of the Website and migration to the new repo. 🎉🎉

[Rabenherz112]

Also, if I spot it correctly, aren't we at the moment still missing the needs to mature, feedback needed and reviewers wanted labels?

[kokomo123]

Thanks for the explanation then, so it'll still all be merged to the website. 💯

[Rabenherz112]

I noticed a recurring pattern in the project descriptions during my recent search on the website for a specific piece of software. Many include terms like 'open-source', 'free', 'self-hosted' and so forth, which feels redundant. This is an open-source list; of course, projects listed here will be open-source and, therefore, also free to use. Additionally, some projects reiterate their name in the description, for instance, 'XYZ is ...'

Here's an example for clarity:

+ Good Example
Feedpushr
An RSS aggregator with the capability to transform and forward articles to various outputs. It's a single binary, extendable through plugins.

- Bad Example
Metabase
An easy, open-source method for everyone in your company to ask questions and learn from data.

We have previously re-written similar descriptions (refer to #419, #423, etc.), but we haven't formally documented this practice or discussed it (at least, I couldn't find any issue regarding this; feel free to point me to the discussion if he had one before).

I'm interested in knowing your perspective on this matter. In my opinion, software descriptions should focus more on accurately defining the project rather than promotional language. This would include avoiding terms like "awesome", "free", "open-source", "easy", etc., unless they add substantial value to the description. What are your thoughts?

[nodiscc]

Additionally, some projects reiterate their name in the description, for instance, 'XYZ is ...'

I agree with this, and it has been mentioned in #408 (comment):

There could be some sort of guideline about how to phrase descriptions too (for example Minimalist text adventure game would be preferred to A minimalist text adventure game or $PROJECT is a minimalist text adventure game)

Many include terms like 'open-source', 'free', 'self-hosted' and so forth, which feels redundant

Also agree.

What we need is an additional section Other guidelines or similar in https://github.com/awesome-selfhosted/awesome-selfhosted-data/blob/master/CONTRIBUTING.md, which lists lists these "soft" guidelines - I'm not sure we should add these directly to https://github.com/awesome-selfhosted/awesome-selfhosted-data/blob/master/.github/PULL_REQUEST_TEMPLATE.md, as the list of requirements could become overwhelming for potential contributors, and make the PR checklist less effective.

[Rabenherz112]

Should we add this to the Pull request template

I don't think this would be useful. These guidelines are only relevant for a small fraction of additions but would significantly increase the number of requirements, resulting in overly complex checks for people who want to add new software.

I would align more with your suggested approach of introducing an extra section in the Contributing, or we could consider a separate 'review' document. This could detail these specific requirements, leaving it to the reviewer's discretion to identify and address any additional requirements. If created in a tutorial-like format, it could also assist new users who want to review PRs, by having one central place for all that information without the need to search through numerous unrelated issues in both the current and older repositories.

[nodiscc]

I would align more with your suggested approach of introducing an extra section in the Contributing

Proposed changes in #500

or we could consider a separate 'review' document.

• I think we should add another section Reviewing additions to CONTRIBUTING.md and mention that it is an effective way to contribute (I am extremely grateful to people who help with this task). This boils down to:
• ensuring that the syntax is conform (which is indicated by the results of automated checks)
• ensuring that the project is not already listed on awesome-sysadmin, staticgen.com, staticsitegenerators.net, dbdb.io
• ensuring that the software is actually relevant to the categories/tags it was added to (refer to the tags descriptions for the actual purpose of each tag)
• Ensuring that the list of platforms actually matches the provided installation instructions
• Ensuring that the license actually matches the project's license, and that it does not have hidden dependencies on non-Free/closed-source components or arbitrary restrictions that are aginst the spirit of the DFSG or Open-Source definition
• Ensuring that the software actually provides network services and web applications which can be hosted on your own server(s) (e.g. purely local command-line/desktop/mobile applications are out of scope)
• Ensuring that the first release is actually 4 months old
• I probably forgot some things

[nodiscc]

For the first time, automated checks for unmaintained projects are passing .

Thanks to everyone involved in cleaning up the list.

[nodiscc]

• Another item that would speed up reviews, is having prepared reply templates for common problems. A frequent cause for additions being rejected, is the project not having any releases yet.

Here is a draft for replying to such PRs. We should probably refine it a bit based on previous hand-crafted replies.

Hi, thanks for your contribution.

However, there are no tagged releases for this project. Our guidelines require that _ Any software project you are adding was first released more than 4 months ago._ I encourage you to create a release now and/or a simple changelog that will help users keep track of changes in the software (especially breaking changes or changes requiring configuration tweaks), and will allow administrators to install a known working, unchanging version (as opposed to always installing the latest development version).

Once this is done, the project may be resubmitted to awesome-selfhosted when the first release reaches the age of 4 months.

Thanks for understanding, and good luck with this project.

[Rabenherz112]

I agree with having reply templates for common problems. This wouldn't only speed up reviews but also ensure consistency across reviews from different people. But where should such templates be stored?

Here is a Template that I think is good to use, if there is already a release, but it is not yet 4 months old (and it is a PR)

Hi, thanks for your contribution.

Currently, this project has a release, but it is not yet 4 months old. Our guidelines require that _Any software project you are adding was first released more than 4 months ago_. This count initiates only after a release has been created to ensure users need not rely on the latest development version to use the project.

I'll go ahead and close it for now to keep the PR section focused on active tasks. Once the first release is four months old, feel free to resubmit it to awesome-selfhosted, or you can create an issue instead (we don't close issues; we just tag them to indicate they need to mature).

Thanks for understanding, and good luck with this project.

Also here is nodiscc template again, just raw for easier copy-paste (and some smaller tweaks, I did to it)

Hi, thanks for your contribution.

Currently, this project doesn't have any tagged releases. Our guidelines require that _Any software project you are adding was first released more than 4 months ago._ This count initiates only after a release has been created to ensure users need not rely on the latest development version to use the project.

We also recommend maintaining a simple [changelog](https://keepachangelog.com) that will help users in tracking software changes, particularly those that are breaking changes or require configuration modifications.

Once a release has been created and the project has matured for at least 4 months, the project may be resubmitted to awesome-selfhosted.

Thanks for understanding, and good luck with this project.

Other Ideas for template messages:

• Project has releases but the first release is not 4 months old (this could be modified from the template for missing releases)
• Project isn't an end-user application with a web interface (SDK, command-line tool, and so on)
• Project is already featured on awesome-sysadmin or one of the other lists

[Ki-er]

Been a while since I've done prs for this list due to other commitments but Im back now!

I agree with the consistent messages, the only thing is that we can make sure is that they don't come across as to robotic and unapproachable.

[nodiscc]

It is very kind of some people to monitor the availability of https://awesome-selfhosted.net/ for me, however please refrain to issue full GET requests on the main page every few minutes because that will amount to a considerable amount of traffic, and will get flagged as abuse and result in a ban. HEAD requests should be fine, but rest assured that monitoring and alerting are already in place on my side. Thanks

awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:16:54:32 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:16:59:32 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:17:04:33 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:17:09:33 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:17:14:33 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:17:19:34 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"
awesome-selfhosted.net:443 89.xxx.xxx.xxx - - [21/Jan/2024:17:24:34 +0100] "GET / HTTP/1.1" 200 6368484 "-" "Uptime-Kuma/1.23.11"

[nodiscc]

The VPS hosting https://awesome-selfhosted.net/ will undergo a maintenance/migration operation by the hosting provider (Ionos) somewhere between 15/04/2024 and 10/05/2024. The website will be unavailable during the maintenance. Further details/ETA will be provided when the maintenance is about to start.

[kokomo123]

#837 (comment)
I think we should document all the precedents we have set just for reference, as I forgot about this one, otherwise eh, at least we have you nodiscc to remember precedents l dont usually remember. rip

[TheGiraffe3]

Pull request merge can be slow sometimes. It seems that @nodiscc is the only maintainer at the moment. Is this correct?
I would nominate @Rabenherz112 (the author of this issue, who currently has triage access) or one of the other respected reviewers to receive merge permissions, if they are alright with it.
I don't blame anyone for not having enough time; but if it's possible to add time to the overall maintainer time...

[Rabenherz112]

I found that Github has finally added a saved replies feature that can be used functionally via the slash command. This might be quite useful for a few of us (we no longer need to search the templates and copy and paste them into the review).

When you go into your settings there is a new section named 'Saved replies' where you can add templates.

Edit:
Also on this note, I created a small PowerShell script that allowed me to find duplicate software entries. With the help of this script, I also did my recent PRs (#1006, #1031). Thought I might share this as well if anyone is interested in it.
https://gist.github.com/Rabenherz112/025bb71758279719710ceb2664c381e9

[kokomo123]

I will definitely set this up, thank you raben!

[Rabenherz112]

How do we handle software contributions that merely port an existing application to another system (e.g., Dockerization), especially when the repository is neither owned nor controlled by the original creator?

I am asking because I just saw #1027 which kinda goes in that direction

[nodiscc]

How do we handle software contributions that merely port an existing application to another system (e.g., Dockerization)

I don't think we should approve these, it will open the gates to a flood of custom builds, third-party docker images... a quick search returns at least 2 other docker image projects for Anki [1] [2], so I'd prefer if these solutions could be considered first:

• contributing the OCI image build procedure to the upstream project (Dockerfile, documentation)... Anki devs were apparently open to contributions in the issue linked above
• linking to the third-party docker image build from the upstream's project documentation

I will have a look at #1027

[Rabenherz112]

I don't think we should approve these

Agreed

flood of custom builds, third-party docker images

Agreed as well. Another potential issue is the risk of a bad actor cloning popular software, creating a Docker image, injecting malicious code, and submitting it to us. While unrelated to the mentioned PR, it's well-known that malicious Docker images for popular software exist. I also don't think we have the time or resources to thoroughly vet every submission to ensure the build process is entirely trustworthy.

[armchairancap]

I would align more with your suggested approach of introducing an extra section in the Contributing, or we could consider a separate 'review' document.

About that - some of the (completed) PRs seem to be waiting for more reviewers for over 30 days. (Disclosure: my PR happens to be one such PR (hence this comment), but I imagine other contributors in similar situation must be wondering as well.)

Rather than ask in the PR, I tried to figure out what reviewers wanted means and how a reviewer decides to go to PRs and take a look. The how-to-contribute doco doesn't explain that, though.

I don't mind waiting, but I do wonder how does a PR author "motivate" reviews of PRs that are "ready to go"?