Bug management/Task list

From MediaWiki.org
Jump to: navigation, search

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[edit | edit source]

  • 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 Goals[edit | edit source]

Monthly goals and tasks are now tracked for "Aklapper" (the bugwrangler) under the corresponding monthly ECT (Enginnering Community Team) project in Phabricator. See the ECT board and the corresponding monthly sprints and their boards.

Quarterly Goals[edit | edit source]

October to December 2014[edit | edit source]

Backlog[edit | edit source]

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 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. 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 permissions[edit | edit source]

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[edit | edit source]

Also see the weekly status updates for more verbose information.

Other stuff[edit | edit source]

Random Phabricator queries[edit | edit source]

See Bug management/Phabricator queries.

Random Bugzilla queries[edit | edit source]

See also: wmfBugZillaPortal

Tables[edit | edit source]

Growth charts[edit | edit source]