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]

Monthly Goals[edit | edit source]

April 2014[edit | edit source]

  • (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. Status:    In progress
  • (With Guillaume) Likely have another IRC office hour about Project management tools Status:    Not done
  • Gather more feedback on rebooted Annoying little bugs after GSoC start Status:    Not done
  • Prepare introducing "Bug of the week" by talking to development teams Status:    Not done
  • Have a bugday in the second half of April (have to define topic first) Status:    Not done
  • to be continued

Quarterly Goals[edit | edit source]

April to June 2014[edit | edit source]

To be further defined

  • (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)
  • Have a public bug day approximately once per month.
  • Some more Bugzilla taxonomy cleanup. - bugzilla:38990
  • Investigate closing components of extensions archived in the code repository. - bugzilla:47540
  • Investigate splitting "enhancement" out of Bugzilla's "severity" dropdown and make it separate. - bugzilla:58096; low priority & only if we stick with Bugzilla


Backlog[edit | edit source]

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:
  • 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. bugzilla: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? bugzilla:45539
      • <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".
  • 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[edit | edit source]

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

Finished / completed tasks[edit | edit source]

Also see the weekly status updates for more verbose information.

Other stuff[edit | edit source]

Random Bugzilla queries[edit | edit source]

See also: wmfBugZillaPortal

Tables[edit | edit source]

Growth charts[edit | edit source]