Auto-tools/Automation Development/Meetings/WorkWeek July2011

From MozillaWiki
Jump to: navigation, search

Overview

Date: July 25th - 29th
Attendees: David B., Henrik S., David C., Dave H., Owen C., Geo M., Anthony H., Matt B.
What: Automation Services Workweek UnCon
Notes ashughes

Meeting Space

Where:

# Cambridge, UK

Twitter Hash

http://twitter.com/#!/search?q=%23mozautoqa

Agenda

Schedule Topic
Monday
10am - 12pm & 1pm - 3pm
Create agenda - compiled list of sticknote topics http://mozqa.sync.in/54
Tuesday
10am - 12pm & 1pm - 3pm
http://mozqa.sync.in/56
Wednsday
10am - 10:50am, 11am - 12pm & 1pm - 1:50pm, 2pm - 3pm
http://mozqa.sync.in/58
Thursday
10am - 10:50am, 11am -12pm & 1pm - 1:50pm, 2pm - 3pm
http://mozqa.sync.in/64
Friday
10am - 10:50am, 11am - 12pm & 1pm - 1:50pm, 2pm - 3pm
http://mozqa.sync.in/65

Monday

Reserved for planning out the work week. Prior to the work week we used a scrumpad to capture a few ideas.

  • 10am  - 3pm - Planning, break for lunch at ~12pm
  • 6pm Springboard Pitches
  • Topic generatation: link to sticknote topics http://mozqa.sync.in/54

Tuesday

  • 10am - 12pm and 1pm - 3pm,
    • New Members
    • Internal Team Communication
    • Team Dynamics

Notes from the day - http://mozqa.sync.in/57

Wednesday

  • Team responsibilities
  • Code Reviews
  • Community

Notes from the day - http://mozqa.sync.in/58

Thursday

  • 10am - 10:50am - Workflow
  • 11am - 12pm - Goals
  • 12pm - 1pm - Lunch
  • 1pm - 1:50pm - Internal team communication (loop back conversation)
  • 2pm - 3pm - - External team communication

Notes from the day - http://mozqa.sync.in/64

Friday

  • 10am - 10:50am - Infrastructure
  • 11am - 12pm - Group Documentation
  • 12pm - 1pm - Lunch
  • 1pm - 1:50pm - Meetups/Events
  • 2pm - 3pm - From topic backlog/retrospective

Notes from the Day http://mozqa.sync.in/65

Summary and Action Items

New Members

Summary

As a way to integrate more people into the team, the team has decided that we need to make sure that employees, contractors and contributors. To this end we need to make sure that the documentation that we create fits this. We need to make sure that we give both new members and mentors the information that they may require. We need to make sure

Actions

  • David C to create initial documents on QMO and share that with the team to get feedback
    • split out documents if they have a better fit on other sites (Wiki, MDN, etc)
  • Team to get a few questions together for interviews and share with QA as a whole.
    • Have a page with interview questions for a number of different levels to spread the load of interviews.
    • Set of questions that we can give to recruitment
  • Have an on ramping document with milestones for first X months
  • Get a overview of projects
  • Have a document structure allows contributors
  • "how to" for mentors on the wiki


Community

Summary

Our community is everyone that we interact with as individuals and as a team. We may tweak the messages as we go out but there should not be any major changes when we can avoid it. We need to make sure that our barrier to entry is too high? We need to make sure that we get repeat business and how can we do this. We also discussed how we can maximise test days and get new contributors. How can we sell it to them? How can we get universities involved and showcase/teach what we do? Have current interns as mentors within their university.

Test days need to be seen as something that happens all day long no matter what timezone.

We also need to make sure that when we do any task that we do it in the open so that community members can easily get involved. This can be a little more work for us but shows we are not hiding anything.

Actions

  • We need to get Mozilla Contributor Engagement involved
  • Find out what people what to learn so we can teach them
  • we need to speak to Al about how we give points towards badges
  • Look into involving universities in events that show automation
  • Create a task directory so that contributors can get involved

Responsibilities

The teams has a number of tasks that they are currently doing. We can split the current tasks into 3 different items. The list below is taken from what we are all currently doing.

Summary

We should be doing:

  • APIs
  • Debugging Failing Test
  • Code Reviews
  • Framework extensions
  • Tool Development
  • Consulting and Evangelism
  • Bug Maintenance
  • Test Days
  • Community involvement
  • Infrastructure Requirements
  • Recruitment in QA

We should be engaged in:

  • Triaging tests for automation
  • Framework development
  • QA Team for the A*Team

We should not be engaged in:

  • Result monitoring
  • Test development
  • Automation test execution
  • Manual testing
  • Maintaining infrastructure

Actions

  • We need to prioritise tasks we should be doing
  • What is our minimum for tasks that we should be doing in our responsibilities? What is the things we can do more?
  • Define a clearer responsibilities and not just a couple words.

Code Reviews

Summary

The team wanted to make sure that we can have a process that we make sure that we have a similar level of work coming from WebQA and from the Desktop Automation. The team felt that they are doing a bit too much on the reviews. We want to have a automated process to validate test files against known best practises. Code reviews shouldn't be against past issues or if we decide on new best practises. Should we be using pivotal tracker as a means to note code review tasks and use it to spread the load on reviews.

Actions

  • have a look at the Google JavaScript styleguide
  • How do we spread the load on reviews?
  • Can we have a common process that validates the automated test against litmus and validates the correct usage against frameworks.
  • Have a tool to review files.
  • Speak to WebQA about adding bugzilla reports for pull requests.

Workflow

Summary

The team feels that when doing something we need to make sure that we fit within our responsibilities and when teams want to engage with the team that items get added to the backlog. Priorities can then be assigned to backlog items but prevents answer shopping from external sources.


Actions

  • Pivotal Tracker
    • add pivotal tracker project links to code repository and project wiki so it painfully obvious
    • Speak to pivotal about a better integration story
    • Have a measurement process for estimation of tasks
    • Have a process for assigning priority
  • Bugzilla Actions
    • Have a firefox extension for commonly used whiteboard entries
    • have a list of whiteboard entries that match what we are already working on

Goals

Summary

When doing goals should we do things in parallel or in serial and how can we do this while being as effective as possible. We need to work on team project together so that we are sharing information and skills. This will allow team to complete projects instead of moving from quarter to quarter.

The current approach to goals is negatively affecting personal goals because new items get added before we can complete. Perhaps we should revise how we define goals due to be more agile and give us flexibility to cover new projects if necessary.

Goal dependencies need to be identified sooner and to make sure that items are reciprocated if needed.

Actions

  • Compare Responsibilities vs Current Goals
  • Check point the backlog Priorities in each meeting
  • check with IT/A*team how they define goals


Communications

The team needs a good way to communicate with each other, other teams and with contributors. In the past all communications was done on private mailing list. We need to being doing a lot more. We want to discuss items with everyone but if need be we can escalate and keep liaisons in the loop. IRC can be used as a primary direct communication with users. It allows us to engage users better. The team needs to be made aware as soon as possible/shi about potential projects so we can define technologies and manage the ramp up time of Automation Services team. Product QA Leads need to keep us in the loop about what projects.

The team wants to get a team standup so that we can get better flow of team discussions going and helps team leads to manage work load. Whenever we are in a meeting we need to get a good pulse of QA as well as making sure that we are removing pain points. We need to make sure that we are not alienating teams

We need to publish more so that we can raise the visibility of the team.

Actions

  • speak to AL to see if we can use as everyday too, need to get newsgroups plugin maybe
  • Create a public facing emailing lists
  • Create our own IRC Channel
  • Do we see value in a 1:1. Revisit in a few months
  • Have a look at the IRC Etiquette page and have that linked on our team page so that people can visit it.
  • Google Calendar to Visualize Timezones
  • organise standups
  • discuss with Matt Evans how we define goals. Can we approach this from a more agile development process.
  • Product QA Leads needs to document potential projects that may involve Automation Services.
  • QA Events for meetings
  • Find out if Matt Evans is to prioritize list.


Infrastructure

Summary

We discussed what are the basic need and who can own the VMs. When it comes to who owns the VMs we agreed that QA Infrastructure team would own this.

Actions

  • We need a staging server for Selenium
  • How to set up environments for on-demand testing and implement on-demand testing

Team Dynamics

Summary

The team wants to make sure that they have the skills that can easily transfer. The team dynamics needs to make sure that we are not seen as a selenium/ mozmill shop. We want to show that we have value in learning from each other. Our visibility needs to be seen more as a consultantcy to other teams. We will always make sure that as a team we fail and when discussing things we have a unified front. We need to make sure that we don't promise something we can't deliver so add items to backlog so that they can then be prioritised.

Actions

Team would like a t-shirt for team identity

Group Documenation

Summary

When creating new documentation we discussed where different documents would live. This could be private documentation that is only for Mozilla eyes but we need to make sure that is a last resort. QMO, MDN and wiki should be the public place for us to start storing information.

Action

  • Define structure
  • Complete documentation that is needed

Meetups and Events

Summary

We need to use Meetups and Events should have the following goals:

  • More contributors
  • Increased awareness
  • Skills Growth
  • Team
  • Attendees
  • Personal visibility
  • Networking
  • Innovation

We discussed branding of the person versus company branding. Company branding should always come first. We need to make sure that we never think we are better than people at events.

We discussed the types of events we go to: Types of activities

  • Hosting activities
  • Attending
  • Sponsorship
  • Speaking
  • Coworking

We wanted to know how we can get more contributors especially when people dont get interacted with in the scope of the above actvities. We thought of a few meetups and events that we want to get involved in the next year.


  • GTAC
  • spaces
  • Mozilla Festival and mozilla Berlin
  • Schools
  • Hacker Dojo
  • Brown bags
  • Mozilla Public