User:Sharihareswara (WMF)/archivedectmeetings Feb2013

Feb 5 meeting
Attendance: Sumana, Andre, Chris, Guillaume, Quim, Željko Sadly absent: RobLa Agenda: (reviewed) https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering

Wikimedia QA IRC channel or mail list or open other direct channels?
Sumana: Should we have a separate Wikimedia QA IRC channel? (especially for bug days) Chris: #mediawiki is noisy. #wikimedia-dev is more useful. No other channels are really appropriate. Chris: VE community test announcement went to wikitech-l, wikitech-ambassadors, mediawiki-i18n. Are those appropriate or did we spam them? (Guillaume: these are *exactly* the right channels for that event) Chris: We got ZERO response from any of them. Guillaume: Were you trying to start a discussion (and therefore expecting responses), or were you trying to get the word out (and therefore the e-mails were just aimed at encouraging people to join IRC or so)? Chris: I was trying to get bug reports for VE :-). But we didn't even get any email response, nor IRC discussion, nor Bugzilla tickets.  We did add a tester to Features, Phil Kirkham, who also blogged us for Software Testing Club and will blog it for Atomic Object, but Phil came in via my blog/twitter.    Guillaume: I'm personally of the opinion that we already have *way* too many IRC channels / mailing lists, and fragmenting discussions weakens them Andre says: in #wikimedia-dev, there might be people who came in and wanted to join the BugDay but were shy because there was so much other discussion happening Guillaume: Perhaps a good compromise would be a dedicated channel for events, or better yet one for non-coding activities, but not specifically QA? Like -office? (Quim) -office is more for IRC office hours, I'm not sure I say we try it - it's full of people who are interested in participating & giving their feedback on Wikimedia stuff Maybe consider a channel for non-coders? Like, testers & product managers? feeling tentative We might try again, do as Sumana say, and actually raise the topic during the QA activity to see what others idling in that channel think, plus the ones coming for the QA activity. (Quim) Next steps:
 * For the next bug day, probably try #wikimedia-office
 * Go ahead and greet every person who shows up even if it feels a little foolish
 * Ask the residents of the channels what they think

mw:Project:Calendar
https://www.mediawiki.org/wiki/Project:Calendar Guillaume: Are you using it? Do you have issues? Is it useful to you? Željko: Should this be added to the calendar? http://www.meetup.com/Wikipedia-Engineering-Meetup/events/100444752/ Guillaume: Yes, absolutely :)

Other topics
Chris: Opportunity to support E2 via community testing messaging, Echo on mediawiki.org (next week) and AFTv5 trial period to French and German wikipedias (March) Can we frame the Echo & AfT trial periods as testing exercises & make a big improvement in E2 marketing/messaging? Chris is talking about being in position to handle feedback quickly and well, especially negative feedback. It'd be nice if we could test both Echo & AFT to make sure that the features are serving the users, rather than being surprising or unwelcome. Goal: let's see what the actual quality is, and whether the functionality works Larger issue: what are the levels of scrutiny and attention we give to various components & features?
 * 1) Bottom level: "testing in production" (default) - Andre looks at incoming BZ tickets & nearly always puts them in the right product/component, and tries to prioritize them
 * 2) Middle level: Look actively on village pump-style fora, post to wikitech-ambassadors, maybe post to social media & ask Andre to be more forceful in cc'ing relevant people on bugs
 * 3) Top level: full force scrutiny!  Writing automated tests, looking hard on village pump-style fora for bug reports, hosting test days and bug days, assigning community liaisons to gather feedback more actively, maybe even hiring contractors.
 * See QA/Features_testing/levels

Quim asks Chris to write down his goals for the Echo & AfT stuff Can we ameliorate misfeatures by testing? Chris is concerned with the impedance mismatch between developers & users .... we might not be serving their needs. Let's be more proactive. Chris is looking at https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Article_feedback Let's be more iterative.... We should be working with the product team on getting more feedback to them, yes! On outreach for VE testing day -- it'd be more effective to do personal outreach, send personal emails to the people who would be interested Chris: Can we move testing Groups out of "Proposal" status? What does that look like? (I miss more people and more diverse in each group. But it is ultimately the presentation of the proposal to the AffCom and the acceptance what decides when a group is not a proposal anymore - Quim) Quim: I want to take the chance to walk you in 1-2 minutes through the Wikimedia DE offices so you see the Wikidata team and surroundings. Quim: by now I have been pitching https://www.mediawiki.org/wiki/How_to_contribute/Presentation a dozen times or more, combined with the creation of groups and the message seems to be convincing. Let's see if it does bring groups but at least it opens the eyes of people thinking that all we do is PHP development on a wiki engine.
 * Sumana & Chris to talk about connection to Ops
 * Resolved

Quim will spread the word about this ready-to-reuse presentation! (it would help if presentation notes were added, for presenters who need help to elaborate on the slides)

Bug management

 * QA/Weekly Goals:
 * Rotten bugs next week: Retest/triage AFTv5 bugs? (currently discussed in email with fflorin etc. - first needs better documentation which AFT designs are obsolete) -- andre
 * Low-key AFTv5 community test underway, next one TBD.
 * Feb 11 QA: Write your first Test Scenario in plain English
 * Chris to postpone this due to conflict

Other
documentation on mediawiki.org, wikitech, meta: ongoing discussion on wikitech-l Conferences, travel, etc.
 * Chris has been invited to Google Test Automation Conference April 23-24, would really like to go.
 * Chris and Zeljko in SF Feb 18-Mar 1
 * Andre in SF Feb24-Mar3
 * Guillaume in SF Feb 25 to Mar 1

Announcements
https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering in case anyone wants to discuss their statuses
 * GSoC
 * IEG

(Micro)tasks for volunteers to get involved
https://blog.wikimedia.org/2012/11/21/lead-development-process-product-adviser-manager/ listed the following areas: Open questions: In a nutshell, what we need is: Have a discussion with Howie, James F. about volunteer involvement in product development
 * File storage, especially regarding Wikimedia Commons.
 * Prioritizing shell requests.
 * Operations requests from the community.
 * Data dumps. (ariel, maria)
 * Wikimedia Labs / Beta cluster (Sumana, Chris McM.)
 * Admin tools development (Chris Steipp, James F.)
 * Search (prioritizing bug list?)
 * Lua
 * Flagged Revs?
 * Do we focus on those areas and leave the other Wikimedia engineering activities for later? Do we want to push all engineering groups towards maintaining "Get involved" sections and tasks for all projects, or do we want to do this push in Platform only for the moment because that's where Rob has authority?
 * Sumana: Features, language and mobile already sort of have product managers; the areas that remain (platform, ops & offline) are the areas where product help is most needed
 * And possibly accessibility
 * Is the list above still up-to-date? e.g.:
 * Are shell requests & ops requests now handled by Andre and his team of triagers?
 * shell requests: basically no change, they get tagged with that keyword and then volunteers can pick up and create a gerrit patchset. Nothing triageteam-specific. -- andre
 * Meeting every fortnight with mutante & aklapper re "ops" keyword.
 * Re shell: changesets made by volunteers, Sam usually deploys it
 * James Forrester is listed as product manager for Admin tools: is help still needed?
 * Sumana says yes
 * Lua isn't on the list; do we consider that Kozuch is handling this on his own? Or do we still want to have a list of tasks
 * Kozuch is on this.
 * He needs a list of tasks.
 * Would it make sense to add "bug management" and "QA" to the list? i.e. not necessarily to Product-manage those activities, but to have a list of tasks for volunteers?
 * Makes sense to point to existing TODO lists
 * +1 - Quim
 * Once we have an up-to-date list, we need contacts for each activity, i.e. people we can reach out to to maintain the list of tasks. For example, on "File storage", we need to ask the person in charge what exactly they need help with. And we need to do that for every single activity we want tasks for.
 * Sumana suggest to use the "Maintainers" list to know who to ask for each activity
 * An up-to-date list of activities that need help
 * At least 1 contact for each activity with whom we can work to create and maintain a list of tasks
 * Ask James: what are you working on?
 * It is probably better to have less items / products and focus on getting PMs for those, as opposed to have a wide collection that we can't handle ourselves.
 * I think previous discussions established that we want to encourage "come and go" tasks instead of formal PM roles
 * OK, but it needs to be clear for ourselves what products are top priority and we are active, and then the rest.
 * agreed

Agenda for quarterly review for 26 February
Questions to address (agenda) http://etherpad.wmflabs.org/pad/p/ECT-weekly
 * 1) What BENEFITS have we already offered the organization? (where ECT has moved the needle)
 * https://strategy.wikimedia.org/wiki/Product_Whitepaper
 * https://strategy.wikimedia.org/wiki/Strategic_Plan/Movement_Priorities#Goals


 * 1) What LESSONS have we learned?
 * 2) What INPUT are we seeking? (list)
 * 3) What TIMELINE are we planning for the next 3 months?
 * 4) Q&A/discussion.

Travel next week

 * Now's a good time to reach out to people in SF and arrange to meet with them

Bugzilla admin rights
Come up with guidelines and requirements who should be Bugzilla admin and why. Nothing in place currently, number growing -> coordination and security issue, plus do non-employees need an NDA? RFC planned for later this week by Andre.

The Wheel
https://www.mediawiki.org/wiki/Project:Calendar Is this going well? Let's look again in 4 weeks.
 * Are we making sure everyone knows who's in charge of what and the calendar is clear?
 * Are we trying to do too much (and therefore losing quality)?
 * Need to balance scalability in getting contributors & one-on-one contact

Last week, ran a very low-key AFT test (they have a test env) - didn't get attention from outsiders Not every software project is amenable to testing on a monthly schedule.
 * Quim & Chris to talk about this

How we prioritize what features to test
Who's working on the process for ensuring we test a variety of features and  balance testability, urgency, movement goals, etc.? (Including exploratory testing & test automation)
 * Delayed till next week.

Meetings this week
To schedule:
 * today - ECT quarterly review, 11:30-1:30
 * Wikidata discussion today
 * Jenkins test isolation today 1PM
 * Testing products and features today 4:00 -- QA prioritizing some projects over others
 * Luis, re Toolserver: Wed 8am
 * Asheesh & OpenHatch: Wed 8:30am
 * Giant budget meetings - Wed afternoon 1-4
 * Testing E2 Wed 3PM
 * Lua/Scribunto outreach - Thurs 11am
 * Techtalk (Hangout): 12:30pm Thursday - Željko on browser test automation - Quim as driver
 * Beta labs/MobileFrontend Thu 12:30PM (if necessary)
 * MediaWiki core quarterly review - Thurs afternoon
 * TechOps brownbag: Friday noon
 * Josh & Katie - meet with Andre & Guillaume & Sumana - how to publicize DonationInterface/Smashpig work - Thurs or Fri

Bug management
talk about how far into rt management we're going, in bug mgmt How often should we have escalation & triage meetings? & with whom? Depends on the area. Every 2 weeks triage for rotten bugs. Every week for fresh bugs. https://www.mediawiki.org/wiki/Project:Calendar - Bug days are every two weeks - alternate between 'fresh' and 'rotten' bugs, so fresh bugs and rotten bugs once a month, if that makes sense. Bug mgmt -- is he always checking new bugs in preference to old ones? and what order is he tackling them in? General info on "urgent"/important bug handling:
 * Next WMF deployment tracker bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=38865
 * Table that andre uses for bug reports with Priority×Severity for MW, MWext, Wikimedia: https://bugzilla.wikimedia.org/report.cgi?x_axis_field=priority&y_axis_field=bug_severity&z_axis_field=product&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=MediaWiki&product=MediaWiki+extensions&product=Wikimedia&resolution=---&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailtype1=substring&email1=&emailtype2=substring&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap
 * List of highest & immediate priority bug reports and their last change: https://bugzilla.wikimedia.org/buglist.cgi?priority=Immediate&priority=Highest&order=Last%20Changed&columnlist=bug_id%2Cproduct%2Ccomponent%2Cpriority%2Cbug_severity%2Cbug_status%2Cshort_desc%2Cchangeddate%2Cassigned_to&resolution=---&product=MediaWiki&product=MediaWiki%20extensions&product=Wikimedia&list_id=182467

Uploading photos on mobile -- outreach tactics

 * http://www.mediawiki.org/wiki/Mobile_QA/Commons_uploads
 * http://www.mediawiki.org/wiki/Mobile_QA/Commons_uploads#Results

Review of agenda for quarterly meeting
https://www.mediawiki.org/wiki/Volunteer_coordination_and_outreach/ECT_Feb_2013_quarterly_review

Upcoming talks
March 9th - OSBridge deadline Amsterdam - this week there will be decisions re attendance Željko's talk re Selenium was accepted! June Bug Day Blog Posts Drafts: https://meta.wikimedia.org/wiki/Wikimedia_Blog/Drafts/Bug_Days