Tools Meeting wk03 2016

Agustin Benito Bethencourt agustin.benito at
Tue Jan 19 03:50:59 EST 2016


On 18/01/16 20:54, Andersson, Gunnar wrote:
> Hi Agustin
> On Mon, 2016-01-18 at 16:01 +0100, Agustin Benito Bethencourt wrote:
>> Hi,
>> On 18/01/16 14:14, Andersson, Gunnar wrote:
>>> On Mon, 2016-01-18 at 13:52 +0100, Agustin Benito Bethencourt wrote:
>>>> Hi,
>>>> Tools meeting will take place on Wednesday Jan 20th at 10:00 UTC
>>>> through
>>>> #automotive IRC (freenode), as usual.
>>>> The main goal of this meeting are:
>>>> * To go through the previous actions/tasks and update them.
>>>> * To define what we will focus on during 2016Q1
>>>> Any other topic for this week?
>>> I propose to also look at the separate Go Server Kanban board [2].
>>> I can introduce it.
>>>> Check the Tools Team Kanban Board[1]
>>> I think an audio call and WebEx might help.
>>>> I would appreciate if you go through the tasks assigned to you and
>>>> update them before the meeting. I have place them In Review State so
>>>> we
>>>> can go through them and move them into the right column/state if there
>>>> is somebody who takes ownership and is able to define a deadline
>>>> (aprox.) for it.
>>> Some already had ownership.  I don't see the need to move those that
>>> someone else put in ToDo (probably because they aim to do them)
>>> back to review again, but that's a minor issue.
>> Most are assigned to me because they do not have an owner. Other tasks
>> has been there for some time now. Others haven't moved for quite a bit.
>> In fact, the tasks has been the way of taking notes of the desired
>> actions. I would like to make sure we update them before moving on.
>>> A bigger problem is that JIRA automatically reassigns them to you
>>> (or to whomever moves them in the Kanban board) so that the original
>>> assignment is lost.  That is not really desirable and I wonder if JIRA
>>> could be reconfigured to not do that.  The actual state change and who
>>> did that would still be logged but automatic reassignment could be
>>> avoided I hope.
>> A task always has a default assignee, which has been traditionally the
>> Chair. I am fine with this as long as the task are in the Review stage
>> (discussion). Once they go to the backlog (Todo) they should have a
>> different owner. Once they move to In progress, they should have a
>> deadline.
> I agree with all you're saying but I'm not seeing it as an answer to
> what I wrote?
> Do you disagree with what I wrote or did you not see/understand?
> I am saying JIRA also assigns them to you as soon as you move them
> from one column to another... Or did you assign them all to yourself
> explicitly?

Paul assigned to me every issue that was assigned to him because it had 
no owner. It was intentional.

> I saw this happen for myself, when I moved a card it seemed to be
> assigned to me.

It happens when moving the issues to the Review state. This is a 
behaviour by default of JIRA, that can be changed, I believe.

>> With the above simple rules I should be able to focus the follow up
>> effort only on those actions that are in progress. And look for
>> contributors only for those which are in the backlog.
>> But that is just my idea. I am open to discuss others at the meeting.
> I have no problem with that.  What I said was only that:
> 1. There were some topics that were already in ToDo because
> someone had already decided that they should be done.

We will confirm it then.

> 2. Some topics were assigned to people and they could have stayed
> assigned to those people.  It had nothing to do with the default
> assignee for NEW tasks.

I will go through the history of each task moved to review state and 
assign it back to the one that should before the meeting.

>> What I would like is to make sure that we are realistic about what we > will/can do.
>> If a task do not have takers... we close it. We always can > re-open it.
> Sounds good but I'd like to discuss that strategy, because I see a need for
> an open visible backlog where anyone can take tasks, or simply as a way to
> track our wishlist.
> The needs for this might be different in different projects.  For GDP
> maintenance I can understand you may want to track
> more strictly only what the maintenance team can and intends to do?
> But also there I think tracking Todos that anyone can take on would be
> worthwhile.  We've discussed this before that an accessible todo-list
> that is independent of the current team is a best-practice for many OSS
> project.  It makes it easy for new contributors to take something easy
> off that list and start doing it.


> Best Regards
> - Gunnar
>>> Best Regards
>>> - Gunnar
>>>> [1]
>>>> &vie
>>>> w=detail&selectedIssue=TOOL-4
>>> [2]
>>> =5&v
>>> iew=detail
>>>> Best Regards

Agustin Benito Bethencourt
Principal Consultant - FOSS at Codethink
agustin.benito at

More information about the genivi-projects mailing list