The cause is that the feature's implementation status is still set to "Origin trial". We don't list a feature as shipping on the roadmap unless the implementation status gets set to "Enabled by default".

Basically, I think that we should display features on the roadmap based solely on milestones, regardless of implementation status or process status (and in fact remove those fields from the app).

I believe that the underlying problem here is two things:

• ChromeStatus was initially conceived as a tracking tool rather than a planning tool, with the implication of that being that the database was set up to represent the state of a feature entry at a moment in time rather than its overall planned trajectory. If the implementation status is "Origin trial" that means that milestones for stages up to the origin trial are supposed to be interpreted as trustworthy, while milestones for later stages are implicitly draft values that are not commitments.
• Feature owners don't come back to ChromeStatus to update feature entry details enough. Part of this may be because there are so many fields to track that feature owners don't recognize which ones are really needed. And, part of it may be
  because feature owners (naturally) only use the tool as much as is needed to get the approvals needed to launch and do not think about coordinating with cross-functional teams that support web developers.

One big part of our strategy to solve this problem is adding approvals and integrations so as to align the needs of all stakeholders and make the path of least resistance through the tool be the same as the path of complete process compliance.

Also, we have periodic notification emails that remind feature owners to update features before the shipping milestone.

More specifically, regarding the out-of-date implementation status (and out-of-date current process stage), I am thinking that we should drop both of those fields. There would be no implementation status and no current process stage. Instead, all milestones would be viewed as commitments that can be displayed to chromestatus visitors and used by cross-functional teams. Milestone values could be updated at any time, but they would never be treated as drafts. In the case of this feature, it would have shown up as shipping on the roadmap.

The risk is that some other feature might also show up, even when that feature had not really shipped. Joe had suggested adding a separate confidence field to differentiate draft vs. final values, but I think that is too complicated and that we should simplify rather than complicate. I think it is better to err on the side of displaying features on the roadmap because they can be seen and questioned and updated, whereas a non-displayed feature does not prompt that process.

The active process stage was pretty important for the Guide UX because there it controlled which stage was highlighted as the current stage, which guided features owners to fill in details for that stage and progress to the next stage. However, with our new emphasis on approvals, we could achieve the same guidance by basically emphasizing the next gate that lacks approval.

@cwilso What do you think about having milestone values always mean what they say, without any implied confidence level from implementation status or process stage?

Another idea would be to add some process/data integrity checks, perhaps at page view time (e.g. showing a warning icon) or as a regular email notification (like we do in OT), every time there is such a discrepancy. But I like your point about simplifying things, rather than adding more logic on top.

I discussed it with cwilso and there is more going on than I would have thought on first looking at the feature entry.
It's not clear that this feature actually did ship in 112 because the intent-to-ship discussion is still ongoing. And, the roll-out plan is with a series of percentage launches.

Bigger picture, we need to think through the deprecation process again because it's a complex process and the terminology can be confusing. We should probably survey feature owners who have done deprecations, but to start, I'll just ask this one feature owner if they have any feedback for us.

I'll add it to tomorrow's agenda for our team meeting.

Also, I looked more closely at the feature entry and it actually never ships on desktop, it only ships on webview. The Roadmap page does not display when things ship on webview at all. So, that is a case that our app is completely ignoring and that could require a redesign of the page.

Currently, we don't handle platforms well. The roadmap page is showing:

• Desktop and android launches mixed together
• Origin trials on webview (but no dev trials or shipping on webview)
• Nothing for iOS milestones
  That works OK for web platform features because they center around the desktop shipping milestone, but not for a browser feature that are not so much part of the web platform.

IIRC, there was a suggestion to have a Platform selector on the roadmap page, but we never fully fleshed out that idea.

Another similar case from M113 is WebRTC Callback-based legacy getStats(). This also involves a deprecation and a reverse OT.

On an unrelated note, I don't see the API owners' approvals in that feature, despite those being granted in the email thread.

This is another instance of a feature that correctly appears in the roadmap, but has implementation status "no active development", which confused some users. I tend to agree with your idea to remove this field entirely.

Two more cases from this week.

I am thinking that the way to resolve this is to keep the implmentation status solely for the purpose of indicating features that are no longer being developed. The roadmap page would use review status instead of implementation status.

I am thinking that the steps to do this are:

1. Change the roadmap page to consider approvals rather than implementation status. This is probably a multi-step query, but it should not be too complex.
2. Inform users and stakeholders that they no longer need to set it, via a UI notice and email comms.
3. Implement a "..." menu item to set the feature to no_longer_pursuing and remove old checkboxes. Also stop displaying it (Remove Implementation status #4581).

It would also be good to phase out the concept of active stage. That can also be derived from approvals. It is not really used in queries, just some minor UI elements.