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)

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 (graph) by contacting teams
 * Continue to update and clean up Bug management related documentation
 * Enhance "Weekly Bug Summary" email on wikitech-l to have correct data and be more useful - 45770 - all done except for listing urgent tickets
 * Social:
 * Regular monthly bugdays - Bug management/Meeting preparations -- first one on Jan29, 2013, integrated with cycle of QA/Weekly_goals
 * Community outreach: Make triagers part of Bugsquad (identify key triagers and actively contact them)
 * Clarify interaction with ops/RT ("ops" keyword) - regular triage meetings with mw:User:Mutante of ops
 * Clarify interaction with and Platform Eng ("platformeng" keyword) - regular triage meetings with Greg (Release Manager)
 * 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 - see announcement

Plans for Q2/2013
Note: I sometimes overreach with plans but it helps keeping me busy, so I consider it okay if one or two items might remain not fully resolved. Plus help is always welcome. :)


 * Social:
 * Discuss (and document) Bugzilla access restrictions and especially guidelines for Bugzilla admins (cf. MeeGo docs) and access to Security tickets. Cf. 37517 and question by MZMcBride - membership in several Bugzilla groups like canconfirm, editbugs, etc might be sufficient
 * 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, e.g. in a miniseries linked from Bug management - anybody can do this!
 * User Watching, cf. this blogpost
 * Saved Searches, also cover to share them with the "bz_canusewhines" group
 * Use of Whining Feature to receive reminders
 * Autocompletion of fields like CC and assignee, avoids errors when email addresses do not exist
 * How to exclude "lowest" and "unprioritized" priorities from queries, to keep the noise out
 * Using tables displaying priority x severity - e.g. used by I18N for triaging
 * Have monthly IRC office hours on Bug management -- First one on 20130319
 * 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.; Cryptic "Zarro boogs" message; "email" instead of "login" string - need Labs instance for better testing
 * Taxonomy: Discuss using classifications in Bugzilla (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, Tools/dbzip2
 * Consider providing a NEEDINFO bug status or a needinfo flag (depending on need by development teams) - bug 36064

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


 * Docs/Policy: 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.)
 * Docs: 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) and E3's Trello: https://trello.com/b/FdtPTV2y as per https://meta.wikimedia.org/wiki/Editor_Engagement_Experiments
 * The patch keywords and the related process is utterly broken. State changes are nothing that you want to express via manually entering keywords. Consider introducing a bug status before RESOLVED FIXED but only after 17322 got fixed. Related: 39399, 39402
 * design keyword workflow: improvements possible? 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
 * Retest Search tickets are currently in four different components, consider simplification
 * Encourage reporters to use the "Version" field in reports (metadata makes cleaning up and retesting way easier in a few years)
 * Versions in Bugzilla: WMF-deployment (Wikimedia) vs upstream versions (MediaWiki) vs branches (MediaWiki extensions)
 * 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".
 * 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 (which would require running a script) - Open tickets sorted by votes
 * Last discussion on this topic in 2005
 * 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.
 * Policy: Document to bump the "Version" field in bug report if still reproducible in newer version
 * 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
 * Find out where code is located for stuff under "Tools" product in Bugzilla and update/link to it from the Bugzilla product and component descriptions
 * 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
 * Clean up: Triaging ancient likely invalid reports and closing of components:
 * 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.
 * Check tickets that have a "design" keyword set, after that recommend to Vibha and Munaf to have a saved search for this!
 * 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 - We can safely assume that Calcey reporters won't be responsive.
 * Clean up open UsabilityInitative tickets as per 36111
 * Clean up Uniwiki tickets and find out about its status?
 * WONTFIX "CodeReview" tickets and close product for new bug entry?
 * Triage remaining open tickets in the "mwEmbed" product (mostly superseded MWExtensions/TimedMediaHandler but still used as a fallback on some computers)
 * Cortado: Retest open tickets in that product (reason). See my question on the [http://lists.xiph.org/pipermail/theora-dev/2012-October/004358.html Xiph mailing list.
 * Extension:Readerfeedback (open reports) has been superseded by ArticleFeedback (plus requires NFS).
 * Feature requests under https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&product=Wiktionary%20tools should probably find a better place
 * are there instructions somewhere for users how to provide a stacktrace when the Wikipedia App crashes on iOS? Ask mobile team (e.g. 41027)
 * Analyze the "Priority" field usage from time to time, and how realistic it is (cf. Mer)
 * Consider adding a field for gerrit IDs? Currently it's cumbersome to link between - 39399 and User:Guillom/Collaboration
 * Docs: 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
 * 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"
 * Consider collecting stock answers, cf. Maemo or MeeGo
 * 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)
 * Check Target Milestones and keywords whether anything should be changed or removed

Finished / completed tasks
Also see the weekly status updates for more verbose information.


 * 20130322: Taxonomy: Merged several mobile apps - 41922
 * 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
 * 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