Successfully reported this slideshow.
Your SlideShare is downloading. ×

Maintaining quality in open source

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 39 Ad

Maintaining quality in open source

Download to read offline

Open source software is unique in the fact that the community can help build and maintain the software project. Because of this, processes must exist to ensure that quality is held to a high standard no matter who contributes. This presentation outlines strategies to effectively engage with the community while ensuring product quality. Some strategies include collaboration guidelines, build scripts, and pull request review processes.

Open source software is unique in the fact that the community can help build and maintain the software project. Because of this, processes must exist to ensure that quality is held to a high standard no matter who contributes. This presentation outlines strategies to effectively engage with the community while ensuring product quality. Some strategies include collaboration guidelines, build scripts, and pull request review processes.

Advertisement
Advertisement

More Related Content

Slideshows for you (19)

Similar to Maintaining quality in open source (20)

Advertisement

Recently uploaded (20)

Maintaining quality in open source

  1. 1. Maintaining quality in open source
  2. 2. Quality Engineer @ GitHub /meaghan-lewis meaghan@github.com @iammeaghanlewis
  3. 3. 3 CLIENT APPS
  4. 4. 4
  5. 5. 5
  6. 6. 6
  7. 7. 7
  8. 8. What distinguishes open source projects?
  9. 9. COMMUNITY 9
  10. 10. 1WHY INVOLVEMENT MATTERS
  11. 11. Contributions are key ● Engagement is good ● More eyes on the application ● More ideas for features and enhancements
  12. 12. CONTRIBUTIONS MAKE OR BREAK A PROJECT
  13. 13. ENCOURAGE THE COMMUNITY
  14. 14. Make it easy ● Helpful README ● Have contribution guidelines ● Maintain build & test scripts ● Have templates
  15. 15. Readme
  16. 16. Contributing
  17. 17. Scripts
  18. 18. Run tests in CI automatically
  19. 19. Issue template
  20. 20. Pull request template
  21. 21. COMMUNITY INTERACTIONS
  22. 22. Types of collaboration Issues Pull Requests Support
  23. 23. Issues ● Label issues accordingly ● Triage regularly ● Work with community members
  24. 24. Label issues accordingly
  25. 25. Triage
  26. 26. Work with collaborators
  27. 27. Pull requests ● Have test process & plan ● Test changes ● Give feedback
  28. 28. Define testing process
  29. 29. Manual test scenarios
  30. 30. Confirm PR tested
  31. 31. Support ● Make notices publicly available ● Pre-canned responses ● Have SLA for response
  32. 32. Halp
  33. 33. Canned Replies
  34. 34. Takeaways 1Make information accessible Have processes to support contributors Be responsive and helpful 2 3
  35. 35. Thanks! Any questions? /meaghan-lewis meaghan@github.com @iammeaghanlewis

Editor's Notes

  • This session is about Maintaining quality in open source. This is a personal journey and what I’ve learned from testing on an open source project. Throughout this session, I’ll share what have been some effective ways to build in high quality on open source projects.

    My hope is that some of these lessons might resonate with you whether or not you work on an open source project.

  • First, I’ll briefly tell you a little more about me.

    I’ve been in quality for the past 6 years now.

    Over the past few years, I have begun to work on open source projects and have become sort of an automation aficionado and open source advocate.

    Im excited to share some processes that have helped me in working with open source software.
  • At GitHub, I work under client apps which is for applications that GitHub builds to support developers in various ways.

    Throughout this session, I will feature some examples from these projects that highlight things we do to ensure quality.

    It includes the products:
  • At GitHub, I work under client apps which is for applications that GitHub builds to support developers in various ways. It includes the products:

    Electron - a platform to build cross platform desktop apps



  • Atom - which is a text editor


  • Desktop- desktop tool to use GitHub


  • Editor Tools - which focuses on the GitHub plugin for IDE’s.


  • When I first started testing open source software, I noticed there was something very different about open source projects compared to non-open source projects.

    There is something that sets them apart. Something that forces me think about the software from a different perspective.

    So what is it that distinguishes open source projects?
  • Community makes all the difference.
    Working on open source, you don’t just have to consider your teammates in your own software delivery team
    You have to take into account a whole community of contributors and maintainers.

    From a quality engineer’s perspective, it means you have a bigger team- there is more unexpected activity

    there are sometimes more pull requests than you expect. Definitely more issues and questions about the software.

    More to take into consideration
  • So community involvement makes open source unique.

    The community affects these projects in so many ways.

    Let’s talk for a few minutes about why involvement matters.
  • Contributions are really key in a few different aspects.

    As we just saw an example of, engagement is good and can have tremendous benefits to a project.

    Show a picture where a user submits a bug
    Having more eyes on the application is always a plus. With non open-sourced applications, of course there are users- but you might not interact with them. When projects are open-sourced, users find it easy to pop on over to the GitHub repository and open up an issue. The users want to be heard, they want you to know all the bugs they found, and they want them to be fixed.

    Show a picture where a user submits enhancements
    In addition to bugs, users can also describe pain points in their workflows- which is a plus, and can often suggest enhancements and new features as well. This can even influence the product team about what to work on next.

    Engagement is good, because it also means people care about your product.
  • So involvement is good, but we want community members to be able to easily understand how to contribute, what the guidelines are, and make sure they feel supported to help out.

    it’s important to build a community of contributors who are not just eager about the software, but can help contribute in a positive way and promote quality in the project.
  • Have pics/examples for each sub-bullet!

    The goal is to have good steps in place to tell the community best practices for working together
  • Have a friendly readme. This is the Atom README that shows details about the project, resources for websites to visit for more information and support.

    There is a link to follow them on Twitter

    A section describing a code of conduct

    Then there’s steps for installing Atom and getting set up to use it

    This is an example of a great README that’s full of juicy information
  • Whereas READMEs help people use the project, contributing docs help people contribute to the project. It explains what types of contributions are needed and how the process works.

    The contributing doc should include a code of conduct that describes expectations for participating in the project and steps to report inappropriate behavior. The code of conduct sets ground rules for participants’ behavior and helps to facilitate a friendly, welcoming environment.

    Contributing docs should also include information about how to submit pull requests, issues and feature requests.

    While not every project has a CODE_OF_CONDUCT file, its presence signals that this is a welcoming project to contribute to.
  • Makes it easy
    Makes it so that people follow the same steps to do stuff. More uniformity, less surprises. That’s always a motto I like to live by- so boring, I know. But extremely helpful
  • In addition to having those scripts locally it’s also great to use those scripts to run in CI and then set it up so that it is integrated with pull requests
  • Pull request templates are helpful to have in order to ask directed questions so that there is enough information in the description of the pull request for reviewers.

    Similarly, it’s also a good idea having an issue template for the same reason.

    Templates can be really helpful to directly ask all of the details you want to get from users- although unfortunately people are people and break the rules sometimes and don’t fill out all the fields that you think are helpful
  • Pull request templates are helpful to have in order to ask directed questions so that there is enough information in the description of the pull request for reviewers.

    Similarly, it’s also a good idea having an issue template for the same reason.

    Templates can be really helpful to directly ask all of the details you want to get from users- although unfortunately people are people and break the rules sometimes and don’t fill out all the fields that you think are helpful
  • Next, I want to talk about the different types of contributions that the community makes and how to build quality processes around these areas.
  • There are 3 main avenues that the community can get involved in a project
  • People are going to email in support questions. It’s important to:

    Make anything that needs to be made available, made available

    Pre-canned responses for standardization

    SLA for response time in order to
  • Give people information they need upfront. Make it accessible

    Be accessible. Be responsive. Be helpful

    Have good processes in place to support product and follow processes to maintain/ensure quality

×