Living issue: Website Launch Plan

[stockholmux]

Okay folks! Last night the command reference was merged, but there is a ton of work to do to even get to an MVP.

These are in the most logical order I can muster right now. But if you have expertise on something down list, do it.

How to pitch in

If you want to take one of these items, check if there is an issue first. If there is an unclaimed issue, claim it. If there is no issue, create one and tag this issue.

Some thing are hard to do without specific info (i.e. talking to the LF), so don't worry if you can't accomplish something or can't accomplish it right now.

If you think there is something missing, ask below and I'm glad to discuss it.

Todo

Meta:

• More accurate instructions on how to build the site locally on README
• Paragraph on how command reference is built on README

Infrastructure:

• move from submodules to GitHub Actions to pull in valkey-io/valkey-docs and valkey-io/valkey

Template:

• Download / Get Valkey page: (/download/ or /get-valkey/ or something else) It should have instructions and links for docker, package manager, and build from source.
• Fix top nav to point to proper pages

Content - write basic content to populate site:

• Content: About Page (/about/) MVP: 1 paragraph that describes the history of the project
• Content: Connect Page (/connect/) MVP: 1 list with ways to connect (and security reporting info). I would model this after the opensearch connect page.
• Content: Home Page (/) MVP: some minimal content or tells the 3 most important things about Valkey
• Content: First Blog Post (/blog/update/...)
• Content: Docs stub (/docs/) that points to command reference and whatever actual docs pages that are present) Docs stub page + 2 docs pages #24

Requirements:

• Find out if site needs Terms of Service, Privacy Policy, etc. as per LF polices
• Determine if LF allows Analytics and how to get proper tag

Decisions:

• What to do with pre-Valkey releases referenced in docs/command reference (e.g. There are places where search/replace yields confusing references to Valkey 3.0 that doesn't exist). Actual changes should mostly be in valkey-docs but this affects the command reference templates as well

Design / CSS:

• De-brand the site (remove puppy for now, move to a neutral colour pallet) De-brand site  #14
• Make fonts more neutral (all sans serif) De-brand site  #14
• Add logo [Bug] Add logo #28

Check and Review - Check for spelling, disfluency, accuracy, etc.

• Content Review: About Page
• Content Review: Connect Page
• Content: Home Page
• Content: First Blog Post

Repo/contributing/dev:

• Update site how-to for local
• Add bash script to build the site
• Update README

Technical Review

• Content Review: Commands Reference (this is a giant task - there are more than 400 pages here)

[madolson]

What to do with pre-Valkey releases referenced in docs/command reference (e.g. There are places where search/replace yields confusing references to Valkey 3.0 that doesn't exist). Actual changes should mostly be in valkey-docs but this affects the command reference templates as well

I think we should keep track of the important decision, and include them in a "OSS Redis compatibility page" that can includes the relevant changes.

Content: Docs stub (/docs/) that points to command reference and whatever actual docs pages that are present)

I would like to include as much as possible from the former site. My proposal is that we should have folks migrate the docs pages and update them on the website in a pair of PRs. That way we have a clear way of tracking them, basically if they are hosted on the website they have been updated.

[Laphatize]

Going to tackle this one tonight.

Content: About Page (/about/) MVP: 1 paragraph that describes the history of the project

[stockholmux]

@Laphatize Right on! Looking forward to your PR.

[madolson]

We also need to add a logo.

[Laphatize]

We also need to add a logo.

Is there a non ASCII variant logo currently? Could only find this: https://github.com/valkey-io/valkey/blob/d89ef06ce5c377e5bcba5703ac138ccdfffb89e4/src/asciilogo.h#L30

[stockholmux]

@madolson is that finalized?

[madolson]

Yeah, I think the only open question is the coloring. As long as we are okay with a black logo, I can get you the SVG for it.

[lia-07]

I started designing an alternative Valkey website last night (with SvelteKit and TailwindCSS), and could fully build it out and map it to Jekyll/Hugo (without Tailwind) if you guys like. I think it looks a bit more cool and distinctive than the current site, without being an over-the-top rebrand (e.g. Redis). All fonts used are open source.

(Edit: The copy on it definitely needs work and someone else could probably write it better than me)
(The reason I didn't just come right out with a pr is I don't know if you all don't actually want it)

[Laphatize]

It looks good - but I'd try to make it follow the styling of the current logo & the Linux Foundation's branding guidelines.

[lia-07]

It looks good - but I'd try to make it follow the styling of the current logo & the Linux Foundation's branding guidelines.

Do all LF projects have to follow their branding/theme? The only thing I could find on their website about it was saying to not use their logo. Also it looks like most other LF projects don't.

As for the logo, I have included it in the header:

Edit: Just made a mock up with colours from the official LF brand guidelines:

[madolson]

Do all LF projects have to follow their branding/theme? The only thing I could find on their website about it was saying to not use their logo. Also it looks like most other LF projects don't.

My understanding is no. We have just been using the same original blue theming, and I sort of prefer the blue one.

I would be happy accepting a PR to move to one that still supports jekyll. @stockholmux @zuiderkwast thoughts?

[zuiderkwast]

The design looks good to me (disclaimer: i'm a programmer). 😁

I think it can be incorporated in this repo in a PR, right?

We have this logo with colors:

(We can make the background transparent so it works with light and dark backgrounds.)

[stockholmux]

Okay folks. We're approaching the end of launch plan. We'll soon start to move to the next phase. I love the creativity in this thread!

I think though, it makes sense to think about everything from a sequencing perspective. The reasons why the site is frankly a little boring is that so much is yet to be determined.

Generally, the path that the project needs to take is to first figure out the 'brand'. This would involve creating a comprehensive set of guidelines for things like pallets, fonts, logo/use placement, etc. The brand goes beyond just the look/feel of the website - it goes to things like templates for presentations, conference materials, tee shirts, etc. And, given that this is an open source project, we'll probably have to go through many rounds iteration before there is a consensus. I'm think the end result would be a document that would be structured something like the OpenSearch brand document.

The other factor is determining what the project actually needs and how it's structured. Right now, doc are just starting to be able to pulled in and there was recently a question on how it should be structured. That will have massive impact on how the site is also structured.

There is also some dangling thing that need to be understood about how we should present LF on the page - this is more about footer materials and how the site can/cannot place the LF logo on the page than dictating the design language.

So, after we get a solid brand and confirm structure, then it'd be'll be in a good position to start thinking about mockups

[daniel-house]

Tee shirts? A full range of merch! How about a bobble head?

[lia-07]

I could start working on an initial concept of a brand page based off my website if you like.
I understand that this may not be adhered to or well-liked, but it could be a start.

EDIT: Also, were we planning to eventually switch from Jekyll to some other page builder (i.e Hugo, Astro, NextJS, or SvelteKit)? Because if so, a new design could come in at the same time.

[zuiderkwast]

FYI: I'm working in the doc repo with this: valkey-io/valkey-doc#30

There are other issue and PRs in the doc repo for rebranding. I think discussion about content should be in doc repo rather than here.

[stockholmux]

@lia-07 Your design skills could be of good use for #55

[Amitgb14]

Is there anyone working on this? I see webpage are still looks static and need update.

[stockholmux]

@Amitgb14 yep lots of work going on! There are a few dangling tasks here so it's not closed. Right now the work is focused on #62/#67 as there was a bit of a brick wall on the current ssg.

[celestehorgan]

@stockholmux - just a question: is the idea to port content that currently lives in https://github.com/valkey-io/valkey-doc to here, or is https://github.com/valkey-io/valkey-doc still on the buildpath?

From a new contributor perspective, having all your content in .md files in a static site generator is easier to deal with, if a little less automated.

[stockholmux]

Hey @celestehorgan (I think we've met in Berlin at FOSS backstage!)

The pathway is to have two distinct repos: the website and the docs.

This is for two reasons:

1. There are some folks in the project that feel extremely strongly about this separation. I am not one of these people, but there was no other consensus that could be reached.
2. Valkey-doc was forked from redis-doc but the website repo was not, so at the time of the project's creation it was decided to keep forked repos somewhat seperate from net-new repos.

Not sure how much you've played with the current system but once you get into a flow with the two repos, it's a relatively smooth experience, albeit a little unusual. Alternatively, someone contributing to valkey-doc should not actually need to worry about the website, all edits can be made directly to markdown.

[zuiderkwast]

The doc repo now is now able to build preprocessed markdown files (as well as man pages and html files for local viewing). These preprocessed markdown files could be built and stored as github artifacts from a github action in the docs repo if you want and you could use that instead of the doc repo directly if you want. It can transform the links as you want and for command pages it adds certain stuff like See Also, command syntax, ACL categories, etc. Then you could avoid a lot of custom logic in the website rendering.