To some extent this might also touch artificial-intelligence.

The reason being that there are way too many options to choose from and most of the bugs in there are either old,

Phab allows to order a list of tasks by latest update (which is what all queries on mw:Annoying_little_bugs should already do). I'm not aware and cannot imagine any way to test if a bug report in its free-text form is still valid so I'm not sure how any tool could solve this problem. We could also set a threshold to only list tasks updated within a certain timeframe for each list of tasks if wanted.

not self-contained,

I can imagine this to be a good area for Natural Language Processing when it comes to [the length of] content and if content is structured (e.g. bullet points).

has already a patch for review,

...which might need rework or not. The current queries on mw:Annoying_little_bugs exclude tasks with the Patch-For-Review tag.

a team or an individual is working on it,

The current queries on mw:Annoying_little_bugs could exclude tasks which have an assignee set. Currently they don't. (If all teams use the assignee field is a different question, though.)

misses getting started instructions, etc.

That's basically "not self-contained" above, I'd say.

Also, from tracking newcomer activity perspective, there isn’t any process to know if newcomers are working on our bugs, and what have they been able to accomplish!

I was wondering a bit how that's related. Do you mean that someone "experienced" would be subscribed to these five tasks to potentially help? I'd say we already have a few people watching https://phabricator.wikimedia.org/tag/easy/ , me included, but indeed there is no "closely follow up" concept.

Regarding research papers, please correct me if I'm wrong:

http://thesai.org/Downloads/Volume9No2/Paper_12-Software_Bug_Prediction_using_Machine_Learning.pdf

That paper seems to be about creating models to predict future software faults based on historical data. I don't see a relation?

http://yadda.icm.edu.pl/yadda/element/bwmeta1.element.baztech-aca61940-c405-4828-be27-f870125e4613

That paper seems to be about judging the fixability of bugs that cannot be reproduced by others in general?

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41145.pdf

That paper seems to be about predicting areas of code that are likely to be error-prone?

See Also: T146960: Categorize #goodfirstbug (née #easy) tasks by required skills / scope, potentially as project workboard columns; T193070: Explore potential applications for NLP to be applied in Search for NLP in (MediaWiki) searching

Could definitely use artificial intelligence but a simple rule-based scoring system should work wonders and save some resources. For NLP, I used Google Cloud NL API for sentiment analysis on small reviews -- works wonders!

@srishakatux: Either superseded by or a subtask of T194657: Fix the "what to work on" recommendation system for volunteer developers?

Copying @Aklapper comments from https://www.mediawiki.org/wiki/User:SSethi_(WMF)/Sandbox/Suggested_improvements_to_annoying_little_bugs_page below:

• Develop a script that provides a dropdown/search feature on the ‘Annoying Little Bugs’ page and makes it easier to choose a bug by a technical area/project or programming language

"Search" sounds like duplicating existing Phabricator search. I guess I'm reluctant because maintenance costs. Or I don't understand. Would this be something like https://whatcanidoforwikimedia.org/ ?

• Include a separate section that showcases a list of five latest, easy bugs that currently have no owner and for which we do not have a patch in review tag already. Like in https://phabricator.wikimedia.org/maniphest/query/xf0gvyQXJMtl/#R. We also encourage new developers to add their name next to the bug. This list gets updated automatically through a bot on a weekly basis. DevRels could then try to pay little extra attention to the list of bugs we are showcasing in this section; understand what gets picked up what gets not, also improve the task description of these bugs and monitor challenges new developers experience.

Artificially reducing to 5 or 10 tasks that lately received updates sounds like a good idea. I'm not sure I understand why there needs to be a separate on-wiki "list" that requires manual maintenance instead of linking to a Phab query? I guess "new developers to add their name next to the bug" refers to an on-wiki list? Is there an advantage to new developers adding a comment in the Phab task itself?

• Add a concise step by step explanation for how to pick a task on Phabricator, what different concepts or tags mean, how to read the bug description or identify a problem and proceed from there!  (include screenshots) e.g., https://wiki.gnome.org/Newcomers/SolveProject

I was hoping that mw:New_Developers could be close to that very GNOME wiki page but realized...it's complicated to come up with generic and correct information if projects do not use the same task tracker or code hosting.

In T194556#4392802, @srishakatux wrote:

Copying @Aklapper comments from https://www.mediawiki.org/wiki/User:SSethi_(WMF)/Sandbox/Suggested_improvements_to_annoying_little_bugs_page below:
"Search" sounds like duplicating existing Phabricator search. I guess I'm reluctant because maintenance costs. Or I don't understand. Would this be something like https://whatcanidoforwikimedia.org/ ?

I meant something like in https://bugs.kde.org/query.cgi (see the drop-down menu with label 'Product'); to have a similar one for technical areas and programming languages.

Artificially reducing to 5 or 10 tasks that lately received updates sounds like a good idea. I'm not sure I understand why there needs to be a separate on-wiki "list" that requires manual maintenance instead of linking to a Phab query? I guess "new developers to add their name next to the bug" refers to an on-wiki list? Is there an advantage to new developers adding a comment in the Phab task itself?

It needn't be manually updated and can be pulled via a script from Phabricator. I think that a) giving a little preview of a task and a choice to go or to not go to a new platform can be a good experience in terms of design and b) allowing to add names on-wiki could also be a nice way of committing to work on a task.

Well, let's try if it's technically feasible (which I cannot judge)? Would love to see a design :)