Tahoe Website Makeover

[fenn-cs]

The current Tahoe website is based on trac which we also use for tickets. We plan to move away from trac for ticket management and so this would leave us with fewer reason to maintain tahoe website on track. Also:

• The "website" design is stale
• It's technically an engine and we do not have control over how trac is maintained (proposal is to have new website on flask)
• We plan expand the community by increasing usage and contributions, hence the website is a good starting point for that.

[fenn-cs]

New design proposal : ​https://www.figma.com/file/S6SGqvdKs1QvHKRv8blWV8/Tahoe-lafs-Redesign?node-id=0%3A1

[maylee]

For the record, I suggested Flask because it's Python-based and fullstack, but also relatively lightweight.

[meejah]

We should write down the "why" and some goals for the new website.

For example, "maintainability" seems implicit above since _one_ reason "the design is stale" is because no current developers have easy access to change things in Trac. In the past, "make it a wiki" was one approach to maintainability (as also used by Trac and now GitHub? + GitLab?) the idea being that many people can easily edit the site -- how will this need be addressed in a new site? Taking the "wiki" motivation: how does a reader who discovers a mistake and is motivated to fix it do that? How is that fix deployed?

Do we have any interactive requirements that might lead us to have to run a _particular_ Web server? Or can it be a fully static site that could be hosted on approximately any Web-hosting infrastructure?

Does "the web site" include the documentation? Currently, there is some documentation hosted on ReadTheDocs? for example -- how does that fit in?

[meejah]

p.s. nothing against Flask at all (I've used it in my sites) but a fully static web-site can use any web-server at all essentially which may make things easier.

My site ​https://meejah.ca is served directly from Git blobs via a Twisted web server -- this means that "how to deploy" is very easy: I just git push the new or edited content. I'm not sure if that's appropriate here, but something to think about (it's thus _not_ a "static web site" and does need to run particular software on an internet-connected machine).

A fully static website could answer the "how to deploy" question by using a CI pipeline to build and push the content to the static host. That's kind-of how ReadTheDocs? works; a WebHook? tells their service that there's new code and it builds and deploys it.

From a "user" perspective, I think it's important to have a small amount of time between "edit the docs" and seeing them live on the internet. This encourages more participation in the project. It can be discouraging to add some documentation only to see it sit in a Git repo and _not_ get deployed for weeks/months.

[fenn-cs]

"Why?"

The most important why is that the community thinks one is needed, why does the community think so? It's a collective responsibility. I did put a couple motivations why a new website might be required from my point of view.

Just like you talked about "maintainability", if anyone knows of other "why's" here is a good place to put it as those would help in the shaping of the requirements or functionalities of the website.

Requirements

The requirements are implied by the design which was inspired by how this organization currently uses trac.

_one_ reason "the design is stale" is because no current developers have easy access to change things in Trac.

The above statement seems to suggest that Trac works well "except that it's not maintained" and so it is a good starting point.

Moreover the website has been designed a showcase for Tahoe that show basic information that we want visitors to find immediately they on the website.

Hosting and deployment

Unless there's a huge bottleneck with hosting non-static applications there's no need to require that website is static. The functions of the website should speak, for example it I envisage a blog/news section. (Some static site generators can power blogs too).

There are all kinds of hosting platforms with stand procedures on hosting various kinds of applications on different stacks like LAMP, MERN, whatever.

Unless we are working with a totally strange and outlandish stack, I think hosting is not top our our list of worries.

Documentation

The website is at least according to my understanding some sort of showcase and "marketing" tool, the wiki is not part of this and would only be linked.

About having multiple locations where documentation could be found, that is not a good thing and the website should not be shaped around that bottleneck, however at best we would have a single link leading to "the wiki" at worst links to all the wikis.

IF we move to gitlab, the wiki's can live there with the code.

The design is open for updates, modification, corrections whatever... It was only head start.