User:AKlapper/WildIdeas

From Wikimedia Foundation Governance Wiki

Random thoughts, ideas and items in no particular order and stuff that I might take a look at as Wikimedia's bug wrangler.

Higher priority

  • study keywords, understand / improve descriptions
  • Investigate existing bug triaging on Thursday
  • Close WebFonts component and move to jquery.uls? https://bugzilla.wikimedia.org/show_bug.cgi?id=40539#c8
  • update and clean up bug management related documentation! - https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_100#Improving_Documentation_on_Handling_Bug_Reports
    • Bugzilla vs. rt.wikimedia.org (non-public for operations, keyword "ops" -- who keeps this in sync?) vs. OTRS (ticket.wikimedia.org/otrs)
    • Instructions how to change default CC or default assignees? (examples: 13594, 15502)
    • 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
  • Policy: "upstream" keyword: "Somebody should upstream this" vs "Upstream ticket URLmust exist"; consider introducing a status WAITINGFORUPSTREAM like in Mer Bugzilla
  • look at Bugzilla admin settings
  • labsconsole vs wmflabs vs test2.wp vs test.wp?
  • who checks BZ security updates? opers?
  • Currently meta/tracking bugs (blocks/depends on) seem to be used for release management. For community members that want to propose an issue to be a blocker this requires knowing the exact bug ID of the tracking bug, plus anybody can add anything to make it a blocker. Consider using flags to request making a ticket a blocker - https://bugs.merproject.org/editflagtypes.cgi?action=edit&id=1
  • 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:
    • newparser keyword vs Parsoid product: talk to James_F (James Forrester) (PM for Parsoid)
    • analytics keyword vs Analytics product (and Wikimedia/Statistics)
    • newphp keyword vs PHP4.x tracking bug 30092
    • tracking keyword vs tracking meta bug 2007
  • shellpolicy vs shell keyword usage? (Talked to Dereckson, Krenair)
    • <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".
  • look into open Bugzilla bug reports: https://bugzilla.wikimedia.org/buglist.cgi?product=Wikimedia&component=Bugzilla&resolution=---&debug=1
  • Bugzilla: Reorganize products, use classifications? - https://bugzilla.wikimedia.org/show_bug.cgi?id=38990
    • Products closed for bug entry ("Deprecated" classification): Kate's Tools, Logwood, Wikimedia Mobile, Wiktionary tools
    • Mobile apps?
  • Voting: Some products support it, some don't.
    • 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"?
  • Policy: No needinfo/moreinfo? - after upgrade to 4.2 consider new moreinfo flag extension upstream
  • "newphp" keyword vs tracking bug 30092 for PHP 5.4?

Lower priority

Long term / Continuous

Random Bugzilla queries

Tables

Growth charts