Libretime: Cannot self-host docs

[paddatrapper]

The documentation uses Jekyll to build the static website, however it requires files that are not in the repo to build. We have a skeleton script to build them here, but it fails due to missing files. We should look at finding the required theming and build scripts, and including them in the repo

[zklosko]

I do want to look into updating the Help docs inside the LibreTime interface itself. @paddatrapper @Robbt Do you guys know where those are located?

[paddatrapper]

They seem to just link to the website (and now to links that are broken e.g. http://libretime.org/faq/). As where they are in the code I'm not sure. Either the HTML or PHP in airtime_mvc

[zklosko]

Just fixed it in #1050

[zklosko]

I'm working on it.

Would it be better to have our site hosted under a gh-pages branch? It can still be pointed towards our domain without having users download the site on each clone.

[paddatrapper]

So there are two trains of thought here:

1. Documentation should live with the code. This makes updating docs with changes in the code easy to enforce.
2. The website should be in its own repo (libretime.github.io, which is currently just made private to make the docs here work on libretime.org).

I think if we are building an entire site, that should be in its own repo. Maybe there is some way of keeping the specific docs with the code? But it is probably not necessary, considering the docs are largely user-facing and are not describing API/programming interface. however, they would need concentrated effort to ensure that they are up to date for each release

[paddatrapper]

@Robbt thoughts on keeping the site here or moving it to libretime.github.io repo?

[Robbt]

Hmm I'm neutral on this. If we are going to separate this then I thinks a separate repo is the right choice vs. a branch. How large is the docs site ? If it isn't too large then keeping it connected seems OK. Being able to do doc commits as part of PRs is nice. Not sure what the benefit of moving it is other than it making our repo smaller.

[paddatrapper]

Looking at the PR , the site is +69,159 −1,554 in 1 513 files

[zklosko]

I am working on cleaning up duplicate pages and screenshots, so if we did want to keep the site within the repo we could certainly do it.

One thing I do want to do is to make a better case for why LibreTime should be used, especially during COVID-19. All of your efforts have really made us pull out less hair, which is just so appreciated. I can't put it into words. It would be awesome to get this work into other stations so that they are able to stay alive during the pandemic.

[gusaus]

It would be awesome to get this work into other stations so that they are able to stay alive during the pandemic.

@zklosko The work you're doing to complete what @ned-kelly started will make it much easier to get the word out to stations and contributors.

Your station has also provided a great deal of inspiration for functionality we'd like to include in a WordPress MVP for stations and podcasters. https://github.com/OpenProducer/openproducer-platform/issues/18#issuecomment-631800936

I think the combo of marketing + including LibreTime into an easy to manage/extendable platform will really help get the word and code out to stations and podcasters.

Also opens up a lot of possibilities for cross-project collaboration.

[zklosko]

@gusaus Well, we're honored :)

I posted this to the thread you mentioned

I should definitely clarify that WRIR is only using LibreTime as a playout engine. We broadcast on both FM and internet and have completely separate systems working for each that are completely independent from our LibreTime instance.

[gusaus]

@zklosko Off topic for this issue (thanks to me), but I think _how_ stations like yours are using LibreTime and other OSS tools could make for a great case study and inspiration for other community media and LPFM stations.

[zklosko]

This can be closed due to the merging of #1053.