[Gluster-users] Why revamp Gluster.org?

[Soumya Deb]

Hello all,

I came to realize, the entire discussion about why to revamp Gluster website is fragmented across threads & links. Thought it might be a good opportunity to post a brief, yet cover-all write up on why this is necessary.

There are three primary facets to the challenges we are facing, and I'm also listing their prospective solutions:

1. For devops:

Presently, the devop/deployer needs to handle
 - a readme: https://forge.gluster.org/gluster-site/gluster-site/blobs/master/README.md
 - a config: https://forge.gluster.org/gluster-site/gluster-site/blobs/master/config.rb
 - & script: https://forge.gluster.org/gluster-site/gluster-site/blobs/master/setup.sh

^ that's even if it's just a typo fix.

This could be as simple as: `git pull`
Instead of generating, having a ground up static site can solve this for us.


2. For developers:

[Part 1: DevEnv Setup]
Presently, one needs to download and install quite some dependencies (most of which a web-dev may not even need for any other purpose ever) to get started; the overhead is even higher if using no/nix platform.

This could be as easy as, drag & drop the index.html on your browser - being completely static site, it should work fine (Look ma, just file:// protocol!). Essentially, a browser & a text editor is all one would need to start with.

[Part 2: Learning Curve]
Presently, one needs to understand not only HTML, CSS, JS but also HAML, templating/partials, SASS, YML and so on, going through hundreds of files, trying to understand how stuff works, with a combination of technologies so incredibly niche, barely anyone would feel like home rightaway after cloning it.

The learning curve could be as low hanging as the basic web technology, and just that. No abstraction layers, templates, compilers, preprocessors - unless there's a very good reason/need for it (probably not). Essentially, having a much wider prospective contributor base on its codes.

[Part 3: Stage/Showcase]
Presently, one needs to run a script each time (s)he makes even a typo-fixes to get that reflected on their localhost server. To show around, one needs to get a hosting platform & take explicit steps to host it (skipping the expense part of it).

The staging/showcasing can be as easy as a git push to own fork, and to be able to check the live web page served at http://username.github.io/reponame with new code (try http://debloper.github.io/glusterweb/). Essentially each contributor having their own staging, including the http://gluster.github.io/glusterweb/ as the main staging. Easy for the reviewers and deployers to verify that everything is alright instead of trial and error.


2. For visitors:
A website built with many moving pieces, fragile gears & wheels will tend to break, point to wrong/confusing locations, introduce fragmentation & duplication of contents, heftier bandwidth requirements, responsive regression etc (skipping examples), causing bad user experience. The number of HTTP requests, the amount of assets to download, the minimum time required for the site to be accessible etc. all adds up to this point.

If the project is easier to build and manage, it in turn means less breakage & faster fixes. Also iterative extensions/overhauls won't also be a nightmare.


I'm unsure if I was able to set the tone right; I'm only trying to make a point why a complete architectural overhaul of the website is required, and not just a UI or content update. If you have thoughts or concerns, please do share.


Meanwhile, I'm feeling the lack of a Branding guideline for Gluster. I'd be very much willing to help out Toumas to take this opportunity & create a brand guideline for Gluster. Also, I'd like to hear from misc about whether the new proposed model for deployment (git pull ;) would be more preferred than the current setup (or if there could be any blocker to go that way).

Cheers,
Deb