[Gluster-infra] Gluster.org website revamp
deb at redhat.com
Mon Nov 10 10:03:59 UTC 2014
On Wed, Oct 26, 2014 at 6:17 AM, Louis Zuckerman < me at louiszuckerman.com > wrote:
> Hi Deb,
> 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 here.
I haven't yet; but I should ASAP.
Here's where I blog: http://debloper.blogspot.in/
> 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 .
So, now I know the person who'd feel hurt at my opinionated tantrums! :P
> The rest, see below.
> Thanks again!
> 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
> 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).
If we consider the (prospective) contributors are all okay with this, or, it's
only for the maintainer to handle the workload then it's okay. I don't have any
data, but if it's getting in the way, we'll see very less gradual increase of
new contributors & only a handful of initial contributors doing everything.
I'm not sure if that's the case. But if we're having new contributors at a
steady rate working on this, then it's probably not getting on the way.
I, for example, would want to contribute to this (episodic volunteering); but
for the dependency & build/deploy overhead requirements, will stay out of it.
> 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.
Following the point #2, if we use proper tools for each purposes, it's also
better to keep them separated from interfering with each others (interfacing
For e.g. we can have separate infra for docs (wiki/php) and blog (wp/php),
any fail/troubleshooting in either wouldn't mean a downtime for the other.
Even though, technically they can be running off of a same box.
Regarding routing/redirects - http://www.w3.org/Provider/Style/URI.html
We should make sure, one URI that ever worked, doesn't go dead; shouldn't.
> 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 out.
> 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
> Gluster-infra mailing list
> Gluster-infra at gluster.org
More information about the Gluster-infra