Open Bug 1525376 Opened 5 years ago Updated 3 years ago

Deprecate the User Story field

Categories

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

Product:
bugzilla.mozilla.org
Component:
Extensions
Version:
Production
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

People

(Reporter: kohei, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #1518755 +++

Since comments are now editable for everyone with the editbugs permission, we don’t need a separate custom field for the user story. Users can write a story in their initial comment (aka bug description) and update it whenever needed. I guess such a practice is common on GitHub.

Of course, we cannot remove the field/extension that people have already used, but it’s time to deprecate it.

  • Remove it from the New Bug form
  • Hide it from bug pages if it’s empty

As Mark mentioned in Bug 1518755, people may want to get notified via email when the story is updated. So probably Bug 1524884 has to be solved first.

Depends on: bmo-markdown-initial-release

I have mixed feelings about this planned deprecation, because I have used/abused User Story quite often, and it has been very helpful in clarifying certain bugs, and made it easier to move to a resolution. So I would hate to have this go away without an alternative/better solution.

Typical use cases for me have been:

  1. citing numerous support requests (typically SUMO URLs) so that a) they can be researched by developers and support, b) so that these users can be used as testcases once a potential solution has been developed
  2. providing a time line of events/reports, so that one doesn't necessarily need to read the entire bug or all the support requests (#1 above)
  3. summarizing the state of the bug in one place (which can be STR, workaround, next steps, etc) so that one doesn't need to read an entire bug

2 and 3 have been especially helpful for bugs which are very old, or which have dozens/hundreds of comments, or whose user comments have been innaccurate, misleading or difficult to interpret.

some examples readily at hand (but not necessarily the best examples): Bug 1435903, bug 1106251, bug 1381485, bug 1456988. I think one is Jorg's. Bug 1406536 is an example of user story by Emma.

These are all the examples of how the User Story field has been abused (in your own term). A user story is something different. Here are some examples from recent bugs: Bug 1524329, Bug 1524490, Bug 1524781

But as a UX designer, I have to think about possible solutions, though these may probably not be implemented before the field is going away.

I’m currently proposing to create new roles, product owners and members. Once it’s done,

  1. Allow them to edit any comment in bugs filed under their product, so they will be able to update the bug description = reporter’s initial comment if it’s incomplete, like GitHub, or
  2. Allow them to pin a comment, so it will be highlighted at the top of the bug, like Twitter, Facebook or Google+.

I think we should make this change without waiting for the fix of Bug 1524884 in order to stop further abuse of the field. As I pointed out in Comment 2, a real user story is just a one-liner value statement defined by the bug’s reporter/assignee, which won’t be substantially edited afterwards. It means an email notification for an update is not required.

No longer depends on: 1524884
See Also: → 1527001
Depends on: 1527001
See Also: 1527001 →

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #4)

I think we should make this change without waiting for the fix of Bug 1524884 in order to stop further abuse of the field.

What you call "abuse" is in the best hacking tradition of making the most with what's available. If you take it away without a proper replacement we will be losing functionality. Prior to the existence of the User Story field we similarly abused the whiteboard, but given the small visible area were restricted to things like shouting "READ COMMENT 47 FIRST!!!".

The original purpose of bug 540 was to let people--not just the reporter!--edit the initial description to clarify the purpose of the bug, not generic comment editing. There were plenty of generic comment editing requests after that so I'm not complaining it got fixed (not at all! thank you!) but I am a bit unhappy it was closed without filling the original need. That was in the original "bugsplat" system where the long-description was not "just another comment" but was a separate field with no designated author, so editing by anyone with bug edit privs was appropriate. Given the authorial tagging of comment 0 we don't want other users putting words in the original reporter's mouth so the current restrictions on who can edit which comments are fine, but we still need a way to add special instructions right at the top of the bug. The features in comment 2 sound nice, but they also sound like they are not happening this week or this quarter. That's fine too, if we can keep using our User Story hack-around.

If you do "stop the abuse" will the existing data be preserved, at least?

I agree that the best solution is, as you said, making comment 0 the real bug description separated from the comment feed, like Jira. We can try the change later when we work on overhauling this modal bug page. In the meantime, I was thinking of making Whiteboard a multi-line <textarea>, just like User Story. It's a MEDIUMTEXT field, so we should be able to do it easily.

(In reply to Daniel Veditz [:dveditz] from comment #5)

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #4)

I think we should make this change without waiting for the fix of Bug 1524884 in order to stop further abuse of the field.

…where the long-description was not "just another comment" but was a separate field with no designated author, so editing by anyone with bug edit privs was appropriate. Given the authorial tagging of comment 0 we don't want other users putting words in the original reporter's mouth so the current restrictions on who can edit which comments are fine, but we still need a way to add special instructions right at the top of the bug.

I agree with this, I don't think we should remove the User Story field until the author information is removed from comment 0.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #6)

We can try the change later when we work on overhauling this modal bug page. In the meantime, I was thinking of making Whiteboard a multi-line <textarea>, just like User Story. It's a MEDIUMTEXT field, so we should be able to do it easily.

That feels like you're moving the abuse from one field to another… we need somewhere to put editable user story-like things that aren't associated with the bug filer. Putting them in the whiteboard is going to change the meaning of that field and will also add noise to the search results with all the additional text. It will also possibly slow down search results as a result.

Please don't remove the User Story field until we have a replacement for it… the whiteboard field isn't it IMO.

This is unfortunate. I often use it to store some explanations or other comments which may change during the lifetime of the bug. Editing comments does not cut it here. In "lenghty" bugs you would need to check the whole thread for changes.

I really don't see why it needs to be removed. If it is removed please provide a replacement before removing it.

(In reply to Matthew N. [:MattN] (PM me if requests are blocking you) from comment #7)

(In reply to Daniel Veditz [:dveditz] from comment #5)

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #4)

I think we should make this change without waiting for the fix of Bug 1524884 in order to stop further abuse of the field.

…where the long-description was not "just another comment" but was a separate field with no designated author, so editing by anyone with bug edit privs was appropriate. Given the authorial tagging of comment 0 we don't want other users putting words in the original reporter's mouth so the current restrictions on who can edit which comments are fine, but we still need a way to add special instructions right at the top of the bug.

I agree with this, I don't think we should remove the User Story field until the author information is removed from comment 0.

(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #6)

We can try the change later when we work on overhauling this modal bug page. In the meantime, I was thinking of making Whiteboard a multi-line <textarea>, just like User Story. It's a MEDIUMTEXT field, so we should be able to do it easily.

That feels like you're moving the abuse from one field to another… we need somewhere to put editable user story-like things that aren't associated with the bug filer. Putting them in the whiteboard is going to change the meaning of that field and will also add noise to the search results with all the additional text. It will also possibly slow down search results as a result.

Please don't remove the User Story field until we have a replacement for it… the whiteboard field isn't it IMO.

I agree with the request of the last sentence, and the rationale of every item above - although I well understand the proper and intended use of user story. And in particular, whiteboard in any form is whole unsuitable as a replacement.

Also, as a primary abuser (and probably the sole instigator) of user story in the Thunderbird and Mailnews products, bug 1106251 and bug 1381485 are fine examples of my work. And the reason this was done is a) user story was never used for the purposes it was intended afaik, b) the manner in which we have been using it has been VERY useful and effective - and a great time saver because one can collect information from disparate sources (other bugs, other comments, etc) in a single location. Furthermore, the info can be presented in "chronological order" whereas comments frequently are not - for example comment 2 could be about version N, and comment 3 could be about version N-1. As a whole, a GREAT aid in triaging.

I agree with Wayne, Matthew and :frg, "user story" is a very useful aid and a reworked whiteboard field isn't a suitable replacement.

Depends on: 1535000

Hey abusers, I listen to you 🤗

I’m still wondering if repurposing Whiteboard might be better than repurposing Comment 0. It’s a comment after all, and the change affects the tagging, reactions and perhaps starring. I’ll take time to figure out what are written in the User Story field on existing bugs.

Why repurposing User Story is not an option if Whiteboard or Comment 0 or whatever can be repurposed?

I don’t think it as an option because my goal is reducing the # of fields, and legit use cases are more valuable than abuses even if the latter is more common. How will the repurposed field be named? Long Whiteboard? Then what happens to real user stories?

A new multi-line input titled Scratchpad, which anyone with canconfirm/editbugs can edit, would provide a general-purpose solution for the needs described above. It would need revision-history support as any normal comment would, and would let people make use of it for a variety of use cases that would conflict if implemented less generically. I would hide it behind a button with a visual indicator of whether content is present or not and who/when last-updated.

Type: enhancement → task
Assignee: kohei.yoshino → nobody
Component: Extensions: Other → Extensions

Completing bug 1535000 would address the objections to removing the User Story field.

There are around 600 open bugs with a non-empty User Story: https://mzl.la/3frkGws

(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (UTC-8) needinfo? me from comment #16)

Completing bug 1535000 would address the objections to removing the User Story field.

That was true before bug 1535000 comment 4 reduced the scope but not as much now… I personally already have the ability to edit comment 0 but until it doesn't feel like I'm changing someone else's words I don't think it will be socially acceptable to make any significant edits to comment 0. It needs to be clear that comment 0 can be freely modified by others, especially during the transition. Having it visually separated from comments would help with that.

No longer depends on: 1652584
See Also: → 1652584
You need to log in before you can comment on or make changes to this bug.