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
 * Triage new incoming reports by making sure that sufficient information is provided, and setting priority if wanted by development teams
 * coordinating and organizing bugtriage (and community outreach via [[mw:Bug management/Triage|bugdays), and Bugzilla maintenance (taxonomy and configuration changes)
 * improving bug management documentation on the wiki
 * keep an eye on other feedback channels, like Village Pumps

Priorities for Q1/2013

 * Code or Reports:
 * Automated notifications on patch status from Gerrit into Bugzilla (Christian and Chad working on it; testing in 44441) - mostly done
 * Continue decreasing backlog of unprioritized reports by contacting teams
 * Continue to update and clean up Bug management related documentation
 * Social:
 * Regular monthly bugdays - Bug management/Meeting preparations -- first one on Jan29, 2013, integrated with cycle of QA/Weekly_goals
 * Community outreach: Make triagers feel more like being part of a Bugsquad group/team
 * Clarify interaction with ops/RT ("ops" keyword)
 * Clarify interaction with and Platform Eng ("platformeng" keyword)
 * Have a good and successful time with my Women Outreach Program student
 * Discuss with Release Manager the protocol for marking backport candidates (from git master to latest stable) in Bugzilla, and if handling of deployment blockers via current blocker bug is sufficient

Plans for Q2/2013

 * Social:
 * Push for regular meetings with development teams about prioritizing, triaging and tackling their bug reports
 * Document best practices in Bugzilla for developers and engineers to help them get the most out of Bugzilla
 * Have monthly IRC office hours on Bug management -- First one: http://lists.wikimedia.org/pipermail/wikitech-l/2013-March/067341.html
 * Bugzilla setup / code:
 * Set up Labs instance for Bugzilla (docs)
 * Code: New Bugzilla frontpage - 22170 - patch needs improvements, plus for better testing a Labs instance
 * Code: Install component watching extension, "See Also" field: GitHub, RT, Mingle support etc.; ["Zarro boogs" message; email instead of login string - need Labs instance for better testing
 * Replace "login" by "email address" - 24992
 * Replace "Zarro boogs" - 42467
 * Taxonomy: Discuss using classifications in Bugzilla, e.g. Saved Searches (as a first step to bug 38990 (Requests for comment/Bugzilla taxonomy)
 * "Deprecated" classification? Products closed for bug entry: Kate's Tools, Logwood, Wikimedia Mobile, Wiktionary tools
 * Mobile apps classification?
 * : right now, I'd add a 'commons' app. and possibly 'signpost' too.
 * e.g. move hidden https://bugzilla.wikimedia.org/describecomponents.cgi?action=edit&product=Tools&component=WikiSnaps
 * Consider providing a NEEDINFO bug status or a needinfo flag (depending on need by development teams) - bug 36064

Higher priority

 * Policy: Discuss (and document) access restrictions in Bugzilla. (See cf. http://wiki.meego.com/Quality/Bug_Access_Restrictions )
 * 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.
 * Kill RESOLVED LATER - see http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064264.html | Progress chart -- done 12/2012
 * Update and clean up bug management related documentation!: Bug management Doc Rewrite
 * 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) and E3's Trello: https://trello.com/b/FdtPTV2y as per https://meta.wikimedia.org/wiki/Editor_Engagement_Experiments
 * Docs: Instructions how to change default CC or default assignees? (examples: 13594, 15502) https://www.mediawiki.org/wiki/Bug_management/Project_Maintainers
 * Docs: Guidelines for creating new products in BZ? (examples: 12598,13023,12564,13138,15265,15168,37571,39072) - cf. https://live.gnome.org/BugzillaMaintainers/CreatingNewProducts for the admin PoV
 * Docs: Document who checks BZ security updates? I do.
 * Docs: create an UpstreamBugtrackers overview page : Bug_management/Upstream_bugtrackers
 * Docs: Policy: "upstream" keyword: "Somebody should upstream this" vs "Upstream ticket URLmust exist"
 * consider introducing a status WAITINGFORUPSTREAM like in Mer Bugzilla -- http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064288.html
 * Sort out old "MediaWiki%20extensions/Wikidata" component from OmegaWiki vs new Wikidata project - 20121108 by Chad
 * "Site configuration" component vs. "Side requests" (such as running cleanup scripts): https://bugzilla.wikimedia.org/show_bug.cgi?id=39644
 * Push for using "Version" field in reports (makes cleaning up and retesting way easier)
 * Versions: WMF-deployment vs upstream versions
 * Duplication: keywords vs tracker bugs or 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
 * Policy: shellpolicy vs shell keyword usage? (Talked to Dereckson, Krenair)
 *  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".
 * Voting: Some products support it, some don't.
 * If voting is NOT used as a source of information by developers, we should just disable it and add a comment about its current number of votes when doing so. Open tickets sorted by votes
 * Voting disabled by Max votes per person == 0 in Products: Analytics, Huggle, Monuments database, Parsoid, VisualEditor, WikiLoves Monuments Mobile, Wikimedia Labs, Wikipedia App, Wiktionary App. Voting enabled in all other products.
 * "WikiLoves Monuments Mobile" product = it's the app only. - inconsistent with "Wikipedia App"/"Wiktionary App" product naming then; no Versions used here! (Server side is "Monuments database" product)
 * Policy: Bump "Version" field in bug report if still reproducible in newer version?
 * Policy: how are branches handled? each branch to fix in one report, or using flags like Mozilla does "aurora = affected"?
 * Bugzilla 4.2 upgrade -- https://bugzilla.wikimedia.org/show_bug.cgi?id=33158
 * Show 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: https://bugzilla.wikimedia.org/show_bug.cgi?id=41197 but requires Bugzilla 4.2 for more than one condition
 * Hardware field (rep_platform) could be merged into Platform, but this requires editing the template (see http://www.bugzilla.org/docs/4.2/en/html/cust-templates.html ) - not wanted by Mobile team, go for https://bugzilla.wikimedia.org/show_bug.cgi?id=41197 instead
 * While upgrading (bugmail disabled):
 * Merge MW version numbers!, see https://bugzilla.wikimedia.org/editversions.cgi?product=MediaWiki&showbugcounts=1
 * Check Target Milestones and keywords whether anything should be changed or removed
 * "newphp" keyword vs tracking bug 30092 for PHP 5.4?
 * Properly set up Bugzilla testing instance at https://labsconsole.wikimedia.org/wiki/Nova_Resource:Bugtracker

Lower priority

 * Find out where code is located for stuff under "Tools" product in Bugzilla
 * extensions:
 * Which extensions are deployed in production (to reproduce; cf. bug 36738)? See and https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/tools/release.git;a=blob;f=make-wmf-branch/default.conf
 * Which extensions are deployed but should get killed? User:Malyacko/ExtensionsToUndeploy
 * all the patch keywords and the related process is utterly broken. State changes are nothing that you want to express via manually entering keywords. Consider something like a PATCH_TO_MERGE state before RESOLVED FIXED?
 * identify key triagers / potential bugsquad
 * start with / get into having monthly bugdays
 * Clean up / closing of components
 * Once check issues that have a "design" keyword set - https://bugzilla.wikimedia.org/buglist.cgi?keywords=design&keywords_type=allwords&resolution=---, after that recommend to Vibha and Munaf to have a saved search for this!
 * Retest or kill open Lucene Search tickets (superseded by MWSearch???): https://bugzilla.wikimedia.org/buglist.cgi?component=Lucene%20Search&product=MediaWiki%20extensions&bug_status=UNCONFIRMED&bug_status=NEW
 * Mark E Johnston told me via private email about the "Uniwiki" extensions (wikipage; open tickets in Bugzilla) that "i believe that these are not maintained anymore and it is safe to declare them obsolete/wontfix."
 * Clean up Calcey tickets and close as WORKSFORME/set moreinfo: https://bugzilla.wikimedia.org/buglist.cgi?emailreporter1=1&list_id=151776&email1=%40calcey.com&resolution=---&emailtype1=substring - We can safely assume that Calcey reporters won't be responsive.
 * Clean up open UsabilityInitative tickets https://bugzilla.wikimedia.org/buglist.cgi?list_id=152159&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=UsabilityInitiative&product=MediaWiki%20extensions as per https://bugzilla.wikimedia.org/show_bug.cgi?id=36111#c1
 * Clean up Uniwiki tickets and find out about its status? https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&list_id=154062&component=Uniwiki&product=MediaWiki%20extensions
 * WONTFIX "CodeReview" tickets? https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&resolution=LATER&component=CodeReview&product=MediaWiki%20extensions
 * deprecate "mwEmbed" product, as MWExtensions/TimedMediaHandler (according to mdale)
 * Cortado: Retest open tickets in that product, see https://bugzilla.wikimedia.org/show_bug.cgi?id=41274#c12 for the why. I've also asked on http://lists.xiph.org/pipermail/theora-dev/2012-October/004357.html
 * Extension:Readerfeedback (7 open reports) has been superseded by ArticleFeedback (plus requires NFS).
 * http://www.mediawiki.org/wiki/Extension:CodeReview and its open bug reports - probably dead at least for WMF once we switch off SVN.
 * design keyword workflow: improvements possible? Open tickets: https://bugzilla.wikimedia.org/buglist.cgi?keywords=design%2C%20&query_format=advanced&keywords_type=allwords&resolution=---
 * are there instructions somewhere for users how to provide a stacktrace when the Wikipedia App crashes on iOS? (e.g. 41027)
 * analyze priority field usage and how realistic it is, cf. http://www.mail-archive.com/mer-general@lists.merproject.org/msg00272.html
 * Add a field for gerrit IDs? Currently it's cumbersome to link between! - https://bugzilla.wikimedia.org/show_bug.cgi?id=39399 and https://office.wikimedia.org/wiki/User:Guillom/Collaboration
 * Docs: Role of wikibugs-l@ default assignee ? Just all bugmail? See https://bugzilla.wikimedia.org/show_bug.cgi?id=31790#c1
 * Policy: When are users blocked or insulting/useless comments hidden?
 * Policy: Who can be a BZ admin, and is a combination of other groups sufficient (admin = access to Security tickets)? cf. https://bugzilla.wikimedia.org/show_bug.cgi?id=37517 and http://meta.wikimedia.org/wiki/User_talk:Malyacko - Find out which exact tasks somebody wants to execute, and if membership in several Bugzilla groups like canconfirm, editbugs, etc might be sufficient. Needs documentation after agreement.
 * 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"
 * Collect stock answers, cf. https://wiki.maemo.org/Bugs:Stock_answers or http://wiki.meego.com/Quality/Bugtriage_Stock_Answers

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
 * RESOLVED LATER |
 * 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