Well, I'm not sure it is worth the hassle. Does an anonymous user really need to do the math with agile points?

Security bugs are invisible to most non-anonymous users as well; often only the developer who will work on it is given access and the rest of the team is not.

Robla just helped to verify this with a logged-in account and the security bug is indeed invisible and not counted towards the story point totals. I assume same goes for burndown charts etc. Given that PMs rarely get invited to security bugs, I think this can become quite confusing.

This should be brought to upstream and discussed there. We won't introduce a custom patch for this, and there likely are valid reasons and concerns when it comes to leaking information why to not display such placeholders, and to give more access rights to such "private"/restricted tasks instead to those people doing the Scrum/Points planning to allow them getting the full picture.

The main concern with security bugs is that they are only available to people under NDA to prevent leaking sensitive details to the public. With a WMF team PM, I can't imagine that they should be kept in the dark.

The solution there would be simply to CC the PM on security tasks.

I think we're very unlikely to implement this specific change (placeholder cards) in the upstream. See also T187051#5191464 for a similar issue.

If we show a placeholder task and that placeholder task respects the filters on the workboard, an attacker or unprivileged user can discover most of the details about the task by executing different searches. For example, they can discover who the task is assigned to by searching for different assignees and seeing if the placeholder appears. They can discover other projects the task is in with a similar strategy, and can then use fulltext search to figure out a lot of details about the task.

If the placeholder doesn't respect filters, I suspect the behavior would be quite confusing/unintuitive.

Disclosing just the open/closed status of the task and nothing else can be dangerous on its own (see linked comment above for an example).

If this is really a problem ("PMs routinely have major difficulty estimating project timelines accurately because of the development cost of secret issues") I think we're more likely to find solutions by looking at approaches other than placeholder cards. For example, perhaps we could have a rule like "alice is the PM for project Q, so to add a task to project Q it must be visible to alice". But I suspect this is somewhere fairly far down the list of sources of timeline/forecasting uncertainty?

A possible caveat here is that some fact/charting stuff is likely to encounter difficulty fully respecting policy controls: we may not be able to render a custom burndown chart for each user with exactly their permissions in large projects. So it's possible that charts may show numbers which bypass policies, somewhat mooting this. This is undesirable and means we're leaking some amount of information so I'm going to try to implement charts which fully respect policies, but it may not really be practical without making an unacceptable performance tradeoff.