Revamping GlusterFS website for expanded participation

I'm getting my feet wet with GlusterFS community. If you haven't heard of it yet, it's a distributed cloud file system by Red Hat. It's an open-source project with many goodness within, which empower Red Hat Storage (RHS) server.

I was asked to look into the Gluster.org project site & make suggestions on how can we make it better. Better is a subjective term; it depends on the end goal and how far the plan can achieve it. I've set myself a goal & the goal is to radically increase participation in Gluster project.

There are several parts to act on this, and all those will be communicated with in apt channels. This post, however, focuses on renovating the website as the public face & funnel to drive participation & contributions.

0. Forewords

First of all, thanks to who have worked on whichever part of the GlusterFS website (especially tigert). To keep the post to the point, I'd intentionally keep the discussion around the things which we can do better, than those which already are better. If my thoughts appears hurtful/callous for that - I'm sorry, not at all my intention. I just wanna help.

I'll discuss the website strategy in a total four umbrella parts - Contents, Hierarchy, Channels, Engagements. More importantly, I'll talk about how can we set up a system that leads to a better website, than describing the trivialities of how the website should look, or which all buttons should it have.

1. Contents

The flesh of the website is the content that it holds. How does it expose those information, are part of the next section (Hierarchy), but for now, let's consider everything to be flat.

i. The Cause

Let's not presume the visitors to know a lot about us (or to know a lot of jargon). Let's give them an interesting but simple introduction. Let's explain why the project matters, and why should one support it.

Folks who start contributing to FLOSS for a cause they can relate to, are the ones who go the longest of ways.

ii. The Pitch

The key differentiating factor between a corporate product website & a FOSS project site can be boiled down to (IMO): We just need to tune ourselves for the later.

iii. The Outreach

Not everyone would join. But it shouldn't be because they never heard us calling.

We need to make sure we're not being too narrow on our outbound channels. We need to have a face on all social channels, make them easily discoverable & should actively make those channels participatory; letting the visitors choose their favorite channel(s).

More on this later.

iv. The Promise

Those who know the volunteer drop rates in FLOSS world, understands how important it is to be there for the new folks whenever they're stuck at the time of discovery.

The promises can be of various forms, including super-complete documentation, super-interactive demos, super-nice people or, something else... or, all of them!

What matters is, folks willing to join are comfortable believing in, whenever they need some help, it'll be there for them. Always.

v. The Takeaway

The sense of achieving something is the main driving factor for most people. Even when we're spending hours in toilet, playing Flappy Bird or 2048, we're essentially trying to achieve a target high-score, or to do better than before.

The takeaway comes in various forms for different people. In open source world, those are primarily:

  1. The feel good factor of doing something that helps others
  2. The interesting & smart way that they've solved a problem
  3. The global scale of impact they create & recognition they get
  4. The freebies.
Human brain, at least subconsciously, would determine the takeaway to justify any effort it's pondering to give. Let's make sure, we understand & implement this part cautiously & flawlessly.

FWIW, dashboards of contributor stats, contributor spotlight blog-posts, paid positions opportunities, supporting contributors to create-presence/spread-words, T-shirts/Stickers, Potato/Banana - all of them would work (& some of them are parts of the website-strategy; hence the mention/detailing).

2. Hierarchy

The contents are the flesh to the hierarchy skeleton. We need to get the structure right - to ensure maximum reach out of shared information. For a FLOSS project it'll have to be community-facing & welcoming. The need of structured content-discovery would matter more than a shiny animation or picture of smiling people.

i. The Landing Page

Remember we talked about "The Cause"? Yes, this is our time to get it right.

The first view of the landing page should make sure why the project exists in this world & why should it be nurtured for growth. To get this right essentially means a higher chance the visitor to even navigate to other part of the site to discover what it is about.

Apart from the cause, all the other parts of the content should just leave easily discoverable trails in the landing page & link out to different dedicated portals for catering to more details.

ii. The Code Repos

In GlusterFS, we have the Forge, which is a private Gitorious deployment, to host code upstream. There's a GitHub mirror (where we don't accept much participation), Gerrit for code review, Bugzilla for issue tracking, Jenkins for integration & not nearly enough concise, public documentation to get people started with development.

This disconnect is so huge, any new contributor is bound to feel lost while starting with code-contributing without heavy hand-holding.

If we can get a code.gluster.org up, focused towards code-contributions & list/link all the portals, such as Forge, Github, Bugzilla (with easy/good-first-bug search listings), Gerrit, Jenkins, dev-env setup docs etc. That should merge this gap.

On this note, using GitHub as valid participation gateway can also work wonders. Just because we don't accept pull-requests through GitHub means we're missing out on a heavy amount of code contributions (I have a story from last year & ballpark estimation on this).

iii. The Documentations

Let me just list down the various disconnected efforts, making the current state of docs: Holy FFF...Fragmentation!

Let's just have a Gluster-skinned Mediawiki deployment on docs.gluster.org, m'kay?

iv. The Blog

The public engagement happens in the blog. The blog tells the story of recent developments, activities, super-contributors, need-to-knows (announcements) etc.

I'd give any new visitors 10 mins to discover the GlusterFS blog from visiting the site or tinkering with URL. And the moment you figure you've found it, you're wrong - you've found the landing page, Plan B.

So here's the deal:

A lot of efforts can go in to the Blog & very well should.

3. Channels

As discussed earlier, let's not be unheard from any part of the Internet's Social Media.

I'm talking of the outbound channels (social profiles) as well as inbound ones (communication platforms). Presently we're very picky about where we broadcast ourselves, and from where we listen from. But that may be a major bottleneck of contributor engagement.

i. Outbound

We already have our blog, as well as Twitter, Facebook, Google+ profiles. Before we get on to more platforms, we should have better presence on these existing platforms.

All these channels should foster participation & discussion; shouldn't be one off posts on regular interval & no responses on if discussions started.

If we're lacking necessary dedicated people to manage these all channels, maybe tools/services like IFTTT can help.

ii. Inbound

IRC & Mailing list is there. Either of which will take at least 5mins to explain to any new contributor. Their communication preferences has changed drastically in last couple of years. And being orthodox here would simply narrow our own option of community growth.

We do need people to discover the beauty in those tools - we do. But that can't be the 0th day thing. That just makes the entry barrier higher.

Let's keep ourselves open to all sorts of communications tools. Facebook Group Chat, WhatsApp, Telegram, Hangouts groups, Slack - it's a non-exhaustive list, and most of the tools are spammy in nature. So what?

The moment a discussion gets serious/material, we can move them to serious channels. That shouldn't be hard!

What all I'm saying is, I myself might not be joining all those channels/platforms - I may not even like/use many of them. But that's my preference & that's no reason to set limits on others preferences. This applies to all existing community members.

4. Engagements

So, we've done good enough job with the previous three parts. We've came up with the proper details, structured them out in right way, shouted out to spread the word & heard back from the people - got noticed & got good people coming in.Now what?

Now it's time to give them a purpose to be in the community.

Cool demos, interactive getting started guide, different teams & focus groups (no, everyone won't be willing to fix bugs), easy to discover & low-hanging chores in the community (including, managing social profiles - see?), managing/fixing documentation, host events & talk about the project, thin VM images with GlusterFS developer environment setup for the daring souls - these all (and more) can be what gives people an opportunity to help the project, in their own ways. The engagement is what helps them collect takeaways from the project.

5. Wrap up

I've had a list of stuff broken in our website. Including (and not limited to) the test-score results/screenshot of all the UX & Performance benchmarks for all sub-sites - to be an objective critic. But beyond my best effort, it kept looking like a public shaming of the existing contributors, torn from a cynical's diary & pasted on the village pump. So I re-wrote the entire thing, focusing more on how it should be, than how it is.

Thanks for being with me till here. Wish I could pack better punch(lines) in lesser words.

Although, sure I've left many things underdiscussed & that's where the comments would come handy. I want to hear from all of you. Once we reach consensus on most of the topics here, we can start implementing them in the project.