Creating A Welcoming Community

We want to make the AMP open source community as welcoming as possible, both because we :sparkling_heart: new contributors (and want more of them) and because most people prefer to work on a project with a friendly community.

Here are some ways you can help make AMP's open source community even more welcoming. The TL;DR is "be friendly and helpful." :)

• Be welcoming in everything you do.
  • Think about how intimidating it can be to join a new community (will this new group ignore me? will they treat me like I'm not smart?) and then work to make our community less intimidating. People that see that the current environment is friendly and helpful will be more willing to take the plunge to help out.
  • Familiarize yourself with our Code of Conduct. In addition to a list of "don't's" the Code of Conduct includes some of our ideals like "we are committed to providing a friendly, safe and welcoming environment for everyone."
  • Think about how the words you use can affect how people perceive the community. A jsconf talk from Harriet Lawrence makes some good points, including:
    • Things that may sound innocuous can actually be stumbling blocks for people thinking about joining a community. For example docs that say "these short and easy instructions" can turn away contributors who don't actually find the instructions easy and then feel like they aren't qualified to participate in the community.
    • The communication between people already in the community is one way people judge whether to join in. Be conscious of this when you talk to others (on issues, code reviews, etc.). Your joking insult on a PR with someone you know well may look like hostility to someone who doesn't know you.
• Don't let people feel ignored.
  • Keep an eye out for issues/comments/PRs on GitHub or comments on Slack that aren't being responded to and either respond yourself or find an appropriate person to do so. If you aren't sure who can help, ping mrjoro on Slack.
  • If you can't immediately respond in detail to something in a PR/issue let the contributor know that and provide an estimate of when you'll be able to get to it (e.g. "I won't have time to get to this today, but plan on reviewing it on Friday").
  • Pay particular attention to Good First Issues since the people working on them are generally brand new to the community.
• Understand the motivations of contributors to AMP.
  • There are a lot of different reasons someone may be contributing to AMP. Understanding the motivations of contributors you're working with can help you point them in the right direction.
  • Some of the many reasons people contribute to AMP:
    • A developer using AMP that wants to fix something that isn't working for them (bug or new feature).
    • Someone from an ad network/analytics provider/video player/etc. that wants to add support for their service.
    • People that want to get involved in open source and found AMP (through news, tweets, open source new contributor events, etc.).
• Get an understanding of what new contributors are interested in helping out with (a new feature? just finding some way to help?) and point them to the relevant section of bit.ly/helpamp.
  • If you are working with a new contributor and they are not familiar with Git/GitHub or contributing to open source projects, point them to the Getting Started End-to-end guide at bit.ly/helpamp-e2e.
  • More experienced contributors may prefer the "quick start" version of the getting started guide.
• Help people find a project.
  • AMP relies on the community for many different types of contributions--code, documentation, AMP Start templates, translations, etc. Try to get a sense of what someone who doesn't have a specific project in mind would be interested in helping with and point them in the right direction.
  • Good First Issues are good starter projects.
    • When someone starts working on a GFI we add the "GFI Claimed!" label to it, so the GFIs not marked as "GFI Claimed! are the open ones.
    • Keep an eye out for small issues that would make good Good First Issues and create Good First Issues for them. Having a variety of GFIs always available for new contributors helps ensure new people will have a way to get started contributing.
    • There may not yet be a Good First Issue that matches a new contributor's interests/expertise. If that's the case reach out to the community (e.g. on Slack) to see if anyone has an idea of a project for them to work on.
  • If you aren't sure where to send somebody for a starter project let mrjoro know.
• Encourage contributors to sign up for Slack.
  • Slack provides the best forum for interacting with the community outside of individual GitHub issues/PRs.
  • Contributors will need to fill out a single-question form to get an invite.
  • Point contributors to the Slack channel(s) that they'll likely get the most value out of, e.g. #welcome-contributors if they're brand new to the project, #docs if they're planning on making documentation contributions and one of the Working Group channels if they're interested in the area a particular Working Group tackles.
  • Let contributors know they can Direct Message you with questions on Slack (if you're comfortable doing so).
  • Having conversations about issues/PRs on the issue/PRs themselves is ideal since this provides a more permanent record that may help other contributors. Many contributors are more comfortable asking questions on a less public platform, though, so having these conversations on Slack is fine. (In these cases summarize any clarifications/designs/etc. in the issue/PR after the discussion if it makes sense.)
• Encourage ongoing participation.
  • Make sure people who introduce a new component are added to the relevant OWNERS file(s) and let them know about our OWNERS process. We want contributors to have a sense of ownership over the things they contribute.
  • Help people who finish a Good First Issue find a new project to tackle and encourage them to take it on. If you don't already have a project in mind, gauge their interests and skill level and work with the rest of the community (or mrjoro) to find a project suitable for them.
  • Some people may only be interested in making one-off fixes (e.g. adding support for their ad network) and that's fine. Even in these cases it doesn't hurt to mention some other ideas for ways to help (e.g. maybe someone adding their ad network wants to make some other more general ads fixes) and let them know we'd love their help.
• Let people know about design reviews.
  • Design reviews provide an opportunity for the community to meet "face to face" (over video conference) and learn from each other.
  • Everyone is welcome to attend any design review (even if they aren't presenting a design).
  • If it makes sense, encourage contributors you are working with to bring their projects to a design review. (This is optional and shouldn't stand in the way of a new contributor making fast progress.)
  • Design docs are great, but we've also had successful design reviews with detailed GitHub issues for smaller design questions.
  • If the contributor is in a time zone that makes it hard for them to attend the design reviews let mrjoro know and we can move the time around.
• Follow up when you don't hear from a contributor in a while.
  • Sometimes new contributors express interest, propose a new feature, or maybe even starts on a PR but then we stop hearing from them. Make an effort to follow up with the contributor (in the issue/PR, over Slack DM, etc.) to see if there's anything we can do to help them make progress.