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)

December 2013

 * Google Code-In: Run and organize contest with Quim.
 * Agree and finalize on "etiquette" for behavior in Bugzilla, as discussed on teampractices@. - incorporated feedback from teampractices@, now asked 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; first dzahn to set up Bugzilla 4.4 on zirconium in eqiad (see RT #4783 to track progress)
 * Deploy Bugzilla 4.4 to production., will need help from ops

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 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@. - Talk page feedback incorporated; asked 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.
 * Prepare / start testing upgrade to Bugzilla 4.4 (and our custom patches) - 49597:
 * CSS cleanup.
 * create custom patches for the 4.4 codebase. on 20131128 - 49597
 * test locally on 20131128 - 49597
 * test on labs (or zirconium in eqiad if production is still on kaulen in Tampa). ; after RT #4783 is solved
 * deploy to production.
 * 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



January to March 2014
 To be defined further 
 * 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.
 * (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; guidelines how to identify a bug good for this audience.
 * Better Bugzilla taxonomy: Discuss using classifications in Bugzilla and identify some initial non-controversial changes. - 38990., first small steps: 57738 , 54063, "Deprecated" classification for closed products, etc.
 * Bugzilla setup / code:
 * Common queries on Bugzilla frontpage - 22170. - preliminary patch available since 2013-12-15
 * Only after 4.4 upgrade: Provide a NEEDINFO flag in Bugzilla - 36064.
 * Only after 4.4 upgrade: 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. -- database issues when testing; not yet tested on 4.4 and upstream code is still 4.2 only.
 * Discuss and investigate splitting "enhancement" out of Bugzilla's "severity" dropdown and make it a separate checkbox. - 58096.

Backlog
Anybody is free to help and work on these items. Also check the open requests in Bugzilla about Bugzilla.


 * Continue documenting best practices in Bugzilla via blogpost miniseries. Anybody can do this! List of all episodes | Announcement on wikitech-l. Topics that are not covered yet and help is welcome:
 * Use of Whining Feature to receive reminders
 * How realistically are bug priorities set?
 * Organizing bugmail
 * Bugzilla's quick search, see Liz' post
 * Clean up: Triaging ancient likely invalid reports and closing of components:
 * Clean up / retest Calcey tickets and close them as RESOLVED WORKSFORME if not reproducible anymore, or set the whiteboard entry "aklapper-moreinfo" if not reproducible. Note: We can safely assume that Calcey reporters won't be responsive.
 * Feature requests under https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&product=Wiktionary%20tools should probably find a better place
 * "CodeReview" tickets might be WONTFIX (and the product should be closed for new bug entry but that latter part requires special permissions in Bugzilla): Find out by asking its maintainers/developers that nobody works on it anymore, as we have moved on to Gerrit for code review?
 * Triage remaining open tickets in the "mwEmbed" product (mostly superseded MWExtensions/TimedMediaHandler but still used as a fallback on some computers, e.g. older Microsoft Internet Explorer versions are great to test this)
 * Cortado: Retest open tickets in that product (reason). See my question on the Xiph mailing list.
 * Extension:Readerfeedback (open reports) has been superseded by ArticleFeedback(v5) so these tickets might need to end up as WONTFIX too at some point.
 * General bug documentation updates:
 * 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.)
 * Docs: Bug_management/Workflow explains which system is for which kind of requests, but needs cleanup, plus coverage of other tools such as https://mingle.corp.wikimedia.org/projects/ (see Mingle), RT and E3's Trello: https://trello.com/b/FdtPTV2y as per https://meta.wikimedia.org/wiki/Editor_Engagement_Experiments
 * Extend triage guide to also cover enhancement requests. This is a bit more special (e.g. when it comes to WONTFIXing etc.).
 * Extend triage guide by a "Special cases" section, covering how to
 * do fundraising banner testing: https://bugzilla.wikimedia.org/show_bug.cgi?id=25622#c2
 * get info for thumbnail cache purging issues: https://bugzilla.wikimedia.org/show_bug.cgi?id=46976
 * Bug documentation updates that require discussing with other stakeholders first:
 * Policy: Document to bump the "Version" field in bug report if still reproducible in newer version
 * Make meanings of resolutions/statuses clearer (in Bug_report_life_cycle or How_to_triage?), e.g. when to set WONTFIX (and when not), and after how much time to close a report without enough information as WORKSFORME? Also, meaning of UNCONFIRMED currently is "not clear if it's a valid bug", but might become "not reproduced or seen by anybody else yet"? (This was OPW feedback from Valerie.)
 * Talk to Mobile team: Are there instructions somewhere for users how to provide a stacktrace when the Wikipedia App crashes on iOS or Android? (e.g. 41027)
 * design keyword workflow: Improvements possible? Talk to design team. Open tickets: https://bugzilla.wikimedia.org/buglist.cgi?keywords=design%2C%20&query_format=advanced&keywords_type=allwords&resolution=---
 * 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: shellpolicy vs shell vs ops keyword usage? 45539
 *  Usually shellpolicy 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. shellpolicy is always turned into shell after clarification that community consensus exists. So shellpolicy basically always means "proof of consensus needed".
 * Encourage reporters to use the "Version" field in reports (metadata makes cleaning up and retesting way easier in a few years)
 * Analyze the "Priority" field usage from time to time, and how realistic it is (cf. Mer)
 * Consider collecting stock answers, cf. Maemo or MeeGo

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


 * Clean up: Duplication of information: 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
 * Documentation: Document the role of the wikibugs-l@ default assignee and its setting as [www.bugzilla.org/docs/4.2/en/html/parameters.html#param-email globalwatcher]? See 31790 and 44929
 * Voting in Bugzilla: Some products support it, some don't.
 * If voting is NOT used as a source of information by developers, discuss disabling it and add a comment about its current number of votes when doing so - Open tickets sorted by votes
 * This would require a script: Run "USE bugs; SELECT bug_id, votes FROM bugs WHERE votes > 0" in the MySQL database, then for each output line take the bug_id and the number of votes and paste a comment on that report by using the interface (and disable bugmail before so we don't trigger 2400 notification emails).
 * Currently voting disabled by Max votes per person == 0 in Products: Analytics, Huggle, Monuments database, Parsoid, VisualEditor, WikiLoves Monuments Mobile, Wikimedia Labs, Wikipedia App. Voting enabled in all other products.
 * Discussions in a number of communities that use Bugzilla, to consider:
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=49728
 * http://lists.wikimedia.org/pipermail/wikitech-l/2005-June/017829.html
 * https://mail.gnome.org/archives/desktop-devel-list/2004-March/msg00142.html and https://mail.gnome.org/archives/desktop-devel-list/2004-March/msg00149.html
 * http://timj.testbit.eu/2010/09/09/09-09-2010-request-to-support-voting-in-gnome-bugzilla/ and https://bugzilla.gnome.org/show_bug.cgi?id=629161
 * http://www.abisource.com/mailinglists/abiword-dev/02/Jan/0450.html
 * https://wiki.documentfoundation.org/QA/Bugzilla/FAQ#Bugzilla_Voting.3F and related https://bugs.freedesktop.org/show_bug.cgi?id=39739
 * http://wagenknecht.org/blog/archives/2007/11/how-relevant-is-bugzilla-voting.html
 * https://bugs.eclipse.org/bugs/show_bug.cgi?id=12115
 * http://www.scrye.com/wordpress/nirik/2010/09/02/bugzilla-bugs-and-voting/
 * https://lists.fedoraproject.org/pipermail/devel/2010-September/142472.html
 * http://en.wikipedia.org/wiki/Wikipedia:Bug_reports_and_feature_requests#Voting
 * Number of open tickets with X votes in Wikimedia Bugzilla
 * Next time we upgrade Bugzilla (and can disable bugmail):
 * Merge MediaWiki Version numbers (e.g. all the 1.18s to "1.18.x" to get a shorter dropdown (list, edit)
 * Remove wikibugs-l@ from default CCs for security reasons
 * Check Target Milestones and keywords whether anything should be changed or removed
 * Consider showing some custom fields (Web browser, used in 318 reports, Usage chart per product, Usage chart per value; Mobile platform, used in 485 reports, Usage chart per product, Usage chart per value) only for specific products/components: 41197
 * Hardware field (rep_platform) could be merged into Platform, but Mobile Team reluctant, see discussions 41197, 40936, 45759
 * 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, explaining the situation, and add a "svn-unmaintained" status whiteboard entry so they could be identified later per component in case somebody wants to pick up development again. Also see Git/Conversion/Extensions_queue.
 * Priority and Target Milestones are kind of related, hence maybe get rid of one? (Kudos to Robla and Krinkle here for input and thoughts.) Like: highest priority = next point release, high = this release cycle, etc. Might be good to restrict access to Priority though, see https://bugzilla.mozilla.org/show_bug.cgi?id=81457 or use "letsubmitterchoosepriority"
 * Potential remove "trivial" severity as that is covered by the easy keyword. IMHO it is not a severity, as a bug could be both critical and trivial, e.g. a typo that leads to a crash.

Finished / completed tasks
Also see the weekly status updates for more verbose information.
 * 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), mw:Category:Extensions_used_on_Wikimedia, Gerrit
 * 201111: Bigger updates to [mw:Bug_management/How_to_triage|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