Hi, Not sure this is the right list... 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). 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/. 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. Regards, Alon
Quoting Alon Bar-Lev <alonbl@redhat.com>:
Hi,
Not sure this is the right list...
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).
I agree. It is assumed that a new contributor comes with an agenda/idea of what he/she wants implemented in ovirt. There is no place for someone new or experienced to see what needs to be done. Some of the bugs have access control and are not visible to the community. We should have something like kernel janitor. I can speak to it with some authority since I am not from the core/original ovirt team. Regards Sharad Mishra
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/.
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.
Regards, Alon _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
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?
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". 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". 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.
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. Thanks for the feedback, Alon! Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
----- Original Message -----
From: "Dave Neary" <dneary@redhat.com> To: infra@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. 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.
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.
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.
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. Thanks, Alon.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig258F56716B86D22986221A3D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/19/2012 05:46 AM, Alon Bar-Lev wrote:
=20 =20 ----- Original Message -----
Not sure this is the right list... =20 It will do to begin :-) We had design discussions on arch@ before,=20 and implementation decisions here. =20 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. =20 We are missing "Support" category, there we should have the user=20 lists and a link to bugzilla, and some bugzilla links for reports (opened bugs for example). =20 My thinking re "Support" is that it could be a good addition -=20 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
From: "Dave Neary" <dneary@redhat.com> To: infra@ovirt.org Sent: Wednesday, December 19, 2012 10:53:04 AM Subject: Re: oVirt site organization =20 Hi Alon, =20 On 12/18/2012 07:59 PM, Alon Bar-Lev wrote: menu items - but which one? =20 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.
Open source project has usually several top most goals: =20 1. license - IMPORTANT artifact, it is one of the first things people are looking in open source project. =20 2. support - IMPORTANT artifact, mailing lists, bugzilla. =20 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 ther= e. Is there any reason we can't just put "How to obtain source" under the [[Download]] page? 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= ? 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. 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=20 the source, as we do not have proper gitweb with list of projects, at least link to http://gerrit.ovirt.org/#/admin/projects/. =20 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". =20 People should have immediate path to access the source in open source
=20 project, this is what it is about. =20 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". =20 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. =20 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.
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=20 something common although it may be good English. =20 At http://www.ovirt.org/Mailing_lists, I expect the term "Full=20 index of mailing list" instead of "the oVirt mailman page". =20 In the "the oVirt mailman page" we are missing vdsm lists. =20 =20 On the location of the mailing lists: The Community page could=20 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! =20 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. =20 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 <=3D=3D missing - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig258F56716B86D22986221A3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iD8DBQFQ0hLr2ZIOBq0ODEERAmPOAJwPZrjES0rzbU6PdqaYX/AZBy8FGQCdGM3y SiToJKOfRvEV2/qXL9iATnA= =rlBx -----END PGP SIGNATURE----- --------------enig258F56716B86D22986221A3D--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: infra@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@redhat.com> To: infra@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9DE54E094924A08CCE7DD064 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 12/19/2012 12:53 AM, Dave Neary wrote:
=20 My thinking re "Support" is that it could be a good addition - currentl= y "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?
How about both? We could put Docs under Support, clearly. But we could also put "community support" under Support. Hmm, not to sure about that, though ... there are a lot of things on the Community page that are things people look for that don't belong elsewher= e. I do think people will look for documentation on the Support page. - Karsten --=20 Karsten 'quaid' Wade, Sr. Analyst - Community Growth http://TheOpenSourceWay.org .^\ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 --------------enig9DE54E094924A08CCE7DD064 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iD8DBQFQ0g992ZIOBq0ODEERAt6DAJ4//jRdn2o7q9xew38/NAY5CsZcpgCeJcub eTaKAEQiHHFGVUxUgZOcMDU= =nCgS -----END PGP SIGNATURE----- --------------enig9DE54E094924A08CCE7DD064--
participants (4)
-
Alon Bar-Lev -
Dave Neary -
Karsten 'quaid' Wade -
snmishra＠linux.vnet.ibm.com