You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Hans Boot <ha...@ioteo.com> on 2014/02/28 17:29:56 UTC

Milestone due date handling

Hi, 
The mailing list being somewhat low in volume and not linked to the
closed-circle ticketing system at https://issues.apache.org/bloodhound/, I
hereby wanted to mention some issues I found with milestones and their due
dates. Please tell me if I'm off limits here, and I'll look somewhere else.

All this pertains to v0.8, freshly moved from Trac to BH.

Milestone due date in queries:
Probably the only question and not a bug report here: How can I use or
even see the milestone due date in a query? I have found no way of doing
so. This is a major field to me.


Milestone and cache:
Yes, I'm one of those affected by #681
Whenever one changes a component or a milestone, one MUST restart apache
otherwise the changes are not or not well taken into account.

Milestone due date entry:
Haven't found a ticket on this.
Tested on chrome, safari and Firefox.
It is impossible to select the first week of the month when entering a due
date, as that week is hidden behind the product selection bar.

Milestones on dashboard:
#686. To me this is not major, but at least critical. How can the default
dashboard be anywhere near what business users or even developers would
like to see? 

Issues with Custom dashboard with milestones:
* I had to replace the dashboard. I tried to add a report to the
dashboard, but for that I had to enable the report module in trac.ini
(although reports are possible elsewhere without that setting). That
however broke BH completely. So now I have set up a kind of wiki page in
place of the dashboard.

* When tweaking the query on the dashboard (adding milestones), I found
that on the default, 'no product' dashboard, milestones do not even exist
and therefor that query has no use at all.

Sorting in queries:
#654. Sorting is completely broken. I second urgent repairs on this. I
have to revert to grouping (and a lot of time lost in meetings when
bickering of what ticket is the next on the list, as everybody has a
different display order) to make queries slightly usable. I strongly
advise you to reconsider your classification of Reports as 'deprecated'.
They at least work.


<rant>
Having moved from Trac to BH, sure BH is nicer looking, but I have lost in
productivity due to the large number of bugs in BH. I am seriously
thinking of going back or even jumping to Jira. As it is now, I would NOT
consider this product production ready.
Cmon guys, I'm really disappointed. And then seeing that all of the
tickets I've referred to were moved to '0.x', that is blatant disregard
for users.
</rant>


Kind regards,
Hans BOOT




Re: Milestone due date handling

Posted by Olemis Lang <ol...@gmail.com>.
On 3/1/14, Hans Boot <ha...@ioteo.com> wrote:
[...]
>
>>I'll take a look , but in advance , it's ok if you create a ticket in
>>i.a.o/bh and continue the discussion from there .
>
> How do I do that? I cannot participate without a login, which I don't have.
>

Please register at

https://issues.apache.org/bloodhound/register

Requiring a login name helps us to control spam .

Thanks !

[...]

-- 
Regards,

Olemis - @olemislc

Re: Milestone due date handling

Posted by Hans Boot <ha...@ioteo.com>.
Hi,

>After a quick Googling session I foundŠ

Yes, I use due date extensively in the reports, the reports I moved over
from trac do still work. (except that I can no longer click on the group
head where I had configured custom queries for the groups, that is a pain)
It is the query module that I have problems with.


>I'll take a look , but in advance , it's ok if you create a ticket in
>i.a.o/bh and continue the discussion from there .

How do I do that? I cannot participate without a login, which I don't have.


> It'd be nice if you could provide us with hints regarding «what business
> users or even developers would like to see» so that we can calibrate our
> thoughts and consider your requirements to ensure they will be satisfied
>.

Well, I do not pretend to represent all business users, but the ticket
lists I've seen most helpful so far are:
(any serious project manager working with subcontractors should be able to
give a more complete list)

Sorted by priority ('what's next?'):
* contain only non closed tickets
* be grouped by milestone due date, sorted in ascending order
* inside the groups sorted by priority, from blocking to minor
* (and mention the milestone due date in the group headers, as the
estimated remaining effort)

Sorted by estimated backlog ('what should we focus on?'):
* contain only non closed tickets
* sorted by 'milestone due date - remaining effort in days', in ascending
order
* (and mention the milestone due date, the estimated remaining effort, and
the priority of course)


'Waiting for feedback' ('why is this taking so long?'):
* contain only tickets in a subset of states
* sorted by time since assigned to that state, and still in that state, no
matter the changes since then, in descending order

'By last modified date' ('what are they working on?'):
* contain only non closed tickets
* sorted by date/time of last text or attachment or state modification, no
matter other changes (that means amongst others: explicitly excluding
milestone, priority or version changes), in descending order

Those lists should allow prepared filtering and further interactive
filtering (user, component,Š), and therefore should be possible with
queries, as only queries will allow further interactive filtering.

(Typically, all those KPIs I've mentioned go in reports end of month and
let you base your billing or subcontractor- or team meetings on.)


So: 
* Sorting on milestone implies sorting on its due date, not on the label.
* Sorting on priority implies sorting on its numerical sort order, not on
the label.
* Sorting on calculated fields should be possible.
* Sorting on additional, derived fields, that are maintained by some
custom logic, should be possible
Neither of that is possible in the BH query module now. In trac the first
2 work OOB, and the last 2 with some tweaking.

Please make the query module work again. I have tried looking at it, but I
couldn¹t get to understand how the BH query module works, and haven't
taken the time to compare with Trac. (As I do have a business to run, my
effort is needed elsewhere).

Kind regards,

Hans BOOT




On 28/2/14 18:58 , "Olemis Lang" <ol...@gmail.com> wrote:

>On Fri, Feb 28, 2014 at 11:29 AM, Hans Boot <ha...@ioteo.com> wrote:
>
>> Hi,
>>
>
>Hi !
>:)
>
>[...]
>
>> Please tell me if I'm off limits here, and I'll look somewhere else.
>>
>>
>IMO , it's ok . That's what we are here for .
>
>
>> All this pertains to v0.8, freshly moved from Trac to BH.
>>
>> Milestone due date in queries:
>> Probably the only question and not a bug report here: How can I use or
>> even see the milestone due date in a query? I have found no way of doing
>> so. This is a major field to me.
>>
>>
>I'm not sure about seeing/using it in a query . BTW, could you do so in
>Trac ? If the answer is yes , then you should be able to reproduce the
>hack
>with BH . Otherwise , the only option I see is using custom SQL reports .
>
>After a quick Googling session I found :
>
>http://osdir.com/ml/trac-users/2010-03/msg00092.html
>http://stackoverflow.com/.../how-to-show-due-date-column-in-the-trac-repor
>ts
>
>
>> Milestone and cache:
>> Yes, I'm one of those affected by #681
>> Whenever one changes a component or a milestone, one MUST restart apache
>> otherwise the changes are not or not well taken into account.
>>
>>
>yes , I'm aware of that . It's annoying . I've spent a substantial amount
>of time trying to track it down , and identify what is it about but it's
>been hard to decipher the root cause .
>
>
>> Milestone due date entry:
>> Haven't found a ticket on this.
>> Tested on chrome, safari and Firefox.
>> It is impossible to select the first week of the month when entering a
>>due
>> date, as that week is hidden behind the product selection bar.
>>
>>
>I'll take a look , but in advance , it's ok if you create a ticket in
>i.a.o/bh and continue the discussion from there .
>
>Milestones on dashboard:
>> #686. To me this is not major, but at least critical. How can the
>>default
>> dashboard be anywhere near what business users or even developers would
>> like to see?
>>
>>
>This is just anticipated news ... ;)
>We are working on providing users with some (yet basic) tools for doing
>this . Shortly after BH=0.8 we «plan» to release it , and announce through
>the list . The initial support will be improved later in time .
>
>It'd be nice if you could provide us with hints regarding «what business
>users or even developers would like to see» so that we can calibrate our
>thoughts and consider your requirements to ensure they will be satisfied .
>
> Issues with Custom dashboard with milestones:
>> * I had to replace the dashboard. I tried to add a report to the
>> dashboard, but for that I had to enable the report module in trac.ini
>> (although reports are possible elsewhere without that setting). That
>> however broke BH completely. So now I have set up a kind of wiki page in
>> place of the dashboard.
>>
>>
>What I mentioned above will be an attempt to avoid this kind of situations
>. Please , just let us know what you have in mind and well ... be patient
>until new features will be released . We'll appreciate your help .
>
>
>> * When tweaking the query on the dashboard (adding milestones), I found
>> that on the default, 'no product' dashboard, milestones do not even
>>exist
>> and therefor that query has no use at all.
>>
>>
>the global environment does not own milestones by default , but I do use
>it
>in other multi-product deployments (using product sub-domains , btw)
>
>
>> Sorting in queries:
>> #654. Sorting is completely broken. I second urgent repairs on this. I
>> have to revert to grouping (and a lot of time lost in meetings when
>> bickering of what ticket is the next on the list, as everybody has a
>> different display order) to make queries slightly usable. I strongly
>> advise you to reconsider your classification of Reports as 'deprecated'.
>> They at least work.
>>
>>
>Yes . I can reproduce In my servers running PostgreSQL .
>
>-- 
>Regards,
>
>Olemis - @olemislc


Re: Milestone due date handling

Posted by Olemis Lang <ol...@gmail.com>.
On Fri, Feb 28, 2014 at 12:58 PM, Olemis Lang <ol...@gmail.com> wrote:

>
> After a quick Googling session I found :
>
> http://osdir.com/ml/trac-users/2010-03/msg00092.html
>
> http://stackoverflow.com/.../how-to-show-due-date-column-in-the-trac-reports
>
>
sorry the last URL is wrong , it is

http://stackoverflow.com/questions/7120472/how-to-show-due-date-column-in-the-trac-reports

-- 
Regards,

Olemis - @olemislc

Re: Milestone due date handling

Posted by Olemis Lang <ol...@gmail.com>.
On Fri, Feb 28, 2014 at 11:29 AM, Hans Boot <ha...@ioteo.com> wrote:

> Hi,
>

Hi !
:)

[...]

> Please tell me if I'm off limits here, and I'll look somewhere else.
>
>
IMO , it's ok . That's what we are here for .


> All this pertains to v0.8, freshly moved from Trac to BH.
>
> Milestone due date in queries:
> Probably the only question and not a bug report here: How can I use or
> even see the milestone due date in a query? I have found no way of doing
> so. This is a major field to me.
>
>
I'm not sure about seeing/using it in a query . BTW, could you do so in
Trac ? If the answer is yes , then you should be able to reproduce the hack
with BH . Otherwise , the only option I see is using custom SQL reports .

After a quick Googling session I found :

http://osdir.com/ml/trac-users/2010-03/msg00092.html
http://stackoverflow.com/.../how-to-show-due-date-column-in-the-trac-reports


> Milestone and cache:
> Yes, I'm one of those affected by #681
> Whenever one changes a component or a milestone, one MUST restart apache
> otherwise the changes are not or not well taken into account.
>
>
yes , I'm aware of that . It's annoying . I've spent a substantial amount
of time trying to track it down , and identify what is it about but it's
been hard to decipher the root cause .


> Milestone due date entry:
> Haven't found a ticket on this.
> Tested on chrome, safari and Firefox.
> It is impossible to select the first week of the month when entering a due
> date, as that week is hidden behind the product selection bar.
>
>
I'll take a look , but in advance , it's ok if you create a ticket in
i.a.o/bh and continue the discussion from there .

Milestones on dashboard:
> #686. To me this is not major, but at least critical. How can the default
> dashboard be anywhere near what business users or even developers would
> like to see?
>
>
This is just anticipated news ... ;)
We are working on providing users with some (yet basic) tools for doing
this . Shortly after BH=0.8 we «plan» to release it , and announce through
the list . The initial support will be improved later in time .

It'd be nice if you could provide us with hints regarding «what business
users or even developers would like to see» so that we can calibrate our
thoughts and consider your requirements to ensure they will be satisfied .

 Issues with Custom dashboard with milestones:
> * I had to replace the dashboard. I tried to add a report to the
> dashboard, but for that I had to enable the report module in trac.ini
> (although reports are possible elsewhere without that setting). That
> however broke BH completely. So now I have set up a kind of wiki page in
> place of the dashboard.
>
>
What I mentioned above will be an attempt to avoid this kind of situations
. Please , just let us know what you have in mind and well ... be patient
until new features will be released . We'll appreciate your help .


> * When tweaking the query on the dashboard (adding milestones), I found
> that on the default, 'no product' dashboard, milestones do not even exist
> and therefor that query has no use at all.
>
>
the global environment does not own milestones by default , but I do use it
in other multi-product deployments (using product sub-domains , btw)


> Sorting in queries:
> #654. Sorting is completely broken. I second urgent repairs on this. I
> have to revert to grouping (and a lot of time lost in meetings when
> bickering of what ticket is the next on the list, as everybody has a
> different display order) to make queries slightly usable. I strongly
> advise you to reconsider your classification of Reports as 'deprecated'.
> They at least work.
>
>
Yes . I can reproduce In my servers running PostgreSQL .

-- 
Regards,

Olemis - @olemislc