Page MenuHomePhabricator

Suggested improvements to annoying little bugs page
Closed, DuplicatePublic

Description

Problem

Annoying little bugs’ is a good resource. But, IMO there is a problem. In our new developer surveys, it has come up several times that it is hard to choose a task to work on. Looking at this resource, I sense that it can be overwhelming to a) first decide on a project from the massive list on wiki, and b) then pick a task associated with a project from another massive list on Phabricator; considering that sometimes these tasks are old, unconfirmed, lacks proper description, and already a work in progress. Also, for DevRels, there is no way to pay extra attention to new users on Phabricator who may be working on some of these bugs as their first task for Wikimedia.

Trying to solve..  

Make it less cumbersome and time-consuming for new developers to jump start on a bug they like and provide a process for DevRels to monitor bugs that new developers are working on!

Possible approaches for a small experiment

  • 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
  • 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.
  • 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

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 11 2018, 11:44 PM
Aklapper added a comment.EditedMay 12 2018, 9:44 PM

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?

Lazhar added a subscriber: Lazhar.May 14 2018, 6:22 PM

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!

Vvjjkkii renamed this task from Develop a tool or a process for periodically generating a list of five bugs from “Annoying Little Bugs” that new developers could jump right in! to z2caaaaaaa.Jul 1 2018, 1:10 AM
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed a subscriber: Aklapper.
WhitePhosphorus renamed this task from z2caaaaaaa to Develop a tool or a process for periodically generating a list of five bugs from “Annoying Little Bugs” that new developers could jump right in!.Jul 1 2018, 2:38 AM
WhitePhosphorus raised the priority of this task from High to Needs Triage.
WhitePhosphorus updated the task description. (Show Details)
WhitePhosphorus added a subscriber: Aklapper.
srishakatux renamed this task from Develop a tool or a process for periodically generating a list of five bugs from “Annoying Little Bugs” that new developers could jump right in! to Suggested improvements to annoying little bugs page.Jul 3 2018, 3:26 AM
srishakatux triaged this task as Normal priority.
srishakatux updated the task description. (Show Details)
srishakatux updated the task description. (Show Details)

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.

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 :)

Aklapper lowered the priority of this task from Normal to Low.Mar 22 2019, 5:52 PM