redirect tiaas to the other website

[bgruening]

as requested by Bea

[gmauro]

Doesn't work

[gmauro]

You are cutting off several other URLs

[hexylena]

This'll have to be updated every time we add URLs to tiaas which is really cumbersome. Is there any chance that doing it the other way could work for you @beatrizserrano? Is it a concern of updating the tiaas homepage or so that I could make easier?

[beatrizserrano]

No, my only concern was that we had 2 pages and were not sync, so that was confusing for the users. In which direction the redirect should work, no clue :)

[hexylena]

ahh cool :) Then I'm 100% for redirecting to tiaas, then we can keep that as the "main landing page" and put all of the updates there, and then every other server gets those updates as well which I think would be an improvement.

[beatrizserrano]

Now that TIaaS is available globally, we can make this page a bit more generic for the other servers to reuse. Here's the suggestion:

1. Create a generic page in the Hub with all the common information (how the service works, etc.): tiaas_general.md
2. That page redirects users to the particular server with more specific information (e.g. how to apply for the resources in different domains like EU, AU, US, ...): tiaas_domain.md
3. We render those 2 files together and display them in each domain.

File 1 will live in galaxy-hub, File 2 will live probably there as well (needs to be discussed but might be a subfolder if we unify the hubs) or in usegalaxy-eu/website. So I guess that the current usegalaxy.eu/tiaas won't be needed any more. Does this make sense?

[hexylena]

Yay a path forward!

I think File 2 would be best located inside tiaas itself, so everyone can customise their page/requirements there themselves without needing to go through the hub. I don't think it should be a page within individual or unified hubs, I feel it's a bit disconnected from the service and might be hard to locate when an admin wants to make an update?

Otherwise I like this plan. usegalaxy.eu/tiaas would then be 'file 2'

[beatrizserrano]

Yeah, so to avoid the disconnection, having some documentation in the technical repo would be enough I think. The outreach or user-facing side I think it's better to keep all together in the hub. I guess that the question is: who will update the explanation to users, the admin, or the outreach person?

[hexylena]

Could you elaborate what you mean by 'technical repo'?

I think surely galaxy outreach won't be responsible for things like "What are the requirements to register for this site's tiaas", right? That's the responsibility of admins + site-specific outreach folks. Therefore, that belongs in their configuration of how they deploy TIaaS, not something that you should need to care for or so?

[beatrizserrano]

Could you elaborate what you mean by 'technical repo'?

I mean that to modify usegalaxy.eu/tiaas (or 'file 2') we would need to modify the page in the tiaas2 repo, is that correct?

I think surely galaxy outreach won't be responsible for things like "What are the requirements to register for this site's tiaas", right? That's the responsibility of admins + site-specific outreach folks. Therefore, that belongs in their configuration of how they deploy TIaaS, not something that you should need to care for or so?

Yes, so I see 2 different things here: one relevant for admins (that should be located in tiaas repo) and another one for users (when I need to reply to the same question by email 3 times means that something can be explained better in the page, so I think it's better that this part lives in the hub).

[hexylena]

I mean that to modify usegalaxy.eu/tiaas (or 'file 2') we would need to modify the page in the tiaas2 repo, is that correct?

Jein :) it could be templated! We already template a lot of content in there as part of the tiaas configuration/deployment process. We could just set a variable and pass it to the 'markdownify' filter and have it rendered as part of that page, so local admins would really have control over their tiaas pages without needing to host that somewhere else. (I want and will implement this in any case, because I need it for the TIaaS deployment inside avans which will not be advertised/available outside)

(when I need to reply to the same question by email 3 times means that something can be explained better in the page, so I think it's better that this part lives in the hub).

yes that makes sense!