[Gluster-infra] Gluster.org website revamp

Soumya Deb deb at redhat.com
Mon Nov 10 10:03:59 UTC 2014


Hey Louis!

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 .

Awesome!
So, now I know the person who'd feel hurt at my opinionated tantrums! :P


> The rest, see below.
> 
> Thanks again!
> 
> -louis
> 
> 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).

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

Example: http://gluster.org/documentation/


> 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
is okay).

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
> refresh.
> 
> 
> 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
> somewhere.
> 
> In my opinion, your issues #4 & #5 are the most important.
> 
> 
> 
> 
> Cheers,
> Deb
> 
> 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
> http://www.gluster.org/mailman/listinfo/gluster-infra
> 
> 
> _______________________________________________
> Gluster-infra mailing list
> Gluster-infra at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-infra
> 


More information about the Gluster-infra mailing list