bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: First installation... my humble review
Date Wed, 06 Nov 2013 18:15:51 GMT
Hi Olivier,

Thanks for bringing all that up!


On 06/11/13 15:06, Olivier Mauras wrote:
> Hello,
>
> I met Gary Martin this morning on #trac and discussing quickly about 
> the look & feel of Bloodhound i ended up installing it on a test server.
> Here's a compilation of the points that i find "lacking":
>
> 1/ Blocking points for a production adoption - indeed that's only my 
> opinion
>
>   * Product owner should automatically have admin rights to this product.
>   I plan on using Bloodhound in a multi product / multi users setup.
>   I can't imagine it working without delegating the product admin 
> rights to their owners

I am pretty happy with named owners of products, or more generally 
resources, being given rights associated with admin of the resource. It 
might be useful if the permissions admin settings for a product 
reflected that in some sense.

>
>   * Products should be able to have their own source repo
>   If rights are delegated, I don't see any valid reason for owners to 
> not be able to add their own repos

I think that there may be some good use-cases for this, particularly 
when combined with the rights to access the product's admin pages. For 
instance it could be that a repository for a product should never even 
be known about in another product. The current solution forcing 
repository definitions globally and allowing local links means that the 
admin pages would have to be restricted to those that are effectively 
allowed access to all. It could instead be delegated.

In the end, there is still the current requirement that repositories 
have to be on disk and a trac-admin command has to be run by someone 
with appropriate access to the server but that doesn't fully justify the 
restrictions.

>
> 2/ Confusing points
>
>   * Tickets tab being the dashboard
>   Being a new user, I find it really confusing for the "Tickets" tab 
> for being the dashboard and consequently the only access to products 
> list.
>   It would be way more intuitive - and faster - to keep the products 
> list dropdown at the left of the breadcrumb.
>
>   * Not knowing where you are
>   This is indeed linked to the previous point, wiki and source pages 
> don't show the product in breadcrumb

I would definitely argue for extending the breadcrumb to go across all 
pages for this purpose.

>
> 3/ Eye candy
>
>   * Source browser CSS may not be the easiest to read
>   All lines to the same color make it difficult to catch things
>   Age color highlight is too light and/or too close in colors
>
>   * There's place on the mainnav tabs
>   As there's place available and that one can enable timeline and 
> roadmap from base.ini why not add them to mainnav() to not have then 
> in "More" tab?

The timeline has the virtue that it crosses all aspects of the system. 
There is probably a case for having a link, particularly if there are 
pages that do not have activity areas.

>
> 4/ Graphic glitch
>
>   https://bh-demo1.apache.org/products/%40/roadmap
>   As you can see here milestone bars are not displaying correctly.

There is an argument for dashboards to be replacements for the roadmap. 
Dashboards will provide more information and they are not yet available 
in an equivalent style. This might be enough of an argument to get the 
roadmap up to scratch as, at least in a sense, it is a little more 
focused a view than the dashboard provides.

Cheers,
     Gary

Mime
View raw message