You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
On the project's page, the user doesn't know whether any design related issues exist or how many they are. In order to access this information, they have to enter the project's github, and filter the issues manually.
Proposed solution
An LLM solution will, periodically, scan the project's labels, and decide which labels are relevant to designers.
Then, the back end fetches the number of issues that belong to each label, and feeds them to the front. Since Github imposes a limit on how many times its API can be used, ideally the labels for each project and their issue count would be temporarily saved, either on cache or on a database.
Finally, the front end displays the label and the number of issues that belong to it.
Alternative solution
If the LLM solution is too expensive/inaccurate or ineffective in any other way, then the possible relevant labels could be "hardcoded" as a list that the server can check against.
Additional context
It could be possible to use the same LLM that #67 uses.
The text was updated successfully, but these errors were encountered:
Problem
On the project's page, the user doesn't know whether any design related issues exist or how many they are. In order to access this information, they have to enter the project's github, and filter the issues manually.
Proposed solution
Alternative solution
If the LLM solution is too expensive/inaccurate or ineffective in any other way, then the possible relevant labels could be "hardcoded" as a list that the server can check against.
Additional context
It could be possible to use the same LLM that #67 uses.
The text was updated successfully, but these errors were encountered: