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?

[kana800]

Most users will not want this (including me, I hate when websites do this - let me manage my tabs). You can open links in new tabs quite simply, using ctrl+click or middle-click, or two-finger-tap on touchpads, or right-click -> open in new tab, or configure your browser to always open links in new tabs...

Understandable : ) , I will configure it on my browser

[zerebos]

Just wanted to drop this in here... I personally much prefer the markdown version of the list over the html version because (to me) the html version wastes a lot of space and makes it harder to see more than just a couple projects a once. So I have a bit of a design proposal to change that but I didn't want to just try to go implement it without gathering thoughts from you guys here.

Currently, there are 3 lines of "tags" for each project. The first line is really moreso buttons, the second line is tags, the third is a category tag. My proposal would be to move the button-tags to be a part of the heading itself, and collapse the rest of the tags into a single line. I think having the tags on a single line is okay and does not hurt visibility or the ability to distinguish them because they are already color-coded and have their own icons. I would also personally adjust the font-size and padding a bit. Here's how it might look:

In the screenshot, Adguard Home and admidio are untouched. Aimeos is just making the layout adjustments I described with no changes to the styling. Adminer changes both the layout and applies the font-size and padding changes I described. To me, that makes better use of the space and it's still easy to see and distinguish everything. The tags can even wrap to a new line if many are added and it will still look fine.

What are your thoughts on this?

The only other ideas I had to improve the readability would be to do a media query for larger screens/resolutions and increase the width of .content, it's quite small on my screen/resolution. Or, to reduce the saturation of the tag colors because currently they pop a lot and draw the eye away quite heavily from the actual title/description of each project.

[Rabenherz112]

I personally agree. When examining your example, it becomes apparent that it optimizes space utilization quite effectively. Additionally, it has the nice side effect of providing clearer delineation for the buttons, used for accessing the project's additional information (Website, Source Code, Demo, and Client), separating them from the rest of the informational labels

So overall I would also like to see such a design change (like done in your example with Aimeos)

[nodiscc]

• move the button-tags to be a part of the heading itself
• collapse the rest of the tags into a single line
• adjust the font-size and padding a bit

I agree with the suggested changes.

They should be implemented in https://github.com/nodiscc/hecat/blob/master/hecat/exporters/markdown_multipage.py. Keep in mind that the website should remain usable on small displays (phones). I am unlikely to find the time to work on this, but would accept a pull request that implements these changes (ideally, one change by PR). Website generation can be tested by cloning https://github.com/nodiscc/hecat, and running make clone_awesome_selfhosted test_export_awesome_selfhosted_html inside the repository.

[zerebos]

Awesome! I should hopefully have some time this week to work on this, but I figured I would check-in before opening any PR(s). I'll definitely make sure that any changes I make will remain accessible to all resolutions.

[kokomo123]

It seems that some github action runs need to be rerunned due to them being cancelled by the latest action being pushed through due to some hierarchy that's implied.

does the update-metadata job solve these kinds of issues? just confirming

[nodiscc]

some github action runs need to be rerunned

Nope, the cancelled workflows are caused by a more recent commit being pushed to master before the build for the previous commit was completed. See concurrency: [1].

We don't want concurrent build jobs on the same branch, only the latest revision should be built - if a workflow is already running when a new commit is pushed to master, it is cancelled, and a new workflow run starts for the latest commit instead.

Edit: example workflow status page for a cancelled build:

[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