Maintaining quality in open source

No notes for slide

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

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

Meaghan Lewis

Maintaining quality in open source