Compatibility/Meetings/2017-06-work-week: Difference between revisions
Lizardwalk5 (talk | contribs) (→Attendees: update arrival/departure) |
(moving lightning talks) |
||
Line 73: | Line 73: | ||
----- | ----- | ||
=== Fri, Jun 30, 2017 === | === Fri, Jun 30, 2017 === | ||
==== webcompat - lightning talks ==== | |||
We introduce a topic to the rest of the team in 5 minutes. A technique we used for coding. A way of working on something. A python dev issue. A devtools hack. An organization/management suggestion. Or maybe something completely different from your life. Your garden. Your cooking skills. Your reading. | |||
==== Evening ==== | ==== Evening ==== | ||
Bye Event. | Bye Event. | ||
Line 157: | Line 160: | ||
==== webcompat.com - type-media ==== | ==== webcompat.com - type-media ==== |
Revision as of 10:17, 29 June 2017
This is the agenda and logistics page for Web Compatibility Team Work Week meeting in San Francisco (USA) from June 26 - June 30, 2017.
- Previous Work Week: Berlin, Germany - April 2017.
- Next Work Week: (not known yet)
Logistics
- Location: San Francisco, USA
- Hotel: Hilton Hotel
Attendees
Hotel | Attendee | Arrival | Departure |
---|---|---|---|
Parc55 | Adam Stevenson | Monday 3:38pm | Saturday, 11:55am |
Union | Dennis Schubert | Monday 4:15pm | Sunday, 2:05pm |
Union | Eric Tsai | Monday 2:25pm | Sunday 1:40am |
Union | Guillaume Demesy | Monday 12:30pm | Saturday 03:10pm |
Parc55 | Karl Dubost | Monday 10:30am | Saturday 11:25am |
Parc55 | Mike Taylor | Monday 3:44pm | Friday, 11:59pm |
Union | Ola Gasildo | Monday 7:05pm | Saturday 3:05pm |
Parc55 | Tom Wisniewski | Monday 7:03pm | Saturday 7:55pm |
Union | Carol Chung | Monday 9am | Saturday 3pm |
Union | Beatriz Machado | Monday 11:03am | Saturday 12:55pm |
Regrets
Agenda
Let's make sure that we minute everything or have summaries for everything we discussed. Hawaii was a good work week but poorly minuted. We are usually good on the first day and then slowly with fatigue let things slip.
- Use the etherpad for minutes taking with the usual format.
- Minutes on the wiki by the end of each day. Karl will generate them.
- If working in smaller groups, write the minutes for your group on the etherpad at the usual place.
- Record clear Action items which can be understood out of context.
- WHO to do WHAT in WHICH CONTEXT by THIS DATE
- Example: Karl to do review peace in the world policy framework in webcompat-dev issue 6969 by 2020-03-16
- Send the minutes to the mailing-list. (Karl will do it.)
Mon, Jun 26, 2017
See the Attendees table in this page. Most of the people will arrive during the day. No work is planned, but you are welcome to start discussions or really anything.
Evening
Let's try to welcome Beatriz and Carol properly if they are already there. Reception event
Tue, Jun 27, 2017
Evening
- Karl: already booked.
Wed, Jun 28, 2017
Evening
Team Dinner, somewhere, somehow Let's eat together as a team, for one evening. The rest are up to you.
Thu, Jun 29, 2017
Evening
Fri, Jun 30, 2017
webcompat - lightning talks
We introduce a topic to the rest of the team in 5 minutes. A technique we used for coding. A way of working on something. A python dev issue. A devtools hack. An organization/management suggestion. Or maybe something completely different from your life. Your garden. Your cooking skills. Your reading.
Evening
Bye Event.
Topics Bank
Use the following template in one of the section below:
==== Topic ==== Description with [http://example.com links] when necessary
webcompat.com bug form required fields validation
Get info about why selecting the Description triggers validation for Problem type/category field.
webcompat.com - architecture overview
Info session to learn about how data flows through the system (end to end). Other questions?
webcompat.com - deploys
Hack session to work on the work left to get someone else to deploy the site (other than Mike).
webcompat - VPNs
How useful? Should we consider getting a team plan, or something? Or just a few designated peeps?
webcompat - H2 planning
What are the projects we will continue to work on for the rest of 2017? What should we kill? What new projects?
webcompat - team meetings
A quick discussion on all our current meetings to decide if what we do works for us.
go faster - H2 planning
What's the current status for webcompat gofaster and what comes next?
Google Tier 1 planning
Review bugs filed by SoftVision and plan how we can move forward.
webcompat newsletters
More projects at Mozilla are making a nice review of what happened recently under the form of a newsletter/blog post. Examples: Photon Engineering Newsletter #6, This week in Rust, Quantum Flow Engineering Newsletter. Been there, done that at W3C open web platform weekly summary. It takes time, but it's valuable. It sometimes require a bit the participation of everyone. It also ties into the topic of transparency that Dennis mentioned a couple of times.
Thomas on IRC on June 22, suggested we use etherpad to collect things. So we started as an experiment webcompat-news. Feel free to add stuff there and we will see where it goes.
webcompat - transparency on what the team is working on
As Dennis mentioned a few weeks back, it's hard to keep track on who is working on what right now. Maybe we can find a good way to make things more transparent as a short brief in our meetings on everyone's status or making everyone's quarterly goals transparent (if possible).
webcompat.com - Living Style Guide (LSG)
With the refactor, we'd like to work on a Living Style Guide to build a base for the upcoming refactor of the page. This will include - a "grid system", - website modules that will be build upon the grid system including defined HTML semantics, - the structure for the LSG (usage of modules, documentation of colors, fonts etc), - Tests (How much do we need to change due to CSS / semantics refactor) - Visual Regression Testing for LSG (http://webdriver.io/guide/services/visual-regression.html) - Ownership of LSG
With the LSG we will be on the same page to proceed with the refactor remotely as well as be able to manage small releases plus have a clearer entry point for new contributors.
A few questions need to be discussed before we start working on the LSG: - How do we want to handle SVG's? - How do we want to handle font loading as we will probably switch to Open Sans (Example: http://webcompat.github.io/design/)? - How should the naming conventions for CSS look like? - We would need to decide on the audience of contributors for the LSG, so we know how the documentation should look like. - How do we want to handle the CSS development (e.g. pull from webcompat.com in LSG for testing purpose) as the same CSS should serve both (webcompat.com & LSG), so we can run manual / automated visual testing for it.
webcompat.com - Discuss roadmap for refactor in Q3 / 4
With everyone working remotely, it would be great to discuss a rough roadmap for the refactor of webcompat.com. A few questions that fall under that topic would be: - What needs to be done? - Who would like to help and take over which tasks? - What needs to go in which milestone? - When do we tackle the JS refactor?
webcompat.com - Discuss roadmap for refactor in Q3 / 4 (low prio)
Following questions can be interesting to discuss, but are not high priority as they can be discussed in a remote meeting at some later point: - Webpack rebuild - Tooling for JS refactor (Mostly framework discussion + tools for handling npm dependencies, test coverage...)
webcompat.com - testing
As we will change semantics and naming conventions for webcompat.com and the LSG, we will need to put some work in the tests. How much do we want to change? Just fixing the tests? Or do we want to make more improvements as we are on it already? How would those improvements look like? What is out of scope?
webcompat.com - type-media
We receive a lot of type-media issues. We need to clarify a couple of things. - Do we push them in needs-diagnosis once identified? - Who is handling them in needs-diagnosis? alfredoyang? - We have the webhook being developed by karl. - Do we kill the handling of those?
webcompat.com - Atom feed for issues
Part of the SF Milestones on Github. I will work on this during San Francisco Work Week. https://github.com/webcompat/webcompat.com/milestone/35
webcompat.com - alexa top and priority
Handling alexa through webhooks by Eric
webcompat.com dev - committing on your repo
It seems there are two styles of coding for branches. Some people will commit on webcompat.com repo a branch, and some will do it on their personal fork. We pushed people to do it on their own repo in the past to avoid any kerfuffles on webcompat.com.
Communications channels and openess
There is a trend that we need to stop and fix. We have a tendency to use non-open communication channels for things which are not Mozilla-secret sensitive. Each time we share something on a private channel, each time we lower the sense of the community. Mundane stuff, simple links to geeky stuff, etc. All of that is useful for the community even if there are just peeping.
Triage Consistency
(Adam, Eric, Karl) When doing triage we need to define some consistent strategy. Examples: when do we close as incomplete? When do we move to non-compat and with which status? When it's a bug report for another browser, do we automatically move it to needsdiagnosis? Etc.
Webcompat.com Responsibilities Overview
How the responsibilities worked out since Berlin Meeting? Do we need to readjust the path? tweak? Do we sail as-is?
Webcompat.com San Francisco Milestone
We have a San Francisco Milestone for Webcompat.com. Let's try to tackle it before the work week.
GoFaster hacking time
(Dennis, Eric, Mike, (Tom)) Dennis is running into some difficulties while adopting the GoFaster addon to newer standards (especially bug 1371442) and would love an hour or two of concentrated Gecko-knowledge to discuss these in a group.
Half-day or evening team building
Let's do something not work related together. The bigger the team the harder it becomes but we will probably find out something. If you have ideas, propose them here.
Webcompat.com Localization
(Adam) In the past we have generally pushed back on this idea, due to the possibility of increased bug reports in languages we don't understand. We currently get bugs from many different countries, with no description of the problem. Can we somehow encourage users to leave descriptions in their native language without doing full localization? It's easy to Google translate and currently these reports are being closed anyway.