1547414 - Create Last Major Update field that excludes minor, bulk and automated changes

Status: NEW

(bugzilla.mozilla.org :: Bug Creation/Editing, enhancement, P2)

Description

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

There are times when we need to modify a bug's or large numbers of bugs' metadata such as merging components, migrating a metadata field (whiteboard to flag,) and other cases where we don't want to trigger a change such that the bugs show up on someone's last modified search, but we can't not modify the last changed date. Thus we need a last_user_visible_modification date to distinguish between changes done through administrative updates and those done by users.

Comment 1

[Kohei Yoshino]

How should we distinguish between administrative updates, bots and others? How do you usually run “no bugmail” changes, like the last time when you removed the good-first-bug keyword from BMO bugs?

Comment 2

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Anything on the bots list on the wiki. Let's make sure it's up to date.

Comment 3

[Kohei Yoshino]

Found the silent_users param on the Email admin page. Assuming it lists all the bots, I’ll use it for this new timestamp field as well.

Comment 4

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

The silents_users param is not inclusive of all the bots.

Should we have a bot registry in bugzilla with an option to make the bot behave like a silent user?

Comment 5

[Kohei Yoshino]

Not sure what’s the best way here. We could have a new boolean field on each user that indicates whether the user is a bot, but since we already have the silent_users param, we could use it instead. Maybe some bots may rather want to trigger sending email and update the timestamp?

Comment 6

[Kohei Yoshino]

Aside from minor changes like CC, attachment metadata, etc., I’ll just focus on the autonag bot now as requested by the RelMan team.

Comment 7

[Mark Clements]

Just a thought - slightly orthogonal to this bug - but how about if the 'last change' property was linked to the user's notification settings. Therefore, if someone chooses to be notified about Cc changes, then this will affect the last modified date that they see, but if they don't then Cc changes will be ignored for the purposes of the last modified date.

I would like to see the notifications settings built-out a bit anyway - not to the level of each individual field, but with to a greater extent than we currently have - and joining the two things together would perhaps avoid some duplication and provide a simple way to make this user-configurable.

Some examples of things I would like to be able to ignore: flag changes that don't involve me (as the setter or the settee), Cc list changes, severity/priority/platform changes, time-tracking fields, and assignee changes that don't involve me (as the old or new assignee).

Other people will have a different list, and so providing a bit of configurability would be of great help, and I suspect in most (all?) cases the set of things you are interested in are the same, whether in the context of e-mails or searches.

Comment 8

[Kohei Yoshino]

how about if the 'last change' property was linked to the user's notification settings

This is an interesting idea. We could make this user-configurable in the future when web notifications are implemented.

Some examples of things I would like to be able to ignore: flag changes that don't involve me (as the setter or the settee), Cc list changes, severity/priority/platform changes, time-tracking fields, and assignee changes that don't involve me (as the old or new assignee).

Yeah, actually most field changes are minor and ignorable. What’s important varies by user, but major changes for everyone are probably only these things:

• A comment is added
• An attachment is added
• The status or resolution is changed

I’ll update my pull request for this bug accordingly.

Comment 9

[Kohei Yoshino]

Attachment: GitHub Pull Request

Comment 10

[Kohei Yoshino]

Attachment: GitHub Pull Request for DB schema change

Comment 11

[Mark Clements]

Yeah, actually most field changes are minor and ignorable. What’s important varies by user, but major changes for everyone are probably only these things: [SNIP]

What is the purpose of this new field? What is the use-case for wanting to know when the last 'major change' happened?

The main reason that I can think of is so that you know when some real-world activity last took place in relation to the bug, so that you can see bugs that have not been worked on or thought about for a while. If this is the case then you probably also need to include the 'time worked' time-tracking field, as this is an indicator that some work has taken place.

Another interpretation could be that you want to know when significant details that might require you to take another look at it, if it is a bug you are following. In this case you probably also need to include the product/component, whiteboard and milestone.

The use-case in the original summary was to reduce noise for bulk changes. If this is the purpose, then surely it should be populated whenever the bug is edited via show_bug, but not when it is edited via 'change several bugs at once'?

Please can you provide some information about what use-case this feature is trying to solve as, at the moment, the proposed list of fields doesn't feel like it would satisfy any of the use-cases I have listed.