25

I usually find posts that require redaction via "other" flags on a post. When I then submit a redaction (remove credentials or PII from revisions), a flag is raised for other moderators to validate the redaction.

When one of those flags is active, however, "other" flags on that post are hidden for me (and perhaps other types as well)? I can't then mark the flag as helpful until the redaction flags have been handled by another mod. What's worse is that other new flags on the post also won't be visible, so I could potentially be missing flags at this time.

This applies to both the flag queue (where the filtered "other" list contains the redaction flags, for some odd reason), and the post page itself (where the flag details banner only includes the redaction flags).

If I keep another tab open with the flag still visible, I can mark it as helpful. The redaction flags then disappear from the "other" flag queue too, so they are clearly being displayed instead of the "other" flag on the post. The redaction flag is then still visible in the redaction flags filter, and on the post itself.

I don't know if this applies to just me as redactor, or every moderator.

Please let me see the "other" flags on the post and in the queue even when a redaction approval flag is active.

Improve this question

1 Answer 1

Reset to default
3

I'm calling this by-design because... Well, it is: the rendering for redaction flags is special; it includes the revision diff, metadata, links and unique controls for approve & reject actions. These flags should not be handled along with other flags on the post, which the normal flag UI defaults to doing.

That said, I do understand that this can be awkward at times, and confusing at best. So I'm open to suggestions for improving the UI here, with the caveat that redaction is already difficult enough for most folks and we shouldn't do anything to make it more difficult.

Improve this answer
10
  • 2
    I'm fine with the redaction flag being visible to the moderator that kicked it off. But then show both, show the redaction flag and any other flags on the post.
    – Martijn Pieters
    Commented Jan 31, 2019 at 16:54
  • 2
    The current situation means that moderators also can't see new flags on the post until the redaction flag is cleared.
    – Martijn Pieters
    Commented Jan 31, 2019 at 16:54
  • 3
    And really, calling a bug 'by design' because the current flag page design isn't flexible enough to show both an 'other' flag and a redaction flag i can't further handle is not really a response I'd ever want to present one of my clients.
    – Martijn Pieters
    Commented Jan 31, 2019 at 16:58
  • 1
    To be clear: I'm calling it by design because it was designed to work this way: these flags replace the normal renderer when present. IOW, we'd have to redesign the normal flag rendering to make it work differently. That might be worth doing, but it's not trivial; we're gonna want to sit down & talk about how that should work in detail before it's at all clear what's feasible there.
    – Shog9 Mod
    Commented Jan 31, 2019 at 17:13
  • 1
    And yeah... It's definitely not ideal that the flag UI works this way; the redaction stuff was very much bolted on to a fairly inflexible existing system. That system is finally seeing some core improvements after many years of stagnation, but those changes haven't landed yet (and... there'll likely be a lot of other bugs to work out once they do, although we've been doing as much testing as possible internally). I'm responding here only because this came up in the TL earlier & I realized we'd never actually explained any of this publicly.
    – Shog9 Mod
    Commented Jan 31, 2019 at 17:17
  • 1
    Right, I interpret status-bydesign as "sorry, this is supposed to work this way, and it won't change", rather than "current design makes this choice, we may need to rethink the design".
    – Martijn Pieters
    Commented Jan 31, 2019 at 17:18
  • Put differently, from your wording I'd have expected no status tag or at most a status-deferred or status-planned tag. status-bydesign is a 'closed' state, at any rate.
    – Martijn Pieters
    Commented Jan 31, 2019 at 17:19
  • 1
    Generally "by-design" is for bugs, "deferred" / "declined" is for feature-requests; by definition, designs can change, but it's important to separate unintended behavior from that which is intended but not ideal. In this case, the behavior isn't due to a mistake, or even an unintended consequence of an intentional behavior elsewhere; this is currently the only way to shoehorn the UI we need for redactions into the UI for flags.
    – Shog9 Mod
    Commented Jan 31, 2019 at 17:27
  • Right, then I guess this should be re-classed as a feature request. Personally, not being aware of the internal designs, from a moderator perspective I still class this as a bug. I know how hard it can be to separate current architecture design from the bugs vs feature-request debate. :-)
    – Martijn Pieters
    Commented Jan 31, 2019 at 17:39
  • 1
    @MartijnPieters tl;dr the intent of the status-bydesign tag is to indicate that this is a design flaw, not a bug. I've often filed feature requests asking for the design to be changed after my bug reports were dismissed as by design.
    – Sonic the Anonymous Hedgehog
    Commented Jan 31, 2019 at 18:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .