You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@bloodhound.apache.org by Apache Bloodhound <bl...@incubator.apache.org> on 2012/08/31 16:59:20 UTC
[Apache Bloodhound] #194: examine workflow for Bloodhound site
#194: examine workflow for Bloodhound site
-----------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Keywords: |
-----------------------+--------------------
At the moment tickets end up being assigned for long periods, not really
reflecting their state properly. This makes it hard for potential
contributors to really know if a ticket could be usefully looked at by
them. It also makes it hard for reviewers/committers to know that there is
something to do.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by jdreimann):
I can think of a few things that could help here, some immediate, some
longer term:
1. People shouldn't assign tickets to themselves unless they are planning
to work on them in the near future -> it's not a landgrab.
1. Purposefully leave some low priority, easy issues untouched and add
them to a section on the BloodhoundContributing page for newcomers to pick
up. This requires little maintenance as closed issues will be shown with a
strikethrough, so won't have to frequently be removed.
1. Estimating the work required for a ticket, even as a rough
approximation like '''I''' = low, '''II''' = med, '''III''' = high, but
preferably some ''''x''' hours' value.
1. The status of tickets is currently either 'new', 'assigned', 'accepted'
or 'resolved' and 're-opened' as far as I can tell. In reality something
like this happens: 'new', 'work in progress', 'pending review',
'resolved'. (Work usually means code). Matching this more closely and
providing better control to move between states would help.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:1>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
I don't see a particular advantage to declaring tickets that are paused as
different to any other with no owner. The new label may be a little
unfortunate but as a shorthand for unassigned, it is probably good enough
for now.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:12>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner:
Type: task | Status: assigned
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by gjm):
* status: needinfo => assigned
Comment:
yes.. appears you are right. If it is a problem with the workflow
definition, it should be sorted here. If it is a bug, this will probably
need a new ticket (and a look to see if there is an upstream ticket).
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:22>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner: gjm
Type: task | Status: review
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by olemis):
* milestone: => Unscheduled
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:19>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner: gjm
Type: task | Status: review
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by olemis):
* keywords: => bh_workflow
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:18>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by jdreimann):
2. I like the keyword based approach. What I wanted to say by untouched is
that we leave those tickets alone, other than with helpful comments and
hints for those that will pick them up -> not resolve the tickets. Showing
them in the Dashboard when not logged in would work well in our use case,
but maybe not in a general one for Bloodhound? Not sure.
3. So a more abstract '''I''' / '''II''' / '''III''' approach may work
better?
4. That's why I didn't call it code. debates, wireframes and mockups also
fall into this category.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:4>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
Oh, perhaps for we might want to have helpme tickets prominent on the
Dashboard too, particularly for those who do not have an account
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:3>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
I think I would like to start from an example workflow that should only
need some tweaking to get what we need. So I suggest we start with the
opensource-workflow example which is represented by the following diagram:
[[Image(opensource-workflow.png)]]
If we add a review state, and possibly a testing state with appropriate
transitions, would we have enough for our needs?
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:9>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Olemis Lang <ol...@gmail.com>.
Recently I noticed some weird transitions while using new workflow .
Actual sequence was
1. #195 put into needsinfo status owner => jdreimann
2. #195 put into assigned status owner => <empty>
(even if input box = olemis)
3. #195 put into assigned status owner => olemis
(review action not available :'( ... )
4. #195 put into review status owner => jdreimann
The issue is somewhere between transitions (2) or (3) . I was hoping
to be do it like this
1. #195 put into needsinfo status owner => jdreimann
2. #195 put into assigned status owner => olemis
3. #195 put into review status owner => jdreimann
what d'u think ?
On 10/31/12, Apache Bloodhound <bl...@incubator.apache.org> wrote:
> #194: Examine workflow for Bloodhound site
> ------------------------+--------------------
> Reporter: gjm | Owner: gjm
> Type: task | Status: review
> Priority: major | Milestone:
> Component: siteadmin | Version:
> Resolution: | Keywords:
> ------------------------+--------------------
> Changes (by gjm):
>
> * status: accepted => review
>
>
> Comment:
>
> Work complete, waiting on feedback.
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:16>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound (incubating) issue tracker
>
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: gjm
Type: task | Status: review
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Changes (by gjm):
* status: accepted => review
Comment:
Work complete, waiting on feedback.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:16>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+----------------------
Reporter: gjm | Owner: gjm
Type: task | Status: accepted
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+----------------------
Changes (by gjm):
* owner: nobody => gjm
* status: new => accepted
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:15>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner: gjm
Type: task | Status: assigned
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by gjm):
* status: review => assigned
Comment:
Well.. may as well test:
1. #194 -> review failed - assign to gjm
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:20>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by olemis):
It has a lot of potential . I think it won't hurt to try it for a while .
And you ?
:)
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:10>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by jdreimann):
Replying to [comment:6 olemis]:
> Replying to [comment:1 jdreimann]:
> > I can think of a few things that could help here, some immediate, some
longer term:
> I welcome all these suggestions, yes . Especially sometimes it's a bit
hard for me to determine assigned tickets having pending patches , for
instance .
I agree. My suggestion for this is the 'pending review' status.
> > 2. The status of tickets is currently either 'new', 'assigned',
'accepted' or 'resolved' and 're-opened' as far as I can tell. In reality
something like this happens: 'new', 'work in progress', 'pending review',
'resolved'. (Work usually means code). Matching this more closely and
providing better control to move between states would help.
>
> The only thing I'd like to add is that sometimes between 'work in
progress', and 'pending review' , ticket enters an state in which nothing
can be done until something happens
Your examples describe a blocker issue in my opinion, some internal and
some 3rd party. Internal means the ticket that is blocking progress should
be changed to 'blocker', external means we should add a ticket type that
is 'External' or '3rd party' and assign it a 'blocker' status if it's a
blocker.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:7>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by olemis):
Actually what I don't like is that there's a single state with no owner
(i.e. `new` ) . Something like ''deferred'' or ''paused'' would be nice to
have to make a difference between new tickets and started but inactive
tickets . Beyond that , it seems to me that it's fine .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:11>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Olemis Lang <ol...@gmail.com>.
On 11/8/12, Joachim Dreimann <jo...@wandisco.com> wrote:
> On 7 November 2012 06:34, Apache Bloodhound <
> bloodhound-dev@incubator.apache.org> wrote:
>
[...]
>>
>> Recently I noticed some weird transitions while using new workflow .
>> Sequence was
>>
>> 1. #195 put into needsinfo status owner => jdreimann
>> 2. #195 put into assigned status owner => <empty>
>> (even if input box = olemis)
>> 3. #195 put into assigned status owner => olemis
>> (review action not available :'( ... )
>> 4. #195 put into review status owner => jdreimann
>>
>
> Your suggestion seems reasonable to me, what stops this from working that
> way currently?
>
AFAICS in step (2) username in the input box is ignored and ticket
owner field is set to an empty string once action is applied . Hence
the need for redundant step (3) above .
Besides ... I wonder ... is review action available for ticket owner only ?
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Joachim Dreimann <jo...@wandisco.com>.
Your suggestion seems reasonable to me, what stops this from working that
way currently?
- Joe
On 7 November 2012 06:34, Apache Bloodhound <
bloodhound-dev@incubator.apache.org> wrote:
> #194: Examine workflow for Bloodhound site
> ------------------------+--------------------
> Reporter: gjm | Owner: gjm
> Type: task | Status: review
> Priority: major | Milestone:
> Component: siteadmin | Version:
> Resolution: | Keywords:
> ------------------------+--------------------
>
> Comment (by olemis):
>
> Recently I noticed some weird transitions while using new workflow .
> Sequence was
>
> 1. #195 put into needsinfo status owner => jdreimann
> 2. #195 put into assigned status owner => <empty>
> (even if input box = olemis)
> 3. #195 put into assigned status owner => olemis
> (review action not available :'( ... )
> 4. #195 put into review status owner => jdreimann
>
> The issue is somewhere between transitions (2) or (3) . I was hoping to be
> do it like this
>
> 1. #195 put into needsinfo status owner => jdreimann
> 2. #195 put into assigned status owner => olemis
> 3. #195 put into review status owner => jdreimann
>
> what d'u think ?
>
> '''PS:''' the same comment has been posted to bh-dev ML ... I just thought
> this had to be mentioned here instead ... jftr
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:17>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound (incubating) issue tracker
>
--
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
*
*
*Transform your software development department. Register for a free SVN
HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: gjm
Type: task | Status: review
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by olemis):
Recently I noticed some weird transitions while using new workflow .
Sequence was
1. #195 put into needsinfo status owner => jdreimann
2. #195 put into assigned status owner => <empty>
(even if input box = olemis)
3. #195 put into assigned status owner => olemis
(review action not available :'( ... )
4. #195 put into review status owner => jdreimann
The issue is somewhere between transitions (2) or (3) . I was hoping to be
do it like this
1. #195 put into needsinfo status owner => jdreimann
2. #195 put into assigned status owner => olemis
3. #195 put into review status owner => jdreimann
what d'u think ?
'''PS:''' the same comment has been posted to bh-dev ML ... I just thought
this had to be mentioned here instead ... jftr
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:17>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Joachim Dreimann <jo...@wandisco.com>.
That's fine, I think your proposed workflow is enough of an improvement
that we should go for it. We can revise/iterate/pivot later.
Cheers,
Joe
On 31 October 2012 01:03, Gary Martin <ga...@wandisco.com> wrote:
> For me, one question would be whether we need two states to indicate
> accepted and in progress work but I suppose we can revise this again later.
> So, unless there are objections, I will attempt to set this to be the new
> workflow later.
>
> Incidentally, I think it might be good to look at a plugin in this area
> for adding the potential for actions that should result in assignment to a
> previous owner. It feels like this is lacking from the standard workflow
> abilities for the "provide info" actions in particular. I think we can live
> without it for now though.
>
> Cheers,
> Gary
>
> Gary Martin <ga...@wandisco.com> wrote:
>
> >I've been looking at issues around this for a while so it is natural to
> >
> >try to adjust the workflow for issues.apache.org/bloodhound. I am not
> >suggesting that this is a workflow that we want for others necessarily;
> >
> >this is strictly for our needs. I'm trying to get something that is not
> >
> >too complicated but adds a few features we might want.
> >
> >Cheers,
> > Gary
> >
> >On 30/10/12 18:20, Apache Bloodhound wrote:
> >> #194: Examine workflow for Bloodhound site
> >> ------------------------+--------------------
> >> Reporter: gjm | Owner: nobody
> >> Type: task | Status: new
> >> Priority: major | Milestone:
> >> Component: siteadmin | Version:
> >> Resolution: | Keywords:
> >> ------------------------+--------------------
> >>
> >> Comment (by gjm):
> >>
> >> I've been looking into various issues around workflow. One thing
> >that the
> >>
> >[https://issues.apache.org/bloodhound/attachment/ticket/194/opensource-
> >> workflow.png opensource workflow] is missing for us is capturing
> >aspects
> >> of review/testing.
> >>
> >> I am not entirely sure that we need anything specific for testing
> >so I
> >> suggest that we just have a generic review step that is re-entrant
> >in case
> >> anyone wants to record specific testing to be done by another user.
> >Also,
> >> I am not proposing that there should be anything to force the
> >ticket to go
> >> through these steps - it is more so that the ticket can be in an
> >> appropriate state for others to pick up on.
> >>
> >> So, the rules I am suggesting at the moment are in the
> >> attachment:new_workflow.ini which should look something like this
> >as a
> >> graph:
> >> [[Image(opensource workflow with review.png)]]
> >>
> >> The graph misses a few features like where there is change of
> >ownership
> >> which I have added to the changes to the infoneeded and review
> >states for
> >> the moment.
> >>
> >> -- Ticket URL:
> >> <https://issues.apache.org/bloodhound/ticket/194#comment:13> Apache
> >> Bloodhound <https://issues.apache.org/bloodhound/> The Apache
> >> Bloodhound (incubating) issue tracker
>
>
--
Joe Dreimann
UX Designer | WANdisco <http://www.wandisco.com/>
*
*
*Transform your software development department. Register for a free SVN
HealthCheck <http://go.wandisco.com/HealthCheck-Sig.html> *
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Gary Martin <ga...@wandisco.com>.
For me, one question would be whether we need two states to indicate accepted and in progress work but I suppose we can revise this again later. So, unless there are objections, I will attempt to set this to be the new workflow later.
Incidentally, I think it might be good to look at a plugin in this area for adding the potential for actions that should result in assignment to a previous owner. It feels like this is lacking from the standard workflow abilities for the "provide info" actions in particular. I think we can live without it for now though.
Cheers,
Gary
Gary Martin <ga...@wandisco.com> wrote:
>I've been looking at issues around this for a while so it is natural to
>
>try to adjust the workflow for issues.apache.org/bloodhound. I am not
>suggesting that this is a workflow that we want for others necessarily;
>
>this is strictly for our needs. I'm trying to get something that is not
>
>too complicated but adds a few features we might want.
>
>Cheers,
> Gary
>
>On 30/10/12 18:20, Apache Bloodhound wrote:
>> #194: Examine workflow for Bloodhound site
>> ------------------------+--------------------
>> Reporter: gjm | Owner: nobody
>> Type: task | Status: new
>> Priority: major | Milestone:
>> Component: siteadmin | Version:
>> Resolution: | Keywords:
>> ------------------------+--------------------
>>
>> Comment (by gjm):
>>
>> I've been looking into various issues around workflow. One thing
>that the
>>
>[https://issues.apache.org/bloodhound/attachment/ticket/194/opensource-
>> workflow.png opensource workflow] is missing for us is capturing
>aspects
>> of review/testing.
>>
>> I am not entirely sure that we need anything specific for testing
>so I
>> suggest that we just have a generic review step that is re-entrant
>in case
>> anyone wants to record specific testing to be done by another user.
>Also,
>> I am not proposing that there should be anything to force the
>ticket to go
>> through these steps - it is more so that the ticket can be in an
>> appropriate state for others to pick up on.
>>
>> So, the rules I am suggesting at the moment are in the
>> attachment:new_workflow.ini which should look something like this
>as a
>> graph:
>> [[Image(opensource workflow with review.png)]]
>>
>> The graph misses a few features like where there is change of
>ownership
>> which I have added to the changes to the infoneeded and review
>states for
>> the moment.
>>
>> -- Ticket URL:
>> <https://issues.apache.org/bloodhound/ticket/194#comment:13> Apache
>> Bloodhound <https://issues.apache.org/bloodhound/> The Apache
>> Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Gary Martin <ga...@wandisco.com>.
I've been looking at issues around this for a while so it is natural to
try to adjust the workflow for issues.apache.org/bloodhound. I am not
suggesting that this is a workflow that we want for others necessarily;
this is strictly for our needs. I'm trying to get something that is not
too complicated but adds a few features we might want.
Cheers,
Gary
On 30/10/12 18:20, Apache Bloodhound wrote:
> #194: Examine workflow for Bloodhound site
> ------------------------+--------------------
> Reporter: gjm | Owner: nobody
> Type: task | Status: new
> Priority: major | Milestone:
> Component: siteadmin | Version:
> Resolution: | Keywords:
> ------------------------+--------------------
>
> Comment (by gjm):
>
> I've been looking into various issues around workflow. One thing that the
> [https://issues.apache.org/bloodhound/attachment/ticket/194/opensource-
> workflow.png opensource workflow] is missing for us is capturing aspects
> of review/testing.
>
> I am not entirely sure that we need anything specific for testing so I
> suggest that we just have a generic review step that is re-entrant in case
> anyone wants to record specific testing to be done by another user. Also,
> I am not proposing that there should be anything to force the ticket to go
> through these steps - it is more so that the ticket can be in an
> appropriate state for others to pick up on.
>
> So, the rules I am suggesting at the moment are in the
> attachment:new_workflow.ini which should look something like this as a
> graph:
> [[Image(opensource workflow with review.png)]]
>
> The graph misses a few features like where there is change of ownership
> which I have added to the changes to the infoneeded and review states for
> the moment.
>
> -- Ticket URL:
> <https://issues.apache.org/bloodhound/ticket/194#comment:13> Apache
> Bloodhound <https://issues.apache.org/bloodhound/> The Apache
> Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
I've been looking into various issues around workflow. One thing that the
[https://issues.apache.org/bloodhound/attachment/ticket/194/opensource-
workflow.png opensource workflow] is missing for us is capturing aspects
of review/testing.
I am not entirely sure that we need anything specific for testing so I
suggest that we just have a generic review step that is re-entrant in case
anyone wants to record specific testing to be done by another user. Also,
I am not proposing that there should be anything to force the ticket to go
through these steps - it is more so that the ticket can be in an
appropriate state for others to pick up on.
So, the rules I am suggesting at the moment are in the
attachment:new_workflow.ini which should look something like this as a
graph:
[[Image(opensource workflow with review.png)]]
The graph misses a few features like where there is change of ownership
which I have added to the changes to the infoneeded and review states for
the moment.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:13>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
2. Untouched as in not actively pursued does not really make sense.
However, that tickets are low priority should cause those to be tackled
last within a given milestone.
- One thing I would not mind seeing at the moment is people beyond the
main contributors taking on tickets in future milestones.
3. No, I think it is a bit too subjective overall. There are always going
to be the 'quickwin' tickets of course if we think to raise enough of
them.
4. investigation prior to coding, yes.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:5>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner:
Type: task | Status: needinfo
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by gjm):
* status: assigned => needinfo
* owner: gjm =>
Comment:
2. #194 -> info request - assign to olemis
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:21>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
2. I think we could probably just make use of a helpus (or similar)
keyword and provide a query like this:
query:status=new|reopened&keywords=helpus. Actually, I wonder if leaving
tickets untouched is helpful. We really just need a lot more and perhaps a
good understanding of how they interrelate.
3. Problem there is that different people will have different abilities
and so a number of hours work might put some off if they don't think that
they can do it in the stated time.
4. Work should not imply code. There is more to tickets than coding.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner: gjm
Type: task | Status: closed
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: fixed | Keywords: bh_workflow
------------------------+-------------------------
Changes (by gjm):
* status: accepted => closed
* resolution: => fixed
Comment:
Fixed a few stupid mistakes - for some reason there were doubled-up
operations for some of the actions.
I'm also going to allow the change to review direct from assigned for now.
We may need to look at more advanced workflow for proper needinfo
transitions so that we can revert to a previous state and previous owner.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:24>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+-------------------------
Reporter: gjm | Owner: gjm
Type: task | Status: accepted
Priority: major | Milestone: Unscheduled
Component: siteadmin | Version:
Resolution: | Keywords: bh_workflow
------------------------+-------------------------
Changes (by gjm):
* owner: => gjm
* status: assigned => accepted
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:23>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
Replying to [comment:7 jdreimann]:
> Replying to [comment:6 olemis]:
> > Replying to [comment:1 jdreimann]:
> > > I can think of a few things that could help here, some immediate,
some longer term:
> > I welcome all these suggestions, yes . Especially sometimes it's a bit
hard for me to determine assigned tickets having pending patches , for
instance .
>
> I agree. My suggestion for this is the 'pending review' status.
>
> > > 2. The status of tickets is currently either 'new', 'assigned',
'accepted' or 'resolved' and 're-opened' as far as I can tell. In reality
something like this happens: 'new', 'work in progress', 'pending review',
'resolved'. (Work usually means code). Matching this more closely and
providing better control to move between states would help.
> >
> > The only thing I'd like to add is that sometimes between 'work in
progress', and 'pending review' , ticket enters an state in which nothing
can be done until something happens
>
> Your examples describe a blocker issue in my opinion, some internal and
some 3rd party. Internal means the ticket that is blocking progress should
be changed to 'blocker', external means we should add a ticket type that
is 'External' or '3rd party' and assign it a 'blocker' status if it's a
blocker.
I would have no particular reason to say that we would need to raise a
ticket about an external blocker to a tickets progress. It would depend on
whether someone else required a ticket to work with a third party to
unblock the issue. The main thing is that the ticket that is blocked notes
the block and references any ticket that deals with it.
So, that just leaves the state that the ticket is in - the ticket might be
expected to remain owned by the same person but it should change to a
"requires info" state or similar. This really depends on the amount of
work that has been achieved up to that point and whether the owner will be
able to take up the ticket again soon after the blocking issue is cleared.
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:8>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Gary Martin <ga...@wandisco.com>.
OK, as noted in the ticket I tweaked about and then removed the started
state for now. Let me know if you think that the distinction between
accepted and started states really matters.
Cheers,
Gary
On 31/10/12 13:46, Apache Bloodhound wrote:
> #194: Examine workflow for Bloodhound site
> ------------------------+--------------------
> Reporter: gjm | Owner: nobody
> Type: task | Status: new
> Priority: major | Milestone:
> Component: siteadmin | Version:
> Resolution: | Keywords:
> ------------------------+--------------------
>
> Comment (by gjm):
>
> With use I noted a few missing actions ({{{reopen}}} and {{{failreview}}})
> and a few problems with action labels when there is also a potential
> change of ownership which should now be corrected. Also the using
> {{{started}}} in addition to {{{accepted}}} still felt like a bit too much
> of a complication. It is a bit easier to add than take away states (in
> some senses anyway) and so I suggest that it is removed, at least
> temporarily.
>
> So, this is the new workflow for now:
>
> attachment:new_workflow_current.ini
> [[Image(current workflow.png)]]
>
> -- Ticket URL:
> <https://issues.apache.org/bloodhound/ticket/194#comment:14> Apache
> Bloodhound <https://issues.apache.org/bloodhound/> The Apache
> Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by gjm):
With use I noted a few missing actions ({{{reopen}}} and {{{failreview}}})
and a few problems with action labels when there is also a potential
change of ownership which should now be corrected. Also the using
{{{started}}} in addition to {{{accepted}}} still felt like a bit too much
of a complication. It is a bit easier to add than take away states (in
some senses anyway) and so I suggest that it is removed, at least
temporarily.
So, this is the new workflow for now:
attachment:new_workflow_current.ini
[[Image(current workflow.png)]]
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:14>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #194: Examine workflow for Bloodhound site
(was: examine workflow for Bloodhound site)
Posted by Apache Bloodhound <bl...@incubator.apache.org>.
#194: Examine workflow for Bloodhound site
------------------------+--------------------
Reporter: gjm | Owner: nobody
Type: task | Status: new
Priority: major | Milestone:
Component: siteadmin | Version:
Resolution: | Keywords:
------------------------+--------------------
Comment (by olemis):
<OT>
I was trying to follow this conversation and it's been hard in general .
Many times I had to scroll up to know was said before and connect it with
comment text , until I had to scroll once again because I forgot and had
no means to «refresh my RAM» quickly. Could we please use reply button
more often ? Especially in this kind of branchy conversations ... for the
sake of legibility ;).
This also makes me wonder that maybe we should have collapsible replies
plus (expand / collapse) all replies links/buttons .
</OT>
Replying to [comment:1 jdreimann]:
> I can think of a few things that could help here, some immediate, some
longer term:
I welcome all these suggestions, yes . Especially sometimes it's a bit
hard for me to know what assigned tickets have pending patches , for
instance .
> 1. People shouldn't assign tickets to themselves unless they are
planning to work on them in the near future -> it's not a landgrab.
Sometimes I've had the intention to start with a ticket but something
happens ... please read below ;)
[...]
> 2. The status of tickets is currently either 'new', 'assigned',
'accepted' or 'resolved' and 're-opened' as far as I can tell. In reality
something like this happens: 'new', 'work in progress', 'pending review',
'resolved'. (Work usually means code). Matching this more closely and
providing better control to move between states would help.
The only thing I'd like to add is that sometimes between 'work in
progress', and 'pending review' , ticket enters an state in which nothing
can be done until something happens (e.g. another ticket has to be closed,
green light to a decision, pending discussion with trac-dev et al.,
research, improvements needed, trac-hacks.org down ... and alike) . Maybe
it's worth having a separate status for this (i.e. remove owner , but
ticket is not technically ''new'' ;) . This is related to 1 above , btw .
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/194#comment:6>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker