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 tasks

 * Identify and track progress on highest and immediate priority issues and mark issues as deployment blockers
 * Triage new incoming reports by making sure that sufficient information is provided, and setting priority if wanted by development teams
 * Coordinate and (co)organize bugtriage, bugsquad community outreach and growth (via bugdays and WikiProject Bug Squad)
 * Improve bug management documentation on the wiki
 * Keep an eye on other feedback channels, like Village Pumps, especially after deployments
 * Bugzilla maintenance (taxonomy and configuration changes, deploying security updates)

October 2014

 * Phabricator: Prepare migration of Bugzilla and RT to Phabricator
 * Prepare Google Code-in -- T561
 * Have a bugday on PDF rendering and the Collection extension on Wed 2014-10-08 (organized and run by Nemo, Planning page)
 * Phabricator: Migrate RT to Phabricator -- postponed to November
 * Phabricator: Migrate Bugzilla to Phabricator -- postponed to November
 * 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) -- postponed to January (after Google Code-in)

September 2014

 * Phabricator: Set up Phabricator production instance and push fixing remaining blockers
 * Phabricator: Improve its documentation
 * Bugday on UploadWizard on Sep 09th 17:00UTC

August 2014

 * Phabricator: Work on consensus on configuration settings, drive decisions and keep an overview
 * Have a bugday on UploadWizard, 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)

July 2014

 * Phabricator (driving tasks): Get Alpha instance up and running; work on consensus on configuration settings
 * (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) : planning page created on 2014-07-02 targetting end of July
 * Have a Pywikibot bugday with the Pywikibot hackers around the end of July - summary email; wiki page

June 2014

 * Mostly Phabricator business (driving tasks)
 * Prepare introducing "Bug of the week" by talking to development teams - 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 - 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

May 2014

 * (With Guillaume) Close Phabricator RfC, and bring it to a decision if possible., see email
 * Phabricator: Identify "heavy topics" and blockers (vs. acceptable trade-offs) that must be fixed before starting a migration to Phabricator., see board
 * Phabricator: Act on top items in the "Doing" column for Phabricator migration
 * Have sessions on Phabricator RfC and bug triage at Zürich Hackathon 2014 (though dropped triage in favor of three Phab sessions)
 * Act on feedback received on rebooted Annoying little bugs page -- some improvements on 2014-05-20
 * Prepare introducing "Bug of the week" by talking to development teams
 * Have a bugday either on bugs with higher priority in MediaWiki, or testing the new PDF Renderer once a test instance exists - pinged on wikitech-l@ about PDF renderer status

April 2014

 * (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. - RfC started on 2014-04-14
 * (With Guillaume) Have another IRC office hour about Project management tools on 2014-04-17 and 2014-04-22
 * Gather more feedback on rebooted Annoying little bugs after GSoC start - 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 -- postponed to May
 * Have a bugday in the second half of April : on 2014-04-29 about General MediaWiki, see Bug management/Triage/20140429

March 2014

 * (With Guillaume) Lead the community discussion about the shortlist of candidates for Project management tools/Review (based on Project management tools/Review/Requirements), take the first implementation steps (possibly in Labs).
 * (With Guillaume) Have an IRC office hour about Project management tools on 2014-03-28
 * (With Guillaume) Set up and facilitate the community RfC about Project management tools, and bring it to a decision. -- postponed to April
 * (With Quim) Reboot Annoying little bugs based on Google Code-In experience; Bugzilla's easy keyword; exposing an easy "bug of the week":
 * Kill curated list on the wikipage; provide specific Bugzilla queries and "getting started" instructions for each area: on 2014-03-07 (diff)
 * Introduce "Bug of the week" after talking to teams? - postponed to Q2/2014
 * Better Bugzilla taxonomy: Discuss using classifications in Bugzilla and identify some initial non-controversial changes. - 38990. ; first smaller cleanup steps about "Tools" and deprecated stuff are 57738, 54063, 53986, 55351, 62386, 62384; Proposal to use Bugzilla classifications on 2014-03-10
 * Bugzilla setup / code:
 * Provide a NEEDINFO flag in Bugzilla - 36064. : (porting more complicated as bmo will skip 4.4) -- might get postponed to Q2/2014
 * Provide a way to mark an item as NEEDINFO in Bugzilla - 36064. : Created list of pros and cons of two implementations on 2014-03-10; next step is start broader discussion on wikitech-l@ and agree on which way to do
 * Install component watching extension to be able to receive bugmail for specific product/component for devs and triagers, plus no more manual adding of people to auto-CC by admins - 37105. -- database issues when testing; not yet tested on 4.4 and upstream code is still 4.2 only. Porting more complicated as bmo will skip 4.4 -- postponed to Q2/2014

February 2014

 * (With Guillaume) Lead the community discussion about the shortlist of candidates for Project management tools/Review (based on Project management tools/Review/Requirements), take the first implementation steps (possibly in Labs).
 * Prepare Bugzilla upgrade to 4.4 (and move to new datacenter) - . Outstanding steps from 49597:
 * (With Daniel and Sean) Switch database and DNS from old kaulen server to new zirconium server. on 2014-02-13
 * Show common queries on Bugzilla frontpage - 22170. on 2014-02-13
 * Finalize Bugzilla etiquette draft. - 2014-02-05: Announcement
 * Further small patches after 4.4 upgrade (License headers and template processing cleanup; numerous contributed Gerrit patches waiting ).
 * (With Quim) Reboot Annoying little bugs based on Google Code-In experience; Bugzilla's easy keyword; exposing an easy "bug of the week":
 * Cover common "getting started" questions: added on 2014-02-18
 * Improve Bugzilla queries on Annoying little bugs to show a good subset: on 2014-02-18
 * Add guidelines for triagers how to identify a bug report that is good for this audience: by editing the "easy" keyword description on 2014-02-24
 * Retriage existing bugs with easy keyword: mostly

January 2014

 * (With Guillaume) Meet Project management tools stakeholders, determine requirements, and document this research. by Guillaume here
 * (With Daniel Zahn) Prepare Bugzilla upgrade to 4.4 (and move to new datacenter) - outstanding steps from 49597:
 * Upgrade Bugzilla on zirconium from 4.2 to 4.4.
 * Apply 4.2 custom changes to Bugzilla on zirconium from Git repository.
 * Apply Andre's 11 patches (linked here) in Gerrit to port our custom changes from 4.2 to 4.4. on 2014-01-07
 * Test Bugzilla on zirconium. on 2014-01-15
 * Make collectstats.pl work - 29203. by dzahn here on 2014-01-29
 * (With Daniel and Sean) Switch database and DNS from old kaulen server to new zirconium server. - tentative date: 2014-02-12
 * Show common queries on Bugzilla frontpage - 22170. - 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. - 2014-01-09: Announcement that discussion will be closed soon
 * Fix inline displaying of image files in Bugzilla - 54181. - 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.

December 2013

 * Google Code-In: Run and organize contest with Quim.
 * Agree and finalize "etiquette" draft for behavior in Bugzilla, as discussed on teampractices@. - Discussion on Talk page still ongoing on 20131225 after asking for feedback on wikitech-l@.
 * Evaluate Project management / issue tracking requirements and potential tools. - 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)., 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

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

October to December 2014
 
 * Have RT and Bugzilla entirely migrated to Phabricator
 * Have a proof of concept for Code Review in Phabricator
 * Have a public bug day approximately once per month.
 * (With Quim) Expose a regular, easy "bug of the week" for new code contributors with rotating support of Wikimedia development teams (based on Annoying little bugs)
 * Successfully (co-)organize Wikimedia's participation in Google Code-In

July to September 2014
 
 * Progress on migrating to Phabricator: Set up Phabricator production instance, set up Legalpad instance, have test import of RT/Bugzilla data
 * Have a public bug day approximately once per month. (Pywikibot on 20140724, UploadWizard on 20140909, PDF renderer in 201410?)
 * (With Quim) Expose a regular, easy "bug of the week" for new code contributors with rotating support of Wikimedia development teams (based on Annoying little bugs)

April to June 2014
 
 * (With Guillaume) Do what's needed to drive Project_management_tools/Review.
 * (With Quim) Expose an easy "bug of the week" with dev team support (after Annoying little bugs is in shape), Andre preparing
 * Have a public bug day approximately once per month. on 20140428 and 20140624, planning for 201407 started
 * Some more Bugzilla taxonomy cleanup. - 38990 -- not enough time for this plus low priority now that we favor Phabricator
 * Investigate closing components of extensions archived in the code repository. - 47540, postponing
 * Investigate splitting "enhancement" out of Bugzilla's "severity" dropdown and make it separate. - 58096, 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
 
 * Social:
 * (With Guillaume) Meet Project management tools stakeholders, determine requirements, and document this research.
 * (With Guillaume) Lead the community discussion about the shortlist of candidates for Project management tools, take the first implementation steps (possibly in Labs).
 * (With Guillaume) Set up and facilitate the community RfC about Project management tools, and bring it to a decision. - postponed to April 2014
 * (With Quim) Reboot Annoying little bugs; Bugzilla's easy keyword; exposing an easy "bug of the week" : Based on Google Code-In experience, decrease manual curation work by providing links to common "getting started" questions. on 2014-03-07
 * Finalize Bugzilla etiquette draft. - 2014-02-05: Announcement
 * Better Bugzilla taxonomy: Discuss using classifications in Bugzilla and identify some initial non-controversial changes. - 38990. ; first smaller cleanup steps about "Tools" and deprecated stuff are 57738, 54063, 53986, 55351, 62386, 62384; Proposal to use Bugzilla classifications on 2014-03-10
 * Bugzilla setup / code:
 * Upgrade Bugzilla to 4.4 on 2014-02-13
 * Common queries on Bugzilla frontpage - 22170. on 2014-02-13
 * Provide a way to mark an item as NEEDINFO in Bugzilla - 36064. : Created list of pros and cons of two implementations on 2014-03-10; next step is start broader discussion on wikitech-l@ and agree on which way to do
 * Install component watching extension to be able to receive bugmail for specific product/component for devs and triagers, plus no more manual adding of people to auto-CC by admins. -- postponed to Q2/2014

October to December 2013
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.
 * Work on "etiquette" draft for behavior in Bugzilla, as discussed on teampractices@. - Discussion on Talk page still ongoing on 20131225 after asking for feedback on wikitech-l@.
 * Evaluate Project management / issue tracking requirements and potential tools. - kicked off on teampractices@ and wiki on 2013-12-13
 * Andre to learn more about / understand better Wikimedia's Release Management from Greg. won't happen this quarter, too busy with additional projects added while in Q4 (BZ etiquette & PM Tools eval)
 * Annoying_little_bugs - try announcing an exposed easy "bug of the week" for new contributors, with support from dev teams . -- Google Code-In has priority over this.


 * Bugzilla setup / code:
 * Show InlineHistory in Bugzilla - 47256.
 * Bring "guided bug report form" into a state that it can be used to report issues for Bugzilla newbies - 36762.
 * Start preparing Bugzilla upgrade to 4.4 (and move server to new datacenter) - 49597:
 * CSS cleanup.
 * Create custom patches for the 4.4 codebase. on 20131128 - 49597
 * Test locally on 20131128 - 49597
 * Clean up custom Perl CPAN modules and replace by distribution packages; puppetize Bugzilla's package requirements - - RT #4783
 * Copy current production Bugzilla 4.2 to zirconium in eqiad (from kaulen in Tampa) for testing. on 20131225
 * Upgrade Bugzilla on zirconium from 4.2 to 4.4.
 * Apply custom changes to Bugzilla on zirconium.
 * Test Bugzilla on zirconium.
 * Switch from old server to new server.
 * Only after 4.4 upgrade: Provide a NEEDINFO flag in Bugzilla - 36064. - moved to Q1/2014 as 4.4 upgrade takes longer
 * Only after 4.4 upgrade: Install component watching extension. -- 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 - 51036 - dzahn of ops working on this since 12/2013



Backlog
Anybody is free to help and work on these items.

Please note: Wikimedia is migrating from Bugzilla to Phabricator, hence any tasks in this list should focus on Phabricator instead of Bugzilla!


 * General bug documentation updates (please see 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 OPW 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. 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 45539.
 * Consider collecting stock answers, cf. Maemo or MeeGo

Tasks that require special permissions
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 tasks
Also see the weekly status updates for more verbose information.
 * 20140422: Rename "Tools" product to "Utilities" in Bugzilla - 53986
 * 20140213: Puppetize Bugzilla - 51036
 * 20140213: Show common queries on Bugzilla frontpage - 22170
 * 20140213: Upgrade Bugzilla from 4.2.7 to 4.4.1 - 49597
 * 20140213: Move Bugzilla from old kaulen server in Tampa to new zirconium server in Eqiad
 * 20140205: Finalize Bugzilla etiquette (Announcement)
 * 20131215: Taxonomy cleanup: Move "CiviCRM" product into a "Wikimedia" subcomponent - 57738
 * 20131202: Warn that patches should go to Gerrit instead of Bugzilla - 42606
 * 20131202: Link on top of enter_bug.cgi to the guided bug entry form - 52696
 * 20131128: Port our custom patches from Bugzilla 4.2 to 4.4 - 49597
 * 20131115: Decrease our custom CSS differences with upstream code (16 CSS files deleted) - 54823
 * 20131111: Renamed "shellpolicy" keyword to "community-consensus-needed" - 49494
 * 20131026: Guided bug report form for Bugzilla newbies available - 36762
 * 20131014: Enabled InlineHistory by default for all users - 47256
 * 20130930: Create good relation to upstream Bugzilla developers via attending upstream Bugzilla meetings and being active on IRC and the support-bugzilla mailing list
 * 20130926: Do not limit Product column in buglist.cgi to 8 chars - 40244
 * 20130925: Show InlineHistory in Bugzilla - 47256
 * 20130901: Clean up open UsabilityInitative tickets as per 36111 and 24335. - 52943
 * 20130830: Documenting best practices in Bugzilla via blogpost miniseries -- see the list
 * 20130827: Quick "Show other bug reports in this component" query link in bug report - 46413
 * 20130723: Replace "patch-in-gerrit" keyword by an automatically set status. Related: 39399, 39402; Discussion started on wikitech-l | Gerrit Notification Patch
 * 20130614: Display "email" instead of "login" string in Bugzilla - 24992
 * 20130614: Start documenting best Bugzilla practices in a blog series linked from Bug_management
 * 20130613: Document Bugzilla administrator rights and guidelines
 * 20130611: More useful Bugzilla frontpage - 22170
 * 20130508: Wikimedia Labs instance for Bugzilla at boogs.wmflabs.org created by Ori
 * 20130422: Enhance "Weekly Bug Summary" email on wikitech-l to have correct data and include most urgent issues - 45770
 * 20130416: Cleanup: Closed remaining (Uniwiki extension tickets as it's unmaintained (part of cleanup bugday).
 * 20130412: Enhance "Weekly Bug Summary" email on wikitech-l to have correct data and be more useful - 45770
 * 20130408: Removed "bugsmash" keyword from all Bugzilla tickets, so it could be used with its actual meaning.
 * 20130326: Search tickets currently in four different components, consider simplification
 * 20130322: Taxonomy: Merged several mobile apps - 41922
 * 20130319: Start having ~bimonthly IRC office hours on Bug management
 * 20130211: Creation of Bug Life Cycle flowchart by Valerie, embedded in Bug management/Bug report life cycle
 * 20130129: First bugday, organized by Valerie and Andre
 * 20130115: Finalized How to report a bug page (with help of Guillaume) for translations
 * 20130111: Document how development teams use Bugzilla - Bug management/Development teams usage
 * 20130106: Publish list of Bugzilla admins
 * 201301: Docs: Further update and clean up of bug management related documentation: Bug management Doc Rewrite
 * 20121217: Smaller Bugzilla bugfixes: 40344, 41321
 * 201212: Docs: Guidelines for creating new products in BZ
 * 201212: Docs: Instructions for project maintainers how to add/change products and settings
 * 201212: Docs: Document who checks BZ security updates? - Andre, documented on Bug management
 * 201212: Docs: "upstream" keyword policy: "Upstream ticket URL should exist when setting, documented on Bug management/Upstream bugtrackers
 * 201212: Disable use of RESOLVED LATER resolution as as discussed
 * 20121204: Upgrade Bugzilla to version 4.2 upgrade - 33158
 * Find out which extensions are deployed in production to give them higher priority when triaging - done and implement in Greasemonkey script, cf. 36738), Category:Extensions used on Wikimedia, Gerrit
 * 201111: Bigger updates to Triage guide
 * 201211: Creation of "immediate" priority in Bugzilla (discussion) due to varying use of "highest"
 * 201211: consider introducing a status WAITINGFORUPSTREAM like in Mer Bugzilla - not wanted as per mailing list discussion, use lowest priority and "upstream" keyword instead
 * 20121108: List extensions that are deployed but should get killed? User:Malyacko/ExtensionsToUndeploy
 * 20121108: Rename old "MediaWiki%20extensions/Wikidata" component from OmegaWiki vs new Wikidata project - done by Chad
 * 20121031: Publish Greasemonkey triage scripts
 * 20121030: Docs: Create an UpstreamBugtrackers overview page: Bug management/Upstream bugtrackers

Random Bugzilla queries

 * See also: wmfBugZillaPortal


 * filed in the last 7d: open all | closed &le;7d
 * open without response: all non-enhancement only


 * without changes for 2yrs
 * No comments from anybody else than reporter
 * more than 20 votes
 * Open bugs for Bugzilla itself
 * MediaWiki: Open && Target Milestone==1.20.x
 * MediaWiki: Open && Target Milestone==1.21.0
 * MediaWiki: Open && Target Milestone==1.22.0
 * Latest changes in Bugzilla
 * Assignees
 * Number of open tickets per bug assignee
 * Reports in ASSIGNED status with assignee and status not changed for more than 12months and without a comment "assigned>=1y" in square brakets (which Andre uses for marking) (cookie licking?)

Tables

 * All: Product×Component open
 * All: Product×Status
 * Wikimedia: Version×Component open

Growth charts

 * All Projects
 * MediaWiki
 * MediaWiki extensions
 * Wikimedia