oVirt site organization

Wed Dec 19 19:53:30 UTC 2012

----- Original Message -----
> From: "Karsten 'quaid' Wade" <kwade at redhat.com>
> To: infra at ovirt.org
> Sent: Wednesday, December 19, 2012 9:18:03 PM
> Subject: Re: oVirt site organization
> 
> On 12/19/2012 05:46 AM, Alon Bar-Lev wrote:
> > 
> > 
> > ----- Original Message -----
> >> From: "Dave Neary" <dneary at redhat.com> To: infra at ovirt.org Sent:
> >> Wednesday, December 19, 2012 10:53:04 AM Subject: Re: oVirt site
> >> organization
> >> 
> >> Hi Alon,
> >> 
> >> On 12/18/2012 07:59 PM, Alon Bar-Lev wrote:
> >>> Not sure this is the right list...
> >> 
> >> It will do to begin :-) We had design discussions on arch@ before,
> >> and implementation decisions here.
> >> 
> >>> I think that there is a gap from what user(and developer)
> >>> expects to see in open source (or any) site and what we have.
> >>> 
> >>> We are missing "Support" category, there we should have the user
> >>> lists and a link to bugzilla, and some bugzilla links for
> >>> reports (opened bugs for example).
> >> 
> >> My thinking re "Support" is that it could be a good addition -
> >> currently "Documentation" and "Community" answer the use-case
> >> "Help! I'm stuck" - plus, of course, the integrated search box. My
> >> only concern is that we already have 6 top-level menu items, and
> >> adding another one would make things worse from a usability point
> >> of view. Perhaps "Support" could replace one of the other
> >> top-level
> >> menu items - but which one?
> > 
> > Support is a must, people look for this word. Drop the community,
> > as
> > it has no sense, the whole ovirt is a community.
> 
> There is definitely evidence that "Community" - and all the content
> we
> currently have on the [[Community]] page - are something people look
> for
> when they come to an open source project.

I am very sorry, but I strongly disagree.
I would consider that the [[Community]] is pressed because of lack of better options...

> 
> > Open source project has usually several top most goals:
> > 
> > 1. license - IMPORTANT artifact, it is one of the first things
> > people
> > are looking in open source project.
> > 
> > 2. support - IMPORTANT artifact, mailing lists, bugzilla.
> > 
> > 3. source - IMPORTANT artifacts, this is open source project, the
> > source is the center of all activity.
> 
> The source is the center of developer activity. These days, people
> don't
> prefer to compile a project from source. That is why [[Download]] is
> there.
> 
> Is there any reason we can't just put "How to obtain source" under
> the
> [[Download]] page?

Because it is not download, sorry, it is entirely different.
At download you download RELEASE.
At source you get access to the SOURCE CONTROL.
Two different audiences, two different artifacts.

You can put a clear title under the MAIN page of develop, with a clear list (maybe auto generated) of all git repositories we have. It should not be hidden at 3rd level page under unclear title of "subprojects".

> If I go to a project and see "Source" as a top-level menu item, I'm
> not
> sure if this project is for me - does this mean I have to compile
> from
> source? *ick* Does this mean the project is all about the source
> code,
> and my expertise as an infrastructure or documentation guru isn't
> welcome?

I strongly disagree. If you have "Download" you go to download if you want to download, if you have "Support" you go to support to get support, the existence of "Source" or "Develop" which are the same is no way tells anything for you inexperience user. 

> Users and contributors of all types are the target audience for that
> page. Source is of interest to only a subset of those groups, and
> scary
> to another subset.

I suggest taking ideas from the following sites:

http://www.libreoffice.org/
http://www.openoffice.org/
http://kde.org/
http://xfce.org/
http://www.cacti.net/

> For those reasons, I'm not sure "Source" is a good idea for a
> top-level
> menu item. Especially since I agree that we want to limit the amount
> of
> menu items for UX reasons.
> 
> >> 
> >>> We are missing "Source" category, a clear place of how to obtain
> >>> the source, as we do not have proper gitweb with list of
> >>> projects, at least link to
> >>> http://gerrit.ovirt.org/#/admin/projects/.
> >> 
> >> On "Source" I don't really think it is a top-level menu item.
> >> There is a much better argument for "Support" or "Get help".
> > 
> > People should have immediate path to access the source in open
> > source
> > project, this is what it is about.
> > 
> >> There is a general ergonomics rule of thumb that top-level
> >> categories should not be more than 5 or 6, and not be fewer than 3
> >> or 4 - even 6 is giving the user a lot of choice and a lot of
> >> things to read, and if you only have 2 items, you're better off
> >> avoiding a header altogether and designing your page around those
> >> 2
> >> categories. So I'm happy having "Get the source code" under
> >> "Develop" and under "Download".
> > 
> > I don't approve these ergonomics rules... If these rules makes the
> > site unusable for me as a new comer, and I cannot find what I look
> > for (which I do find in other similar sites), then something is
> > wrong
> > with these rules.
> 
> Personally, I don't understand intuitively all the user experience
> and
> interface decisions that expert designers make. I recommend, though,
> that we don't dismiss them outright without trying to understand and
> consider the various consequences. On that front, Garrett will be
> back
> in the new year, and I'm sure is happy to help our understanding.
> 
> Bottom line for me is, too many links on a page is not what I'm
> looking
> for. Well organized information where I can find what I want without
> having to use Search, that's what I want.
> 
> It's OK that others don't mind too many links. But others definitely
> *do* mind too many links and walk away when a wall of links is
> presented
> to them. What's the right # of links for a top-nav or for a page?
> That's
> debatable, but there has to be some guidance and rule, or we end up
> looking list this:
> 
> http://web.archive.org/web/20020525101346/http://www.netscape.com/
> 
> >> We don't have a good page on getting the source code right now -
> >> the process is different for Node, Engine, VDSM, etc. This might
> >> be
> >> a good community project for someone.
> > 
> > It is master site design... not a separate project.
> 
> I think Dave simply means, that page is a wiki page, anyone can edit,
> and it would be a good task for someone to improve that page.

We should generate this page, there is no sense in maintaining it by hand.

> 
> >>> Community is not a proper word for "Mailing lists", first thing
> >>> I look is for "list" in the home page and I expect it to be
> >>> there, the term "Have conversations on our mailing lists" is not
> >>> something common although it may be good English.
> >>> 
> >>> At http://www.ovirt.org/Mailing_lists, I expect the term "Full
> >>> index of mailing list" instead of "the oVirt mailman page".
> >>> 
> >>> In the "the oVirt mailman page" we are missing vdsm lists.
> >> 
> >> 
> >> On the location of the mailing lists: The Community page could
> >> perhaps be improved. There is a lot of text right now, and we can
> >> definitely improve on it and make the actions available much more
> >> prominent. Suggestions are welcome!
> >> 
> >> On the VDSM mailing lists being missing from the oVirt mailman
> >> page, this is a consequence of the list being hosted on
> >> fedorahosted - suggested improvements to the text are appreciated.
> > 
> > All source repositories and mailing list of ovirt should appear in
> > ovirt.org. This includes all related projects without exception.
> 
> This is simply a mistaken link on a wiki page. It should go to the
> fedorahosted.org mailing list, and I just fixed it to go there.
> 
> What is really missing is the [[VDSM]] page on the wiki. Cf.:
> 
> http://ovirt.org/Engine
> http://ovirt.org/Node
> http://ovirt.org/VDSM <== missing

Thanks, however I am almost sure the list at[1] is incomplete.

It is *VERY* confusing to read:
"There are many mailing lists in the oVirt project - mostly referenced on the oVirt mailman page"

Then see that mailman page does not contain one of the most important list - vdsm.
And what is mostly? where are the other?

Instead of worrying at this point how much top menu item do we have, I think we need to get into better shape first.

As current state for people of type *ME* smells like immature project.

So let's summary my point of view.

COMMUNITY
news and events.

DOWNLOAD
download source, download distribution specific packages.
Download page should have SOURCE title and BINARIES title.
Under SOURCE there should be a link to WebDAV of sources (ALL VERSIONS).
Under BINARIES title there should be FEDORA, under FEDORA should be FEDORA 17, under FEDORA 17 there should be repository settings for each version and link to WebDAV of RPMs (ALL VERSIONS).
etc...

DOCUMENTATION
Should be user documentation.
I don't think developers are looking for developers documentation at top level documentation.

SUPPORT
A reference to all mailing list.
A reference to bugzilla.
A reference to IRC.
A reference to HOWTOs and FAQ at wiki.

DEVELOP
"Access the source" -> cgit/gitweb front-end with all source repositories.
"Developer documentation"
Development (entry level) mailing list

Action items:
move vdsm lists to ovirt.org.

Thanks,
Alon

[1] http://www.ovirt.org/Mailing_lists

> 
> - Karsten
> --
> Karsten 'quaid' Wade, Sr. Analyst - Community Growth
> http://TheOpenSourceWay.org  .^\  http://community.redhat.com
> @quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41
> 
> 
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
> 