User:MarkAHershberger/Weekly reports/2011-01-24/log/2011-01-18

cr and bugs are all the same in CR you get developers sending crap and other marking them fixed in BUG you get user complaining about crap and developer fixing them
 * Talked to Hashar about what he thinks the bugmeister should be doing
 * He gave me the idea of a developer & OPS survey
 * Use Zak since he did one for the tech docs.
 * Other ideas from Hashar:
 * Document the actual process “Who When What ...”
 * make sure devs answer cleanly to user requests
 * Review the Bugzilla Lifecycle
 * actually we do not close / verify bug (since we have no QA)
 * we are lacking the unconfirmed state which might be helpful
 * Metrics (like CRStats)
 * bugzilla probably have extensions/plugins to handle all of that
 * Talk to Project Managers (e.g guillom)
 * Guillom
 * Scaling up Software Development
 * split the bug tracker, one for MediaWiki, the other for site operations
 * Conversation with Robla (re bugmeister)
 * Focus on little victories
 * Things that are easy
 * Things that make life better now
 * Shell bugs
 * Hard OPS
 * Bug#323
 * oh what a tangled web we weave
 * Hard POLICY
 * Bug#5220
 * Someone needs to decide what to do
 * Focus on Quantity, not quality
 * mistakes are excusable and will happen.
 * Create way to find (easy and hard tracking bug?)
 * List of 20 bugs
 * Give to CT Woo
 * Talk to CT Woo about when he'll be ready
 * How do we use priority
 * use it to push devs and ops
 * Look at extensions that aren't widely used less
 * assign unassigned bugs
 * Harder to categorize go to bug triage meeting
 * Bugs are assigned to PM responsible for area
 * Job is to make sure the decision is made, not necessarily to to make decision
 * Split between kicking at backlog and dealing w/ new bug?
 * Deal with new bugs to figure out what happens
 * Maybe a month into it start looking at backlog
 * PRIMARY GOAL: Make sure nothing big slips through the cracks.
 * Core issues: focus on WMF stuff.
 * Go backwards in time. Focus on new and then go back.