Maintaining quality in open source

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

Maintaining quality in open source

You are reading a preview.

Check these out next

Maintaining quality in open source

More Related Content

Slideshows for you (19)

Similar to Maintaining quality in open source (20)

Recently uploaded (20)

Maintaining quality in open source

Editor's Notes

Maintaining quality in open source

You are reading a preview.

Maintaining quality in open source

Recommended

More Related Content

Slideshows for you (19)

Similar to Maintaining quality in open source (20)

Recently uploaded (20)

Maintaining quality in open source

Editor's Notes