879385 - [story] custom, editable field for the purposes of requirements tracking

Status: RESOLVED FIXED

(Tracking :: User Story, defect)

Description

[Caitlin Galimidi [:c8o]]

Hey there product managers - I'd like to check the feasibility for an editable field in the "Tracker" product, permanently placed above the attachments and discussion, so we can edit / finalize our user stories and requirements and set up a rudimentary tracking system. I realize we're getting a tools some time in the future, but I'd like to see if we can make something work for us in the meantime.

What is the value to you of the story below?



As a product manager I'd like to be able to enter my user story into an editable text field in the "Tracker" product, in a placement on the page permanently above the bug comments and requirements discussions so that it is always prominent & visible. This will enable me to track user story delivery in bugzilla.

As a program manager, I'd like to be able to enter my business requirement into an editable text field in the "Tracker" product, in a placement on the page permanently above the bug comments and requirements discussions so that it is always prominent and visible. This will enable me to track my project scope in bugzilla.

Workflow:
1 - create user story
2 - share with dev, ux, qa, program team members etc
3 - gather comments on the bug
4 - adjust / finalize story
5 - review with devs
6 - devs create dev tasks and tech requirements as usual, in their own product areas of bugzilla

This is a request for an editable field in the "Tracker" product of Bugzilla 
Placement. This will enable requirements tracking / editing **while we are waiting** for the requirements tracking tool to be put into use.

OUT OF SCOPE
It does NOT request any additional functionality (like "locking" this edit field once final story is published or restricting that field to only certain users). We'd need to be good product and program folks and not touch each other's work product without agreement.

Comment 1

[David Bialer [:dbialer]]

In this case, we would like to have a custom field as a Large Text Field tied to a specific product group, in this case, "Tracker".  This field should be visible at bug creation.

Really asking for the ability to have the functionality of add/deleting custom field http://www.bugzilla.org/docs/3.2/en/html/custom-fields.html configurable at the product level.

Comment 2

[David Bialer [:dbialer]]

I would like to add my use cases:
1. I would like to be able to put in a user story, use case, or requirement and modify it, with changes tracked, as it is discussed and refined so it is clear that the refinements are not happening through comments, which get lost in a discussion.

Comment 3

[vkrishnamoorthy]

Similar use case as David above. Having an editable text area for the tracker project gives the flexibility to create a place holder bug for an user story and iterate over the use cases as we tease out the requirements.
Having the ability to track the changes will be great as we can see the how the user story morphed over time, our initial assumptions and the final requirements

Comment 4

[Caitlin Galimidi [:c8o]]

Hey there Clint - 
Been awhile since we checked in on this. Do you have an update from your team on feasibility for adding this field in Product=Tracker of b'zila?

Comment 5

[cmtalbert]

(In reply to Caitlin Galimidi from comment #4)
> Hey there Clint - 
> Been awhile since we checked in on this. Do you have an update from your
> team on feasibility for adding this field in Product=Tracker of b'zila?

Hi Caitlin,

Sorry for the lack of update.  The request is completely feasible, in fact it's pretty straightforward to implement. The issue here (and the holdup) is that we are trying to not add *any* new columns to the bugs table in the bugzilla database.  The bugs table has grown with abandon (everything that can potentially be displayed on a bug page like this one is kept in that table) over the last few years as we've added all kinds of tracking flags to accommodate the Firefox rapid release schedule. We've grown to a size now where we are hitting database performance limits on querying the bugs table.  In plain English, this means every time we add a column to this table at this point, we slow down how quickly we can display a bug on bugzilla.

Fortunately, we have a fix for this column issue, and it is ready to go (it's called the Tracking Flags migration). We have to take bugzilla down to do a fix of this magnitude to the database, and IT scheduled our downtime for the last weekend of the quarter. At that downtime, we'll perform the tracking flags migration. Once that's done, we will be able to knock out your request and push it about two weeks later. We push small updates like this to bugzilla every thursday.

So as for an ETA, we're looking at roughly mid-October. I'm sorry it's taken so long.  Once we get closer to performing the tracking flags migration, Mark (cc'd) will be able to give you a more up to date answer.

Comment 6

[Axel Kratel]

So this feature appears to be available under product "User Stories" and component "tracking". We are currently storing user stories in BugZilla for tools but we're using tracking bugs to track them. How difficult would it be to have this feature on a component for devtools called "user stories"?

Comment 7

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Quick question: what if I want this field to show up in a "Firefox => Developer Tools: User Stories" component ( eg under the Firefox product ). Is that possible? I'm not crazy about having my user stories in a different product completely from where the rest of the bugs are.

Comment 8

[:glob ✱]

this has been fixed and deployed by bug 895687.

(In reply to Jeff Griffiths (:canuckistani) from comment #7)
> Quick question: what if I want this field to show up in a "Firefox =>
> Developer Tools: User Stories" component ( eg under the Firefox product ).

yes, file a bmo::administration bug requesting that.

the code will need some tweaking to support component level visibility (currently it's product level), but i don't expect that to be too painful.

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Byron Jones ‹:glob› from comment #8)
...
> the code will need some tweaking to support component level visibility
> (currently it's product level), but i don't expect that to be too painful.

Okay - I think Axel has logged the bug.