fix(build): avoid breadcrumbs over-shortening

[Josh-Cena]

Summary

Problem

See for example:

Solution

Changed the regex to only match HTML tags at the start of the text (which matches the editorial conventions). Also did some minor refactoring.

---

Screenshots

Before

After

---

How did you test this change?

[Josh-Cena]

Anyone?

[Josh-Cena]

@mdn/core-dev All the AI business aside, could you spend two minutes to review this 10-line PR? Or at least someone tell me the length of the queue ahead of me. It's very discouraging for a contributor (I see myself as a community contributor) to have a bug fix PR completely ignored for 2 months.

[LeoMcA]

Approved, with the nit fixed.

Sorry about the delay reviewing this, I'd like to provide a little explanation and response to your comment:

All the AI business aside

That's not really possible is it? We have limited bandwidth, and now we're investing a lot of that into explaining to and gathering feedback from the community.

could you spend two minutes to review this 10-line PR?

It took longer that two minutes to review: we can't just have a brief look and go "yeah that looks right" when making a change that affects potentially millions of users. My process was something along the lines of:

1. Looking to see what this function was, where it was even referenced in the build process, if there might be any other side effects of changing the logic here

2. Identifying what was a functional change, and what was a refactoring

3. Reviewing the functional change - the regex itself, considering whether it made sense (which is where the nit came from)

4. Reviewing the refactor, whether the logic really didn't change, and if where it did (e.g. || to ??) if that made sense

5. Testing, to see if the change even works. This is where if you'd filled in the template fully it would've really helped speed up things, so I knew what pages you'd tested these changes on, or if you hadn't tested it at all then that gives me an indication of how thoroughly I need to test things.

It's very discouraging for a contributor (I see myself as a community contributor) to have a bug fix PR completely ignored for 2 months.

I could've been clearer on the communication front here, I'm sorry about that. We have quite a significant backlog of open PRs, and over the past few months have been going through them, prioritising them, making content/engineering/product decisions on them, so we can resolve them all over the next few months. One aspect of that was identifying the quick wins - which is what this was categorised as, hence why I'm reviewing it now.

Hope that helps to clear up what's been going on, and what you can expect from reviews going forward.

[Josh-Cena]

Thanks a lot @LeoMcA for taking the time. Sorry I didn't make myself sound understanding. Let me make a few things clear.

1. It's not a problem that the engineers prioritize whatever your employer requests you. When I said "AI business aside" I didn't mean you should put them down; I'm saying despite all the work (which I think it's not worth putting time into, but it's not your fault), a PR 2 months old should also gain some weight in your priority queue over issues that have just emerged a few days ago.
2. On the time to review. I understand myself as a reviewer that some self-testing helps the reviewer a lot, but I really think this is self-evident. Sorry if it isn't to you; it's always good to be vigilant.

My main point is not that my PR is not approved/thoroughly reviewed. It's not that engineers are prioritizing the AI feature over community work. It's that the PR is neglected completely, with not even a label. What I suggest as a baseline is that the reviewers post a message like "Hello, thanks for the PR; unfortunately we have limited bandwidth so we can't review it now and we don't know when we can get back to it, but we acknowledge its existence and will get it merged one day". I think that's a more encouraging way to engage.