From MozillaWiki
Jump to: navigation, search


type-media (miketaylr)

Where are we at, and what should our next steps be? Hide from UI?

  • Adam: Karl has probably some feedback here. I'd think, we should hide it as contributors already jumped on them and wanted to triage them. Would it be easy to hide it?
  • Tom: It should be when we hide them through
  • Adam: Is everyone okay with that?
  • Tom: I think so.
  • Adam: I don't think its the perfect solution, but a step forward.
  • Tom: Probably also a lot of dupes. Shall we close all of them?
  • Adam: The media team will probably want to take a look but yes.
  • Guillaume: Is it possible to hide them from GitHub?
  • Adam:
  • Tom: We just add a minus sign in front of the label and it should be filtered out.
  • Guillaume: I think, its easy to hide that label. --> Adam will file a follow up bug.

# GH Issues (ola)

Needs decision label:

Form refactor

  • Tom: The copy is very important, especially for non-technical people. So we know how we can recreate the issue.
  • Ola: Do you think, having a more "human" copy would be more helpful?
  • Tom: I am not sure. We should do A/B testing.
  • Ola: Guillaume, what do you think?
  • Guillaume: I feel like the design is a good improvement. Not sure about the copy. Maybe it is a good idea to propose this form to non-technical people. For me it is clear and simple. But I don't do triage. So I am not sure about it.
  • Tom: How technical are our user?
  • Ola: I feel like, right now very technical, but this will change as we open up the project.
  • Tom: If we open this up to more non-technical people, we should change more of the writing in the form.
  • Ola: I don't think our audience will ever be that non-technical, but people like to talk to a more human interface than a bot. So they are more likely to leave details.
  • Ola: Try to make the phrasing more human, is everyone OK with that?
  • Group: yep
  • Ola: Add more filler to the list of steps
  • Ola: Sergieu and Oana added some comments as well, which would be best to discuss with them on the call
  • Adam: Maybe we should just go and pick something and change it while we progress. It is just copy, so it is an easy thing to change.

New content

  • Ola: mock-up of the content for the index page, let's talk a bit about the design
  • Ola: intro is a 3 line pitch to explain what the project is doing, in hopes of encouraging others to contribute
  • Ola: more info can be additional resources / news etc. Boxes can be exchanged much more easily over time
  • Ola: tiles with hover or click that have information / additional detail on the back. All are entry points to specific things, as content evolves. A little info about metrics, how much effort is being put in to this project.
  • Guillaume: Good job. My only concern is about "last issues". why did you put the bugs on the bottom? I'd put them on the top. Maybe I'll switch metrics and latest issues. To a new contributor they might be more important. "How we can help?".
  • Ola: The main purpose of the site is to work on bugs, the new (second) purpose is to encourage others to get involved in the project. Giving more context, feeling like it's active and welcoming. Old contributors will go where they need to, to do work. Want to create a more trusting environment that others want to report bugs or other roles.
  • Tom: Is the all issues still at the top?
  • Ola: yep
  • Tom: Are we keeping the above the fold the same, or do we need to add more links to the top? I do like the new design proposal though, looks fantastic
  • Ola: We likely won't add much more to the top
  • Tom: just hinting that there is more to this page.
  • Adam: Its hard to tell through the different devices if we provide the right content. We need to think about the case "old contributors working on bugs" vs "new contributors" and how to serve both. As long as people will get to the point to where they want to go to, it should be okay to have more content for new users.
  • Ola: straighten up the entire design repository, how each section looks on desktop, mobile etc. then start working on CSS. Keep up a living style guide, to document the modules/colours etc. for others to reference. Carol would also love to work on visual regression testing for the living style guide. Automatic testing for the browser, take screenshots for different OS/browser combos and highlights any diff's.
  • Tom: I'm working on a different regression testing tool if you need any help/insight.

Broken Voices of the Web

Web Compatibility Progress