Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received-SPF: pass (google.com: domain of joachim.dreimann@wandisco.com
 designates 10.152.125.12 as permitted sender) client-ip=10.152.125.12;
MIME-Version: 1.0
In-Reply-To: 
 <CAMF4co-KfFVtZHouQW8xRSrX7xvv=NJAbM1iaZTpo9KMAs5+ew@mail.gmail.com>
References: 
 <CAMF4co-KfFVtZHouQW8xRSrX7xvv=NJAbM1iaZTpo9KMAs5+ew@mail.gmail.com>
Date: Mon, 20 Feb 2012 18:51:35 +0000
Message-ID: 
 <CAKoya93L=JOp7+xxc49SsLnZ-iRkPAre1i70wrG3+EGDVb-Gwg@mail.gmail.com>
Subject: Re: Bloodhound thoughts
From: Joachim Dreimann <joachim.dreimann@wandisco.com>
To: bloodhound-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 to your initial assessment of Trac.
You've done a pretty good job of describing Bloodhound's goals too!

> * Can email2trac be bundled out-of-box? https://subtrac.sara.nl/oss/email=
2trac

I would like to know more about this first. From reading some of the
documentation I have the impression that the purpose of this plugin is
to provide an alternative method to create/modify tickets for two
reasons:

1. Trac's poor mobile/tablet interface
2. Forwarding information generated by other systems in an automated fashio=
n

I believe Bloodhound will address both points, the first via the UI,
the second via an API.

>From a user experience perspective the syntax used is very specific
and those humans that would generate this manually per ticket would
always (?) be better off using Bloodhound directly when they have
access to it. If they don't, why not? May 1. or 2. above address this?

We should keep in mind that these Emails would be written in a generic
application without specific support for the syntax, so they wouldn't
be able to assist the user in any way, like providing guidance or
timely feedback.

On that basis I would say -1 for now.

> =A0* Review of historical ticket data is an essential part of our
> project management method. =A0We have scripts that mine trac for
> historical data and plot it using the google charts API. =A0Tickets are
> plotted by state over time, ticket "velocity" (the rates at which they
> move through states), etc. =A0It would be great if this was just part of
> trac and available as a wiki macro.

This type of information will be shown on top of the Activity feed for
example in future, but more details on that need to be decided on for
a version after the initial release.


> =A0* I like the dashboard/activity views that have been shared but I'm
> not clear if these are supposed to be new pages, or new functionality
> available as wiki macros? =A0I make a lot of dashboards using trac and
> wiki macro queries, it would be nice if these dashboards you're making
> were customizable using the same mechanism... can they just be wiki
> pages themselves?

As a starting point these would just be pages without much ability to
modify them. The more feedback we receive and can observe people
actually using it, the better we'll understand how far towards full
flexibility we have to go.

A consistent UI will help users build a clear mental model of how
things work, which will allow them to move towards intermediate skills
more quickly, which should then allow them to use wiki macros etc.

- Joe