Compatibility/Meetings/2016-06-work-week: Difference between revisions

(reorg hallvors section)
 
(22 intermediate revisions by 5 users not shown)
Line 12: Line 12:
   Departure: Saturday, June 18 (Train + Boat)
   Departure: Saturday, June 18 (Train + Boat)
* Mike Taylor
* Mike Taylor
   Arrival:  
   Arrival: Monday morning, June 13
   Departure:  
   Departure: (Will be taking PTO from Saturday June 18 -> Thursday)
* Hallvord Steen
* Hallvord Steen
   Arrival: Monday, June 13, 10:20 (LHR)
   Arrival: Monday, June 13, 10:20 (LHR)
   Departure: Thursday, June 16th, 11:20 (LHR)
   Departure: Thursday, June 16th, 11:20 (LHR)
* Adam Stevenson
* Adam Stevenson
   Arrival:  
   Arrival: Monday, June 13 (probably flight from France)
   Departure:  
   Departure: (Will be taking PTO from Saturday June 18 -> Saturday June 25)
* First_Name Last_Name
* Guillaume Demesy
   Arrival:  
   Arrival: 13 june: 13h30 London St-Pancras (Londres)
   Departure:  
   Departure: 18 june: 07h52 London St-Pancras (Londres)


=== Regrets ===
=== Regrets ===
Line 30: Line 30:
Welcome everyone.
Welcome everyone.
=== Tue, June 14, 2016 ===
=== Tue, June 14, 2016 ===
14:00 - 15:00 Web Compat Team Working Hours<br />
16:30 - 18:00 Web Compat Team Working Hours
=== Wed, June 15, 2016 ===
=== Wed, June 15, 2016 ===
13:00 - 18:00 Web Compat Team Working Hours
=== Thu, June 16, 2016 ===
=== Thu, June 16, 2016 ===
14:00 - 16:30 Web Compat Team Working Hours
=== Fri, June 17, 2016 ===
=== Fri, June 17, 2016 ===
14:00 - 18:00 Web Compat Team Working Hours
=== Sat, June 18, 2016 ===
=== Sat, June 18, 2016 ===


Line 44: Line 49:
</pre>
</pre>


=== 💡 WebCompat.com Development ===
=== LONDON PRE-SELECTION===


==== Usability testing for webcompat.com ====
==== Usability testing for webcompat.com ====
Line 54: Line 59:
Better filtering UI on webcompat.com is very important. I'll keep nagging about https://github.com/webcompat/webcompat.com/issues/795 until we get it right.  
Better filtering UI on webcompat.com is very important. I'll keep nagging about https://github.com/webcompat/webcompat.com/issues/795 until we get it right.  


==== Deployment scripts for webcompat.com ====
==== [DONE] webcompat.com development conventions -- what works and what can be improved ====
(when miketaylr is on holidays or sick) [https://github.com/webcompat/webcompat.com/issues/965#issuecomment-202558159 See Also]
 
'''Pull Requests Format'''
 
I would like to write a script which generates changelog.
 
* pull request number URI
* issue number being fixed
* short description of the change
 
When miketaylr creates a pull request. The title is "Fix #issue_number. Short description".
Bad example.
* https://github.com/webcompat/webcompat.com/issues/1084
* https://github.com/webcompat/webcompat.com/pull/1073
 
Agreed Format. "Fixes #issue_number Short description"
 
'''Pull Requests Merging'''
 
If you are merging a pull request.
 
* add the addtochangelog label
 
'''Pull Requests Labels'''
 
Guillaume will propose a taxonomy of labels.
 
'''Commit messages'''


==== Merging PR for webcompat.com ====
"#issue_number short description"
(when miketaylr is on holidays or sick) How do we manage the PR merging and its conflicts for deploying.


==== webcompat.com development conventions -- what works and what can be improved ====
Prefer atomic commits to large commits, there are easier to review and manage.
@@mike@@ to explain.


==== 🛠 Moving bug stage labels to milestones for webcompat.com  ====
'''Tests and Pull Requests'''
[https://github.com/webcompat/webcompat.com/issues/886 Issue 886] on moving the status of issues from label to Milestones in Github.


==== Review the backlog of issues ====
When submitting a Pull request for python or JavaScript code, run the test before.
(by karl)
Using this [https://github.com/webcompat/webcompat.com/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc issues list], what do we keep, reorganize, erase?


=== 💡 WebCompat.com Community ===
==== [DONE] 🛠 Moving bug stage labels to milestones for webcompat.com ====
[https://github.com/webcompat/webcompat.com/issues/886 Issue 886] on moving the status of issues from label to Milestones in Github.


Mike explains how labels and [https://developer.github.com/v3/issues/milestones/ milestones] are working on Github. Milestones prevent to be in two states. So we are thinking of getting rid of status-* to move milestones. To change a milestone, the [https://developer.github.com/v3/issues/#edit-an-issue issue API has a PATCH method].


==== -webkit- prefixes impact and practical Web Authoring ====
We moved issues 886 to London Milestones.
(by Jet Villegas). Probably needs MDN and DevRel


* Are Web Designers already authoring *only* for Webkit/Blink today?
* '''RESOLUTION''': We ditch the label status-* in favor of milestones.
* How should this affect our choices re: Web standards to adopt/reject?
* '''ACTION''': deepthi to fix 975, before moving to milestones.
* How can we help authors "do the right thing?"
* '''ACTION''': miketaylr to erase the status-* labels on the repo.
* '''ACTION''': miketaylr to fix functional tests for labels->milestones.


==== MDN Doc Prioritization ====
==== How might we collect mail addresses associated with anon webcompat.com reports? ====
(by Jeremy Patonnier) See [https://groups.google.com/d/msg/mozilla.compatibility/VK80qZkM2do/O1EUgJ6OJAAJ his email]
[https://github.com/webcompat/webcompat.com/issues/457 Issue 457] discusses whether and how we should do this. A face-to-face discussion would be good.


* What are the most common web compat issues ?
==== Review the backlog of issues ====
* What information is missing to web dev to solve such issues ?
(by karl)
* What kind of arguments is provided to NOT fix a compatibility issue ?
Using this [https://github.com/webcompat/webcompat.com/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc issues list], what do we keep, reorganize, erase?
* (And do you already have answers to those arguments?)




==== Expectations for NeedsDiagnosis ====
==== Expectations for NeedsDiagnosis ====
As a group we do not share the same expectations for what should be in needsdiagnosis state, and what it should not. It would be good to discuss it so we have a kind of agreememnt about it. For example, this was switched to [https://webcompat.com/issues/1851#issuecomment-154194323 needscontact] without where in the scripts it is bogus. It's just a general description of the issue.
As a group we do not share the same expectations for what should be in needsdiagnosis state, and what it should not. It would be good to discuss it so we have a kind of agreement about it. For example, this was switched to [https://webcompat.com/issues/1851#issuecomment-154194323 needscontact] without where in the scripts it is bogus. It's just a general description of the issue.


* What are the entrance criteria for needsdiagnosis flag?
* What are the entrance criteria for needsdiagnosis flag?
Line 100: Line 127:
* We should also probably survey people at Mozilla.  
* We should also probably survey people at Mozilla.  
* Also wondering if a usability study could be done in cooperation with Mozilla UX team
* Also wondering if a usability study could be done in cooperation with Mozilla UX team
==== Measuring compatibility (and progress) ====
==== Measuring compatibility (and progress) ====
@@mike@@ to explain
How can we programmatically determined if Firefox is compatible with some content. How a specific version would break or not on sites? Mike prototyped something.
==== Structured Triage (bugzilla and webcompat.com) ====
* Automation Looking at the DOM, HTTP, CSS and JS: what are interesting data points to record for comparison and tracking over time?
@@mike@@ to explain
* Matching/diffing error messages from Gecko and WebKit: can we write some code that can give us a meaningful diff and tell us what errors happened in engine A but not in B? (new Compatipede analysis module?)
==== Training contributors to triage and do outreach ====
* What should our approach be to automating *interactivity*: for automated tests, such as automated log-in? (discussion, hack session)
@@mike@@ to explain
* Detect Web regressions (by lmandel): talked on and off about getting better web compat data to use for
release criteria. How can we detect web regressions due to changes in Gecko? How can we detect new Gecko specific issues due to site changes? How do we quantify this in a way that helps us focus on fixing these problems
before we release?
 
 


=== 💡 Automation ===
(by hallvord)
==== Compatipede-2 plug-ins ====
the ones we have (demo), how to write them (workshop)


==== Looking at the DOM, HTTP, CSS and JS ====
==== Structured Triage (bugzilla and webcompat.com) ====
what are interesting data points to record for comparison and tracking over time? (Discussion - good to do before that workshop - we'd write plug-ins to track new data points).
Expectations in the Team how the triage should happen. Adam highlighted how we can be slow.
If we are able to respond quickly, we have a good contacts with people.


==== Matching/diffing error messages from Gecko and WebKit ====
==== Tracking Protection Bugs ====
can we write some code that can give us a meaningful diff and tell us what errors happened in engine A but not in B? (new Compatipede analysis module?)
(by Adam) Determine if we should be focusing on this. There are more users enabling this function now and many things are broken. Also if we do decide to try, what is the message for outreach? Ask Brad who would be relevant in the discussions
==== What should our approach be to automating *interactivity* ====
for automated tests, such as automated log-in? (discussion, hack session)


==== Other stats ====
==== Other stats ====
We can create some spin-off statistics for purposes that are not strictly compat but "nearby" like memory usage. How, and what's important? Memory usage? Can we measure jank? Scroll performance?
We can create some spin-off statistics for purposes that are not strictly compat but "nearby" like memory usage. How, and what's important? Memory usage? Can we measure jank? Scroll performance?
 
==== Trending Content ====
==== WebExtensions-based Firefox/Chrome add-on to control the browser on behalf of Compatipede ====
(by Adam) We have focused on top sites but a lot of trending or temporary content could be breaking without knowledge. Recently there was a Buzzfeed issue. Promotional landing pages fall off the radar as well.
Explore working on the proposed WebExtensions-based Firefox/Chrome add-on to control the browser on behalf of Compatipede, to move off SlimerJS and Phantom (there's some initial code somewhere on GitHub - a Boar branch I think)
 
==== Should we aim for testing on real devices? ====
If yes, how do we bridge the gap between Compatipede and the Firefox instance on the device? Marionette (whenever it comes to Fennec..)? WebExtensions (whenever it comes to Fennec..)? Nodejs-Marionette (testing on FxOS devices)? A custom-written devtools protocol client? Something else?
 
=== 💡 Tech Evangelism Bugzilla ===
=== 💡 Platform ===


==== Removing -webkit- support ====
==== Removing -webkit- support ====
Is there such a thing as removing support for -webkit-blah in Gecko when we notice that it's not necessary anymore? When do we think/how do we find out it will not be necessary anymore.  
Is there such a thing as removing support for -webkit-blah in Gecko when we notice that it's not necessary anymore? When do we think/how do we find out it will not be necessary anymore.  
Related to telemetry CSS.


==== Firefox for Android UA override ====
==== Firefox for Android UA override ====
Firefox Android UA override infrastructure, policy. aka `-webkit-` will sometimes only work in combination with UA override. Fix first then contact, Fix and not contact, etc?
Firefox Android UA override infrastructure, policy. aka `-webkit-` will sometimes only work in combination with UA override. Fix first then contact, Fix and not contact, etc?
=== 💡 DevTools ===


==== Can we contribute more to DevTools QA? ====
==== Can we contribute more to DevTools QA? ====
(by hallvord)
(by hallvord) It would be good as a Team to understand how we are using the devtools.


==== Useful warning/error messages in the console. ====
==== Useful warning/error messages in the console. ====
Line 152: Line 171:
* Something more like a lint flag with URIs to how to fix the mistakes.
* Something more like a lint flag with URIs to how to fix the mistakes.


=== 💡 MDN ===
=== 💡 Misc ===


==== WebCompat work sharing what we do ====
==== WebCompat work sharing what we do ====
A distributed team is working well when we are all sharing what we learn about the project and our actions. Hallvord and Karl are sharing through [http://statusupdates.dev.mozaws.net/project/webcompat minutes] and blogs [http://www.otsukare.info/pages/mozilla-worklog.html otsukare] [http://www.whatcouldbewrong.com/ whatcouldbewrong]. How do we discover about the work of Adam (meetings with desktop, access to physicial meeting in Toronto) and Mike (commits on Gecko/Platform). Some of these are sometimes popping up through discussions but were not necessary shared in advance. So basically how do we better work together?
A distributed team is working well when we are all sharing what we learn about the project and our actions. Hallvord and Karl are sharing through [http://statusupdates.dev.mozaws.net/project/webcompat minutes] and blogs [http://www.otsukare.info/pages/mozilla-worklog.html otsukare] [http://www.whatcouldbewrong.com/ whatcouldbewrong]. How do we discover about the work of Adam (meetings with desktop, access to physicial meeting in Toronto) and Mike (commits on Gecko/Platform). Some of these are sometimes popping up through discussions but were not necessary shared in advance. So basically how do we better work together?
=== 💡 WebCompat.com Development ===
==== Deployment scripts for webcompat.com ====
(when miketaylr is on holidays or sick) [https://github.com/webcompat/webcompat.com/issues/965#issuecomment-202558159 See Also]
==== Merging PR for webcompat.com ====
(when miketaylr is on holidays or sick) How do we manage the PR merging and its conflicts for deploying.
=== 💡 WebCompat.com Community ===
==== -webkit- prefixes impact and practical Web Authoring ====
(by Jet Villegas). Probably needs MDN and DevRel
* Are Web Designers already authoring *only* for Webkit/Blink today?
* How should this affect our choices re: Web standards to adopt/reject?
* How can we help authors "do the right thing?"
==== MDN Doc Prioritization ====
(by Jeremie Patonnier) See [https://groups.google.com/d/msg/mozilla.compatibility/VK80qZkM2do/O1EUgJ6OJAAJ his email]
* What are the most common web compat issues ?
* What information is missing to web dev to solve such issues ?
* What kind of arguments is provided to NOT fix a compatibility issue ?
* (And do you already have answers to those arguments?)
==== Training contributors to triage and do outreach ====
Probably better documentation on how to better train people.
==== New hire(s). ====
* Meeting time for webcompat.


==== IRC bot and IRC Web Archive ====
==== IRC bot and IRC Web Archive ====
Line 164: Line 214:
* Archives of logs == '''Good''' 1. history of our discussions we can point to with proper URI. 2. Could minute the webcompat meeting directly on IRC (W3C style). '''Bad''' 1. soft opacity has a benefit for certain jokes and discussions to not be broadcast and shared with only the people in the room. 2. Might create expectations of work stable information on the channel instead of bug trackers, mails, etc. so create another source where to look for information.
* Archives of logs == '''Good''' 1. history of our discussions we can point to with proper URI. 2. Could minute the webcompat meeting directly on IRC (W3C style). '''Bad''' 1. soft opacity has a benefit for certain jokes and discussions to not be broadcast and shared with only the people in the room. 2. Might create expectations of work stable information on the channel instead of bug trackers, mails, etc. so create another source where to look for information.
* Bot == 1. tools giving information for leaving messages to people in the future (answering machine). 2. Giving information about bugs when typing number (Github and Bugzilla) 3. Meeting logs for minutes.
* Bot == 1. tools giving information for leaving messages to people in the future (answering machine). 2. Giving information about bugs when typing number (Github and Bugzilla) 3. Meeting logs for minutes.
==== Issues best tested while in the UK :) ====
* https://webcompat.com/issues/2436
* https://bugzilla.mozilla.org/show_bug.cgi?id=910573
* https://bugzilla.mozilla.org/show_bug.cgi?id=961460
We could look together at this:
* https://github.com/webcompat/css-fixme/issues/18
to ensure others are somewhat familiar with css-fixme for future maintenance




[[Category:Web Compatibility]]
[[Category:Web Compatibility]]
Confirmed users
1,567

edits