User:AKlapper/WildIdeas
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)
- Define workflow for ops in case that ops don't look a lot at Bugzilla, e.g. for forwarding to rt?
- 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
- Bugzilla vs. rt.wikimedia.org (non-public for operations, keyword "ops" -- who keeps this in sync?) vs. OTRS (ticket.wikimedia.org/otrs)
- Policy: "upstream" keyword: "Somebody should upstream this" vs "Upstream ticket URLmust exist"; consider introducing a status WAITINGFORUPSTREAM like in Mer Bugzilla
- create an UpstreamBugtrackers overview page, cf. http://wiki.meego.com/Quality/UpstreamBugTrackers
- http://bugs.jquery.com
- HipHop for PHP: https://github.com/facebook/hiphop-php/issues - fix keyword to link
- Selenium for automated browser testing: http://code.google.com/p/selenium/issues/list - fix keyword to link
- Wikimedia Toolserver: https://jira.toolserver.org/secure/Dashboard.jspa
- GeSHi: http://sourceforge.net/tracker/?group_id=114997&atid=670231
- Opera Browser: https://bugs.opera.com/wizard/
- pywikipedia: http://sourceforge.net/tracker/?group_id=93107
- Gerrit: http://code.google.com/p/gerrit/issues/list
- Leaflet (Maps on Mobile): https://github.com/CloudMade/Leaflet/issues
- Google Chrome: http://code.google.com/p/chromium/issues/list
- Jenkins: https://issues.jenkins-ci.org/
- Wikimedia Deutschland's "Toolserver": https://jira.toolserver.org/
- create an UpstreamBugtrackers overview page, cf. http://wiki.meego.com/Quality/UpstreamBugTrackers
- 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) --> 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
- 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.
- 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"?
- 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
- Consider applying for Google Code-In this year: http://lists.wikimedia.org/pipermail/wikitech-l/2012-October/063997.html
- extensions: which ones are actively maintained? are reports properly triaged? are there dead components? Which ones have not been moved from Git and can be considered dead? See http://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue
- Cortado: "Since release 0.5.0 development is done at the Xiph.org foundation." - close open tickets? close for new bug entry?
- 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
- Cleanup 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
- 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
- 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
- Which extensions are deployed in production (to reproduce; cf. bug 36738)?
- 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
- 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 )
- Consider using "Field only appears when" if only required for certain team, however only accepts one condition
- 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
- Role of wikibugs-l@ default assignee ? Just all bugmail? See https://bugzilla.wikimedia.org/show_bug.cgi?id=31790#c1
- Policy: Are access restrictions sometimes needed? When? cf. http://wiki.meego.com/Quality/Bug_Access_Restrictions
- 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 - 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"
- add my IRC office hours? - https://secure.wikimedia.org/wikipedia/meta/wiki/IRC_office_hours
- Merge http://www.mediawiki.org/wiki/User:Malyacko / wikimediafoundation.org/wiki/User:AKlapper / http://www.mediawiki.org/wiki/User:Andreklapper
Long term / Continuous
- set priorities of new reports
- Dive deeper into Gerrit
- Follow translatewiki issues: bug 39480
- keep an eye on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29
- understand L10N process?; Play with translatewiki.net/Thread:Support/Accepting_translations
- understand wikidata; https://meta.wikimedia.org/wiki/Wikidata/Contribute
- Collect stock answers, cf. https://wiki.maemo.org/Bugs:Stock_answers or http://wiki.meego.com/Quality/Bugtriage_Stock_Answers
Random Bugzilla queries
- filed in the last 7d: open all | closed ≤7d |
- open without response: all non-enhancement only
- without changes for 2yrs
- [1] No comments from anybody else than reporter]
- more than 20 votes
- RESOLVED LATER |
- Open bugs for Bugzilla itself
- MediaWiki: Open && Target Milestone==1.20.0