2020-11-3 Meeting Notes

Implemented libraries are finding and reporting bugs, but those bugs may be tied to features that may not be developed yet.

Bug report UIDATIMP-655 - Data imports can get stuck at "Running" in the UI when they may actually have completed fully, partially, or not at all
 Vs. feature: UXPROD-2615 Ability to kill a long-running or errored data import

In general we shouldn't use bugs to raise visibility of bugs, but in this case it was so critical it made sense. It was a significant operational concern for two production libraries. AMB was able to pull it into the sprint and get it done - it was a rather small item.

AMB - likes using the bug route

Bug report: UICR-102 - User needs to be able to delete a course if either it has no items or has at least one other crosslisted course
Vs. feature: UXPROD-2594 - After an item has been associated with a Course - Sync item and inventory data

Cate - this one looks like a bug, if Thor had deemed this to be a new feature instead (or a bug blocked by a feature), we should close the bug as a duplicate of the feature.  If the institutions want to keep these bugs around, they can probably find a way to filter it out.  The group wants to do this so it doesn't get lost and it's a way to document a decision.

Kelly - as we go through these can we create a document for how to handle these?  Cate - good idea

AMB - To me, story is functionality (which might be addressing error situations) that the PO did not include in the user stories for the feature, either on purpose or inadvertently. Bugs are things that used to work, or are supposed to work, but don't. I agree that sometimes stories are needed to address requirement details that were perhaps missed in the initial implementation stories.  The developers don't define a bug as something that was missed in the story, it should be a new feature instead.

Tod - there won't be an obvious line, there will be gray areas

UIIN-1244 - Getting issue details... STATUS vs UXPROD-2712 - Getting issue details... STATUS

While this may seem like a bug to implementers, it isn't a bug to the dev team, as the desired functionality is either new or different than what was previously requested.  changed it to a story and linked it to feature 2712.

Tom - if we are claiming that a particular function is doable in FOLIO but it isn't, whether it's a mistake or something that was missed, if we start it over as a new feature it is hard on the institutions

Charlotte - we have timing problems, can't guarantee that the devs can get to everything in a certain time period

AMB - in search, if we had listed everything about search, such as punctuation skip, users assumed it would work that way but the devs never knew it was supposed to be in there

Cate - if it's critical, it can be a critical enhancement request - but can't guarantee that all of these will get done quickly.  Devs are evaluated on bug stats so it isn't fair to call something a bug if it really isn't one

Tod - need to be alert to unstated assumptions but that is very hard to do

Cate - teams have 40% of their time dedicated to bug fixes

Kelly - some of these bugs are foundational and other thing build on them

Paula - don't really want to see more than the 40% of bug work because the libraries going live next year don't want to see other dev work delayed

AMB - would like to see them as bugs and she'll work with the devs to figure out the best way to handle.  Is it a little bug or is it big enough to be a new feature?

856 match issue - it's a volume problem, not a bug with the 856 matching, but we've been saying for 2 years that search is crucial.  Nobody knew about this problem until using data import

Decisions -

If a PO wants to close a bug as a duplicate of a UXPROD features, implementers can track it as long as the label says "support" it will still show up on the support dashboard.  POs will consult the production libraries before making the decision. For bugs - each institution that is impacted should be in the : Affected institution - section of Jira.

The customer priority field is for implemented libraries - and can be : Critical, Important, medium, low  or not indicated.

The Critical label - in the label field is for implementing libraries to indicate a blocker or showstopper for go live