From MozillaWiki
Jump to: navigation, search


Onboarding for new contributors (ogasidlo)

On boarding for new contributors (social side of it, on boarding call, todos / responsibilities, maybe one pairing session?) More information on following topics:

  • ola: We need to have a way to onboard on the project for new people. My idea would be to onboard people who are doing triage, bugs analysis.
  • mike: This seems to be mentoring one person.
  • ola: yes a new contributor on (issue side)
  • karlcow: So when you're saying new contributor, you're talking about the issue side? or the site development side? these are two different things
  • ola: I'd like for both, the sessions would be different, but I think it would be good
  • karlcow: Onboarding for development exists somehow already, or at least we've done similar things in the process. What doesn't exist is for site triage.
  • mike: There are two separate worlds, two separate types of work. My opinion is for the site development is a lot easier. We have done this in the past. People self identify easily. The triage and diagnosis are undefined. I really like the idea of mentoring. Some projects at Mozilla are doing that.
  • adam_s: Triage is documented, probably wrong place:
  • karl: main contributors are those who go through workshops, which is very successful. We had a lot of issues with quality of reported bugs. We discussed on the mailing list how to do reporting, diagnosis, outreach
  • mike: What are the things you would need to teach for during workshops.
  • ola: Screencast on bugs diagnosis would help for transparency.
  • mike: I have done 1-1 call in the past when participants asked can we chat? It helps.
  • ola: there would be a label for the bug.
  • mike: It could be a label or a comment.
  • ola: I was taking about webcompat issues, not the site dev.
  • mike: this is trickier. For triage and diagnosis, it is a bit harder, but for outreach that could work.
  • karlcow: You need to think about the incoming bugs as fire. We are firemen on the line of fire. It's not exactly like the development of a project, it's a lot more like security bugs (without the same impact). If there's really compat issues, we need to understand ASAP, and we are already not fast enough. Triage and diagnosis needs to be processed quickly. Outreach is easier, because it's already a long-term project. Sometimes it can take a very long time (> 1 month). This seems like a good project for mentoring.
  • mike: Maybe we can have public meetings or we record them. It might help people like the video screencast of Mike Conley. We do a lot of learning on the fly.
  • mike: As for labeling mentored outreach bugs, how would we approach that? Adam? Karl?
  • karlcow: For me I've been thinking of how to do this to be beneficial to both sides. For example, other languages. This week there were some bugs in Russian and Portuguese. This would be an example where someone is bringing a skill, in this case their language, and we teach them how to use that help us.
  • adam: There's an awkward state about sitewait, where we might know it's effective or not.
  • mike: we had this idea of highlighting bugs which are too old. We probably need to open a bug on the webcompatDEV project to define how this would work.
  • ACTION: ola to open a bug on webcompatDEV project for having mentor label and how to remove them.
  • ACTION: mike to identify some good first bugs to stick mentors for webcompatDEV issues.

Onboarding: Public Meetings (ogasidlo)

Should we have monthly public meetings (starting in feb?)

  • ola: We need to create transparency for users. 1-1 call for guiding people on how to start. Or "pair programming" on how to deal with the issue. Opening new communications channels such as slack (IRC is hard for new contributors).
  • adam_s:
  • karl: clarifying his understanding of trasnparency
  • ola: more about making things more visible
  • mike: it's about discoverability of what exists
  • ola: structure of the website could improve and we're starting that

Channels (ola)

About opening new channels for discussions.

  • mike: ola spoke about Slack. Adam brought gitter to the table. It means we need to be there. On IRC, we do social and it's cool. And if there is another channel and there is on
  • karl: there was a benefit to being on Moz IRC in the past as we were more engaged with Mozilla engineers. It grew over time. Would being active on freenode bring more diverse contributors to our project.
  • mike: we could move the party, but Moz IRC is still valuable for us and we should monitor it

Onboarding: Wiki (ogasidlo)

What is the purpose of wiki ("just" documentation for project / process or open documentation of site for contributors). Does that need gardening (aka re-structuring)?

(no discussions. Reported to next week.)

Improve User Experience for Potential Contributors (adam)

Mesha has been doing some great work, if you would like to review

Broken Voices of the Web

Web Compatibility Progress