[Gluster-infra] Gluster.org website revamp
me at louiszuckerman.com
Sun Oct 26 00:47:55 UTC 2014
Thanks for the thought & effort you're putting into the gluster web site!
I have a few comments, for whatever they're worth. Some general thoughts
here, then individual comments on your points inline below.
In general, even if you post details of what you're planning or doing on
your blog, please also drop a note with link on this mailing list so we
know to go check your blog. I'd appreciate reading your blog but I
wouldn't know when or where to look unless you posted something about it
Also, since I'm the de facto Varnish admin (as far as I know), I want to
offer any help you may need, and answer any questions you have, about
Varnish and its role on gluster.org.
The rest, see below.
On Wed, Oct 15, 2014 at 7:12 AM, Soumya Deb <deb at redhat.com> wrote:
> Hi all,
> I was looking at the Gluster website for a while.
> Liked the last overhaul, much responsive now, but found that we could do
> even better.
> I'm planning on writing a 3-part blog post (public; so, raise a flag if
> anyone has concern against that) explaining by thoughts in details. But
> that's taking a while now & so I'll put the main topics here only. Correct
> me if I'm wrong/short-sighted anywhere - I know there have been a lot of
> discussion that I haven't been a part of, so unaware of the limitations you
> had to deal with (that I might accuse you of :P). I intentionally didn't
> check commit sign-offs - just so that I can give my opinions fair & square.
> 1. Using static site generator using Ruby: is it really required?
> (Alternative, pure static site, with client side templating)
As far as I know, it is ultimately up to the person who manages the site to
pick the tools they use. However, I know whenever anyone takes over (or
gets involved with) a project they will have a tendency to
redevelop/migrate things to tools they are comfortable with. This is not
necessarily a problem, but I would be careful to not spend time migrating
the project to new tools unless it's really necessary. Is it really
required? I think the question should be, "Is it getting in the way?" If
not, then lets just keep it the way it is (IMHO).
2. Using the right tools/frameworks for the purpose, and not trying to
> emulate the purpose of one framework/CMS with another.
Could you be more specific? Are we facing serious problems due to the
tools/frameworks currently used? (I agree with your statement in general,
it just doesn't seem like a top priority right now.)
3. Each of the facets of the site as short typable subdomains: docs, wiki,
> bugs, code etc. (with proper HTTP/301, as needed)
If it's just an aesthetic preference for subdomains over path directories
then I would say it's not very important in the grand scheme of things. On
the other hand, if we do switch to subdomains, then Varnish might prove
useful for routing requests and I'd be happy to help.
> 4. One go-to place for each facet/purpose (especially docs).
> http://gluster.org/documentation/ &
> http://www.gluster.org/community/documentation/index.php/Main_Page are
> highly confusing to get right information from & also creates
> fragmentation. A single http://docs.gluster.org/ (wiki with pretty URL,
> thus no /index.php/Main_Page etc.)
Agree. We would benefit from having "landing pages" with pretty URLs and
clear content aimed at common site visitor needs. Once we have landing
pages like this we can work on focusing search engines on them, so people
are less likely to find outdated or irrelevant information when starting
5. URLs like http://www.gluster.org/about, http://blog.gluster.org/blog/
> etc. are to be sanitized, decommissioned and/or properly redirected
Agree. Even more broadly, there's a lot of old content around that
confuses new users. There's plenty of old stuff on gluster.org sites, and
unfortunately also on other sites around the net. We should at least take
inventory of our own sites & do a better job of hiding the outdated
information from new users. I think this is a big, important issue, that
may need to be addressed on its own, independent of a gluster.org web site
> 6. Properly responsive website (like blog.gluster.org isn't) with
> seamless themes & url-integration for all sub-sites with better typography,
> legibility, color scheme etc.
> 7. More performing website, by removing code bloats, ghosts of copy-pastes
> etc. Also, needs some help with JS & CSS performance tuning.
> I'll details them in my blog & you'll get to comment there & continue the
> discussion. But please do correct me if I'm starting with the wrong foot
In my opinion, your issues #4 & #5 are the most important.
> P.S: will have to miss today's meeting as well. On the move & flaky
> connectivity. Apologies!
> Gluster-infra mailing list
> Gluster-infra at gluster.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-infra