RFC 158: Code Intel UI Tracking Issue

[shrouxm]

Tracks work on RFC 158

@unassigned

Completed

• (🏁 861 days ago) Create a 'stale code intelligence' tooltip  #10927    🏳️ Backlog

@jjinnii

Completed

• (🏁 468 days ago) Create a "code intelligence status" tooltip #10926    🏳️ Backlog

@oleggromov

Completed

• (🏁 581 days ago) Tracking issue: Better code intel panel implementation #31953
• (🏁 504 days ago) Tracking issue: expose "code-intel inside™" in GraphQL API  #31071

[shrouxm]

General question for web re: implementing all of this:

As-is, this will require duplicate design + implementation work for the browser extension and on dot-com. Was it a conscious decision to style them differently than the equivalent UI elements on dot-com, and would it be possible to unify them and use the same components on dot-com and the extension?

[felixfbecker]

As-is, this will require duplicate design + implementation work for the browser extension and on dot-com. Was it a conscious decision to style them differently than the equivalent UI elements on dot-com, and would it be possible to unify them and use the same components on dot-com and the extension?

We do use the same components, but give them different CSS classes, which was indeed a conscious decision. The browser extension UI should "fit into" the code host UI and not look alien. E.g. a button on GitHub should look like other buttons on GitHub, not like a button in our webapp.

[shrouxm]

OK, if they use the same components then my main concern is resolved.

It wasn't obvious to me whether they should or shouldn't be styled that way so I was curious if there was any prior discussion about it. I'll raise the issue again in a separate thread if I still have qualms after further thought.

[uwedeportivo]

Dear all,

This is your release captain speaking. 🚂🚂🚂

Branch cut for the 3.17 release is scheduled for tomorrow.

Is this issue / PR going to make it in time? Please change the milestone accordingly.
When in doubt, reach out!

Thank you