[Gluster-users] Why revamp Gluster.org?

[Tuomas Kuosmanen]

> ^ 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.

This is actually not true. The middleman / ruby framework is wired up
so that it builds the site when you push the change. For a simple typo
it's no different to what there is now. You can correct a typo and push a fix.

It is however a good idea to generally check that your changes build
correctly and don't break things, just like how you do with code. 

> 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.

This all depends on your own perspective and what you already know. To contribute
content, you don't need to understand any of the framework. You edit a chapter
of Markdown in an existing page, or create a new one in a folder. Markdown is 
designed to be easy to read and write. This email is very similar to the markdown
syntax.

You don't really need to touch the templates or styling or that stuff if 
you want to add *content*. Everything else is for the people who actually 
*design* the website look and feel. And to do those, you need to define them
somewhere anyway.

HTML, CSS and Javascript are not really any "easier" to learn for a newcomer, 
you are just already familiar with them. 

We are not really lacking in people who do web development, we want people 
to contribute *content*.

How about we combine our ideas?

  * We could move the site git repo to github to make it easier to contribute
    (since many people have accounts already)

  * We could then use the github "edit this file" feature to make changes
    to the content files, and people could use Markdown/asciidoc syntax, 
    because it is much easier to work with than writing HTML. 
    <p class="point"><b>Because brackets and markup are <i>great</i> for 
    computers</i> &mdash; but writing them by hand (and <a href="#">spotting
    missing brackets and other mistakes!) is pretty annoying for regular human beings.</b></p>

> 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.

You do not need to learn to use the framework to write content.

An alternative way to contribute:

  * Start a temp git repository in github and write a markdown page (index.md)

  * Edit it with the github web editor, save (makes a git push) and view it 
    directly in github. Github does render it for you so you can see everything 
    works correctly.

  * Submit the file as a merge request or just mail the list and ask it to
    be included if yo ufeel intimidated by the framework.

> 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.

A single html page is always easy. If you want to add more content, you will
need to have some kind of templating system to maintain consistent navigation
and such anyway..?

But let's continue the discussion!

//Tuomas