Bug management/Task list

Tasks, thoughts and ideas related to Wikimedia bug management.

Help is welcome - please contact the bugwrangler if you plan to work on an item).

Regular tasksEdit

  • Identify and track progress of open tasks in Wikimedia Phabricator with priority set to "Unbreak now" (and to some extend to "High") and identify issues to mark as deployment blockers
  • Triage new and existing reports by making sure that sufficient information is provided, setting priority if wanted by development teams, helping to find assignees, cleaning up and organizing older tickets.
  • Coordinate and (co)organize bugtriage, bugsquad community outreach and growth (via bugdays)
  • Improve the process of bug submission, the bug status workflow, and bug management documentation
  • Keep an eye on other feedback channels where bugs might be reported, like Village Pumps, especially in the 24h after deployments of new software versions on the WMF servers
  • Phabricator maintenance (to some extend; taxonomy and configuration changes)

Monthly GoalsEdit

Goals and tasks are nowadays tracked for "Aklapper" (the bugwrangler) in Phabricator. See the Developer-Relations workboard.

October 2014

October 2014Edit

September 2014

September 2014Edit

August 2014

August 2014Edit

  • Phabricator: Work on consensus on configuration settings, drive decisions and keep an overview Status:    In progress
  • Have a bugday on UploadWizard Status:    Not done, likely to happen on Sep 09th 17:00UTC
  • (With Quim) Set up workflow for having a regular, easy "bug of the week" for new code contributors, with rotating support of Wikimedia development teams (based on Annoying little bugs) Status:    Postponed to October due to Phabricator being priority
July 2014

July 2014Edit

  • Phabricator (driving tasks): Get Alpha instance up and running; work on consensus on configuration settings Status:    In progress
  • (With Quim) Set up workflow for having a regular, easy "bug of the week" for new code contributors, with rotating support of Wikimedia development teams (based on Annoying little bugs) Status:    Not done: planning page created on 2014-07-02 targetting end of July
  • Have a Pywikibot bugday with the Pywikibot hackers around the end of July Status:    Done - summary email; wiki page
June 2014

June 2014Edit

  • Mostly Phabricator business (driving tasks) Status:    In progress
  • Prepare introducing "Bug of the week" by talking to development teams Status:    In progress - Andre started preparing email draft to dev teams and workflow of planning on 2014-06-16
  • Have a bugday on older bug reports with higher priority in MediaWiki Status:    Done - Bug_management/Triage/20140624
  • Make Google Summer of Code 2014 and Outreach Program for Women/Round 8 mentors and students provide their mid-term evaluations Status:    Done
May 2014

May 2014Edit

April 2014

April 2014Edit

  • (With Guillaume) (Continued from March) Set up and facilitate the community RfC about Project management tools/Review, and bring it to a decision if possible. Status:    Done - RfC started on 2014-04-14
  • (With Guillaume) Have another IRC office hour about Project management tools Status:    Done on 2014-04-17 and 2014-04-22
  • Gather more feedback on rebooted Annoying little bugs after GSoC start Status:    In progress - Andre sent an email to five GCI mentors on 2014-04-24 and received three answers
  • Prepare introducing "Bug of the week" by talking to development teams Status:    Not done -- postponed to May
  • Have a bugday in the second half of April Status:    Done: on 2014-04-29 about General MediaWiki, see Bug management/Triage/20140429
March 2014

March 2014Edit


February 2014

February 2014Edit


January 2014

January 2014Edit

  • (With Guillaume) Meet Project management tools stakeholders, determine requirements, and document this research. Status:    Done by Guillaume here
  • (With Daniel Zahn) Prepare Bugzilla upgrade to 4.4 (and move to new datacenter) - outstanding steps from bugzilla:49597:
    • Upgrade Bugzilla on zirconium from 4.2 to 4.4. Status:    Done
    • Apply 4.2 custom changes to Bugzilla on zirconium from Git repository. Status:    Done
    • Apply Andre's 11 patches (linked here) in Gerrit to port our custom changes from 4.2 to 4.4. Status:    Done on 2014-01-07
    • Test Bugzilla on zirconium. Status:    Done on 2014-01-15
    • Make collectstats.pl work - bugzilla:29203. Status:    Done by dzahn here on 2014-01-29
    • (With Daniel and Sean) Switch database and DNS from old kaulen server to new zirconium server. Status:    Not done - tentative date: 2014-02-12
  • Show common queries on Bugzilla frontpage - bugzilla:22170. Status:    In progress - 2014-01-10: Patch in Gerrit; depends on 4.4 upgrade first
  • Finalize Bugzilla etiquette draft once the lively discussion on its Talk page has ended. Status:    In progress - 2014-01-09: Announcement that discussion will be closed soon
  • Fix inline displaying of image files in Bugzilla - bugzilla:54181. Status:    Done - andre successfully tested csteipp's patch on Labs on 2014-01-05; deployed on 2014-01-10
  • (With Quim) Finish running Google Code-In contest. Status:    Done
December 2013

December 2013Edit

  • Google Code-In: Run and organize contest with Quim. Status:    In progress
  • Agree and finalize "etiquette" draft for behavior in Bugzilla, as discussed on teampractices@. Status:    In progress - Discussion on Talk page still ongoing on 20131225 after asking for feedback on wikitech-l@.
  • Evaluate Project management / issue tracking requirements and potential tools. Status:    In progress - kicked off on teampractices@ and wiki on 2013-12-13
  • Test Bugzilla 4.4 with our custom patches on Labs (or zirconium in eqiad if production is still on kaulen in Tampa). Status:    In progress, will need help from ops. Steps discussed between dzahn and aklapper on 2013-12-06; dzahn has set up a copy of Bugzilla 4.2 on zirconium in eqiad (see RT #4783). Next steps are upgrading that machine to Bugzilla 4.4, applying our custom patches, testing, and finally switching over.
November 2013

November 2013Edit

  • Google Code-In: Define generic information (template) for all task descriptions; clean up & import tasks from wiki into Google Melange. Status:    Done (except for tasks missing a mentor)
  • Finish cleaning up and syncing custom CSS in Wikimedia Bugzilla. Status:    Done - done (except for two CSS files) (bugzilla:54823)
  • Write an "etiquette" draft for behavior in Bugzilla, as discussed on teampractices@. Status:    In progress - first draft available
  • Start planning evaluation of Project management / issue tracking requirements and potential tools. Status:    Not done
  • Start porting our custom Bugzilla patches by porting our 4.2 custom patches to deploy on a vanilla Bugzilla 4.4. Status:    Done (bugzilla:49597#c5)

Quarterly GoalsEdit

October to December 2014

October to December 2014Edit

July to September 2014

July to September 2014Edit

April to June 2014

April to June 2014Edit

  • (With Guillaume) Do what's needed to drive Project_management_tools/Review. Status:    Done
  • (With Quim) Expose an easy "bug of the week" with dev team support (after Annoying little bugs is in shape) Status:    In progress, Andre preparing
  • Have a public bug day approximately once per month. Status:    Done on 20140428 and 20140624, planning for 201407 started
  • Some more Bugzilla taxonomy cleanup. - bugzilla:38990 Status:    On hold -- not enough time for this plus low priority now that we favor Phabricator
  • Investigate closing components of extensions archived in the code repository. - bugzilla:47540 Status:    On hold, postponing
  • Investigate splitting "enhancement" out of Bugzilla's "severity" dropdown and make it separate. - bugzilla:58096 Status:    On hold, low priority & only if we stick with Bugzilla -- not enough time for this plus low priority now that we favor Phabricator

January to March 2014

January to March 2014Edit

October to December 2013

October to December 2013Edit

Note to myself: Try to keep in sync with ECT Quarterly goals and ECT Monthly goals.

  • Social:
    • Prepare and organize Wikimedia participation in Google Code-In with Quim. Status:    In progress
    • Work on "etiquette" draft for behavior in Bugzilla, as discussed on teampractices@. Status:    In progress - Discussion on Talk page still ongoing on 20131225 after asking for feedback on wikitech-l@.
    • Evaluate Project management / issue tracking requirements and potential tools. Status:    In progress - kicked off on teampractices@ and wiki on 2013-12-13
    • Andre to learn more about / understand better Wikimedia's Release Management from Greg. Status:    Not done won't happen this quarter, too busy with additional projects added while in Q4 (BZ etiquette & PM Tools eval)
    • mw:Annoying_little_bugs - try announcing an exposed easy "bug of the week" for new contributors, with support from dev teams. Status:    Not done -- Google Code-In has priority over this.
  • Bugzilla setup / code:
    • Show InlineHistory in Bugzilla - bugzilla:47256. Status:    Done
    • Bring "guided bug report form" into a state that it can be used to report issues for Bugzilla newbies - bugzilla:36762. Status:    Done
    • Start preparing Bugzilla upgrade to 4.4 (and move server to new datacenter) - bugzilla:49597:
      • CSS cleanup. Status:    Done
      • Create custom patches for the 4.4 codebase. Status:    Done on 20131128 - bugzilla:49597#c5
      • Test locally Status:    Done on 20131128 - bugzilla:49597#c5
      • Clean up custom Perl CPAN modules and replace by distribution packages; puppetize Bugzilla's package requirements - Status:    Done - RT #4783
      • Copy current production Bugzilla 4.2 to zirconium in eqiad (from kaulen in Tampa) for testing. Status:    Done on 20131225
      • Upgrade Bugzilla on zirconium from 4.2 to 4.4. Status:    Not done
      • Apply custom changes to Bugzilla on zirconium. Status:    Not done
      • Test Bugzilla on zirconium. Status:    Not done
      • Switch from old server to new server. Status:    Not done
    • Only after 4.4 upgrade: Provide a NEEDINFO flag in Bugzilla - bugzilla:36064. Status:    In progress - moved to Q1/2014 as 4.4 upgrade takes longer
    • Only after 4.4 upgrade: Install component watching extension. Status:    Not done -- database issues when testing; not yet tested on 4.4 and upstream code is still 4.2 only. - moved to Q1/2014 as 4.4 upgrade takes longer
    • Puppetize Bugzilla - bugzilla:51036 Status:    In progress - dzahn of ops working on this since 12/2013


BacklogEdit

Anybody is free to help and work on these items.

  • General bug documentation updates (please see phab:T206 first!):
    • Document and explain the main things that people do in a bug report: Should I comment or not? Add myself to CC? (This was Outreachy feedback from Valerie.)
    • Extend triage guide to also cover enhancement requests. This is a bit more special (e.g. when it comes to WONTFIXing/declining tasks etc.).
  • Bug documentation updates that require discussing with other stakeholders first:
    • Make meanings of resolutions/statuses clearer (in Bug_report_life_cycle or How_to_triage?), e.g. when to set WONTFIX (and when not) in Bugzilla or DECLINED in Phabricator, and after how much time to close a report without enough information as WORKSFORME in Bugzilla or DECLINED in Phabricator? (This was OPW feedback from Valerie.)
    • design keyword (Bugzilla)/project (Phabricator) workflow: Improvements possible? Requires talking to the design team.
    • Talk to Mobile team: Are there instructions somewhere for users how to provide a stacktrace when the Wikipedia App crashes on iOS or Android that could be added to How to report a bug? (e.g. bugzilla:41027)
    • Policy: Define a policy when users are blocked or when insulting/useless comments will be hidden - might not be needed as the global Code of Conduct applies
    • Policy: Usually "community-consensus-needed" (keyword in Bugzilla, project in Phabricator) is used where there are concerns that the local community might not have discussed the change, or the change is not supported by them. Otherwise "shell" is used to show bugs which need a shell user to review, merge and deploy. "community-consensus-needed" is always turned into shell after clarification that community consensus exists, cf bugzilla:45539.
  • Consider collecting stock answers, cf. Maemo or MeeGo

Tasks that require special permissionsEdit

Tasks listed here require special Bugzilla or Phabricator permissions (e.g. being an admin) hence only a small number of people can work on them.

  • Clean up after migration to Phabricator: Duplication of information in Bugzilla: keywords vs tracker bugs vs products:
    • MW/JavaScript component vs JavaScript keyword vs bug 2114
    • newparser keyword vs Parsoid product: talk to James_F (James Forrester) (PM for Parsoid)
    • analytics keyword vs Analytics product (and Wikimedia/Statistics) --> Contact analytics ml if they use Bugzilla and if it works for them?
    • newphp keyword vs PHP4.x tracking bug 30092
    • tracking keyword vs tracking meta bug 2007
    • SSL: Component vs. tracking bug bug 53999
  • Cleanup: Identify MediaWiki extensions in SVN which have not been converted from now read-only SVN to Gerrit and are hence dead. Close their bug reports as RESOLVED WONTFIX (Bugzilla) or DECLINED (Phabricator), explaining the situation, and add some "unmaintained" project (to be discussed and defined) so they could be identified later per component in case somebody wants to pick up development again? Also see Git/Conversion/Extensions_queue.

Finished / completed tasksEdit

Also see the weekly status updates for more verbose information.

Other stuffEdit

Random Phabricator queriesEdit

See Bug management/Phabricator queries.

Random Bugzilla queriesEdit

See also: wmfBugZillaPortal

TablesEdit

Growth chartsEdit