868080 - custom field for Bugzilla-Kanban support

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Jake Maul [:jakem]]

We are looking to start using a KanbanBoard interface to Bugzilla...

https://github.com/EvanOman/KanbanBoard (we'll fork for any local changes)
https://wiki.mozilla.org/Bugzilla:Addons#Client_libraries_for_the_Bugzilla_Webservices.2FREST_API

In order to use this, it needs a custom field to maintain the status of each affected bug... namely, which kanban column the bug is in.

This would be a drop-down field, with the following values:
Backlog
Archive
Limbo
Ready
Research?Doing
Research?Done
In Progress
Done

The "?" is a separator character that has special meaning in the app (sub-column)... we can use a different character if '?' is a problem. The field name is irrelevant... I can change the code easily to use a different name, so you don't need to feel constrained by this. Since other people might theoretically want to use KanbanBoard, but might want different fields, it kinda makes sense (in my mind) to give it a unique name.

I'm not sure if we can easily alter it to use a different functionality altogether (whiteboard, keywords, etc). That would require more complicated code changes, and I'd need to bring in someone to look it over. But, if a custom field is a no-go, we can look into this. (Alternatively if you have the cycles to scan it and explain roughly what would have to change, that might help a lot too.)


We would only need this to support the "mozilla.org" product, "Server Operations: Web Operations" component. Someday when we get around to creating a product specifically for IT/Operations, that might change... but that's not really on the radar right now.

Comment 1

[Reed Loden [:reed]]

Other teams are using the status whiteboard for this exact same purpose. Any reason why you can't do the same thing? Custom fields are very cumbersome and cause problems, so if we can get away with not using it for a one-off, that would be awesome.

Comment 2

[David Lawrence [:dkl]]

(In reply to Reed Loden [:reed] from comment #1)
> Other teams are using the status whiteboard for this exact same purpose. Any
> reason why you can't do the same thing? Custom fields are very cumbersome
> and cause problems, so if we can get away with not using it for a one-off,
> that would be awesome.

Reed has a good point. As a rule we try to hold off on creating new custom fields where other fields we already can satisfy the need. We could also add the new values as keywords which would satisfy the drop down requirement (autocompletion for the keywords field). Maybe prepend the Kanban related keywords with 'KB: '. Just suggesting.

Using the whiteboard would require the user to make sure they enter the word(s) properly so that the search will pull in the proper bugs. Keywords or a custom field would help with that.

Not trying to open the flood gate for new custom field requests, but once we move off of 
using custom fields for tracking flags (bug 750742), adding custom fields will not be as much of a pain as Reed noted.

dkl

Comment 3

[Jake Maul [:jakem]]

The interface is AJAX-y and allows dragging cards around. User's wouldn't be typing these things in, so typo's and autocompletion are not a concern.

The problem is, I don't have dev resources to re-code this to use something other than a field. At a glance (though I am no javascript or Bugzilla XMLRPC expert), it appears as though it would be a rather extensive rewrite.

Is there an ETA on bug 750742? I'll need to get an estimate on building a new app (or modifying this one, though I suspect if a webdev sees this they'll run screaming and demand a rewrite) and comparing.

Comment 4

[:glob ✱]

i agree with dkl and reed that using the whiteboard or keywords is the approach you should be taking (fwiw keywords will be much faster than using the whiteboard).

i have concerns about this, and not only from the technical overhead which adding custom fields carries -- there's a ux cost, especially if we start adding fields for more than just this one external system.

i'll raise this for discussion in our bmo-team meeting next week; perhaps there's things we can do which will make it easier for the changes to be made to kanbanboard.


hrm, it looks like kanbanboard polls bugzilla every 30 seconds for updates
https://github.com/EvanOman/KanbanBoard/blob/master/js/kanban.js#L5290
this is an unacceptable polling interval and needs to be at least 5 minutes.


how many people are in the web-ops team?
do you have expected time frame for when you'd like to start using this?

> Is there an ETA on bug 750742?

it's the highest priority project we have right now; however a full migration is at least a month away.  to paint some perspective around this, currently we have 155 custom fields on bmo, with each field being a column on the bugs table, resulting in a very very wide table.

Comment 5

[David Lawrence [:dkl]]

(In reply to Jake Maul [:jakem] from comment #3)
> The problem is, I don't have dev resources to re-code this to use something
> other than a field. At a glance (though I am no javascript or Bugzilla
> XMLRPC expert), it appears as though it would be a rather extensive rewrite.

Is the source somewhere we can see what exactly the Bugzilla plugin for Kanban is doing and how it is making changes? technically changing the value of a custom field is not much different than changing the value of any other Bugzilla field such as whiteboard and/or keywords. BzAPI and also BMO's native WebService API supports changing of those fields easily. It could be simple as a few lines of code change on your end. But if we could see it, it would make it easier to judge that.

Thanks
dkl

Comment 6

[Jake Maul [:jakem]]

The source is here: https://github.com/EvanOman/KanbanBoard

That's upstream... we would fork it under github.com/mozilla before making any real changes (I have a few trivial ones in my local clone, but haven't pushed them anywhere).

Comment 7

[Jake Maul [:jakem]]

Forgot to answer an earlier question: WebOps is currently 5 people, but I would bank on more like 10-15 active users (growth, management, webdev/stakeholders, PMs, etc). I know there's also some interest outside of WebOps for such an app... if it was successful, I wouldn't be surprised to see other teams want something similar.

Comment 8

[Reed Loden [:reed]]

Other teams at Mozilla already use Kanban for task management. Have you looked into the tools they use? Looks like they are wanting to do something similar... Maybe work with them to come up with somebody that works for everybody?

https://blog.mozilla.org/webdev/2013/04/22/kanban-for-mdn-development/
https://github.com/groovecoder/kanbugs
https://mdn.kanbanery.com/projects/32137/board/?key=0383ba5f05e165e0eb19d8476654fe9775ce2ca7

Comment 9

[Jake Maul [:jakem]]

That is precisely what I'm doing outside of this bug. However, with respect to those things...

I've already spoken to groovecoder about kanbugs... it's highly MDN-specific, and specific to MDN-from-months-ago, not current. It's also not as responsive as kanbanery: https://blog.mozilla.org/webdev/files/2013/04/kanbugs_screenshot.png. In particular, I believe you cannot really manipulate things within the interface. It's purely a read-only display.


Kanbanery is a 3rd-party tool and does not have native bugzilla integration. Cards and bugs are maintained separately. There is speculative work to build an API bridge between them, but there's no concrete plans there yet, and the plans that do exist are one-way. As in, you make a bug, then run a script by hand, and the script will create a matching card. Manipulating cards would not affect bugs.

It's possible this could be expanded and improved. My comment 3 above alludes to this, and I'm pursuing a project on this front. At some level it stops making sense trying to integrate bugzilla with a 3rd party tool and just write our own interface in the first place... so the project may be an API bridge connecting bugzilla with some 3rd party kanban tool, or it may be a whole new kanban interface that uses bugzilla directly.


I'm actively engaged in discussions with MDN, Engagement, Webtools, and other IT/webdev teams on how to do kanban + bugzilla. Some of them already do *something*, others are interested in starting. Nobody that I've talked to has the silver bullet.

Comment 10

[Mark Côté [:mcote]]

Apologies for letting this languish for so long, but in the absence of any follow-ups, and judging from the presence of kanban-related whiteboard notes in many bugs, I'm guessing this is no longer needed.  Reopen if that isn't the case.