-
Notifications
You must be signed in to change notification settings - Fork 187
Z Intern Questions (Sum 2017)
placeholder: for questions during outreachy internship
- For the typical types of issues reported, what are the breakdowns (like rough percentages)?
- What is the typical breakdown of issues which are user error (or fixed by user education) vs requiring changes to the browser?
- Do the people who work on public webcompat also work for other browsers? (or how do people who work on webcompat communicate with people who work for other browsers?)
- Do webcompat engineers also work on the browser code?
- What are some typical challenges of troubleshooting webcompat issues (from a webcompat engineer perspective)?
- Is one of the goals of this site to attract contributors who are interested in becoming webcompat engineers?
- Work week discussion topic: field validation (request by Ola)
- Ex Why does the app currently expect that when a user selects the #description text area, required field validation should occur for the Problem Type (radio buttons) field?
https://github.com/webcompat/webcompat.com/blob/master/tests/functional/reporting-non-auth.js#L169
Not sure where to document but there is a branch: css_custom
Its purpose is as a prototype (design concept demo) for some next gen custom form css. On the bug report form, the radio buttons and text input fields have been restyled.
About 98% of the radio button css animation was taken from a very nice codepen (Angela V): https://codepen.io/AngelaVelasquez/pen/Eypnq
The radio button css had to be hacked as a workaround to make the interaction demo-able. In real life, the button label should not cover the input control. The original radio input should be hidden. The next choice JS framework should be organized to track the custom control's state.
If any tests were modified in this branch, they should not be reused.