[Gluster-users] Gluster project site revamp update

[Soumya Deb]

On 2015/04/08 at 21:42, Sankarshan Mukhopadhyay wrote:
> On Tue, Apr 7, 2015 at 9:42 PM, Soumya Deb <deb at redhat.com> wrote:
> 
> > I've put together some more stuff on the site.
> > Staging URL: http://code.debs.io/glusterweb/
> 
> The addition of new aspects/content to the staging site is not
> immediately obvious. If you are publishing/deploying the content from
> a repo, can you add the link to a Changelog of sorts?

Ref: https://pages.github.com/#vanilla-step-1
Brief: if you push HTML contents into a branch named "gh-pages" (instead
of "master" or "bug-123") in github.com/user/repo - then it gets published
as a webpage on user.github.io/repo - many actively use this free hosting.


> > Also, we probably can go on without the event-map - not much to show.
> 
> The present count of events may be less -> nil. This is expected to
> change substantially with the upcoming release. It would be helpful
> for a new visitor to be able to use the event-map feature aligned with
> events for the new release (release parties; get-together; meetups
> etc)

The way the site is put together, it should be less than an hour job to put
the events' map back on with all the markers, with Gmaps API integration.


> >> I wonder if you would consider figuring out how to include the "Try"
> >> (ie. download and experience the functionality for yourself) link in a
> >> manner that is immediately obvious. [Snipped]
> 
> I wanted to draw out a conversation around the personas. The new
> aspects to the web-asset are intended to address specific
> requirements. It would be good to have those requirements enumerated.
> This helps (i) in explaining the design thinking you are exercising;
> (ii) allow new contributors with various paths to get on-board and
> send patches.

There are very few rules which are preset, as I see from branding aspect.
I'm also not familiar with the usage stats of the current site to understand
the user demographics. We can expect them to be mostly sysadmins, but we
may as well be wrong. It may very well be managers of various orgs and mostly
Red Hat employees who visit the site.

My target was to attract the 18-28 y/o student/professional power-users with
technical background.


> > a. how to download; install and set-up
> > Was thinking about something like TryStack, or an interactive sandboxed
> > temporary environment to showcase the features of Gluster FS to the user
> > could be a way to go. Spinning up couple of small VMs with Gluster FS
> > preinstalled (or better lxc/docker/rocket/container images) with preset
> > scripts/demos shouldn't be too expensive. But it does need a lot of work.
> > We can start with video tutorial serie, may be & go up from there. But
> > this is where we need to listen to more ideas from the rest of us.
> 
> It would be good to list down the options which can be imagined and
> thereafter short-listed for the presence in the page.

Agreed. A note to self to initiate this; josferna was also interested.


> > d. how to get involved
> > For the time being, I was thinking of showing masthead from the landing
> > page & linking them to docs.gluster.org/contribute/<functionalArea>.
> > On the page, that section is after the event map, as "Be part of..."
> 
> I think it is time to think about ways to replace filler text on the
> page(s) with actual desired content.
> 
> I do realize that a part of my feedback overlaps with design/layout
> decisions and actual view/presentation layers of the design itself.

Trying to get docs.gluster.org up.
Once done, then /contribute/code, /contribute/devops etc. has to go up.


> > Reading docs may not be 'cool' for newcomers now a days & interactive
> > get-involved section featuring functional areas may work in future.
> 
> For example, a simpler design that drives a message similar to
> <https://fedoraproject.org/wiki/Join> may be good.

Neat! Our design intern Shravan is eloquent in wiki-markups.
I'll reach out to Humble to co-ordinate on that part.

 
> > I've had written about the need of the change, but yes - I've missed out
> > mentioning the key requirements. // http://blog.debs.io/3
> 
> It would probably be worthwhile to turn that post into a part of the
> code repository as well.

Agreed. README.md & CONTRIBUTING.md coming up soon.


> > So the idea behind this gluster.org revamp project was to ensure:
> > 1. It to have lower entry barrier for development contributions
> > 2. It to have near zero technical debts or technolgy-lock-ins
> > 3. It should be easy to fix, demonstrate/stage & reiterate
> > 4. It should play well across platform and formfactors
> > 5. It should not provide redundant/broken contents
> > 6. It should help gain project participation
> > 7. It should not look/feel 'off' in 2016
> 
> To ease the flow of administration of the site and updates to the
> content (or, parts thereof) should also be a goal.
> 
> Once the remaining filler text is replaced with actual content, how do
> you think you are doing against your criteria?

Working on #4. Should start working on #6 once the repo in on gh/gluster.
#7 is subjective, but consensus based (and under work). Rest are green.


> >> > The setup is such that it plays well with the new URLs to the
> >> > documentation, blog, code repos etc. makes contribution really easy for
> >> > everyone and doesn't require much overhead on the devop side as well -
> >> > it's as WYSIWYG as it gets.
> 
> That's the choice - whether to have a lightweight shim aggregating
> across existing assets or, create a deploy-ready content container
> which wires up with existing assets.

True; we should think of pros and cons for _our_ purpose to decide then.


> Either way, what is your understanding of a minimally functional and
> ready site which can be useful for the upcoming release?

Sounds reasonable (on time scale) & exciting (on prospect scale).
What all blockers could be there, if we set ourselves out for that?

Thanks for the well thought about insights, Sankarshan. :)