A Beginner's Guide to Developing on a Project

This guide assumes you have already read my piece about the development process: Open Source Software primer: The Development Process. Please take a few minutes to read through it if you haven't already as this guide builds directly on it.

When you start developing on a project the tasks that need tackling are typically all listed in one place, the kanban board typically. And it can be quite overwhelming looking at a big board of issues, trying to work out how you can get in without treading on anybody's toes. If this is open source then you are probably joining the project midway through the development cycle. There's a lot to fix and it's not always clear what to do even once you've taken on an issue.

So how do you choose where to start? Well, here are four simple criteria you should consider.

1. Priority of the issue
2. Ease of work required
3. Type of work required
4. Your ability to take on the issue*

So how do you use these criteria to actually whittle your choices down to one or two?

• Rank everything by priority

Tickets (general term for "issues" in GitHub) in the development process are assigned varying levels of priority from "critical" to "minor". The higher the priority, the more urgent a fix is required and also the higher the stakes for getting it wrong. I wouldn't recommend leaping straight onto a high-priority ticket but you could perhaps consider contacting a developer who's already on an issue to see if they'd like some help? Otherwise, as you ease yourself into the development process it can be good to tackle some minor tickets to start with. These are low-stakes and you are unlikely to step on anyone's toes in fixing them. If you want to tackle something bigger then do reach out to the community for guidance first.

• What do you feel comfortable doing?

You should be aiming to do a good job and to do a good job you need to feel confident in what you're doing. So next, filter out any issues you don't understand. It may be that this is all of them! That's OK, we'll address this shortly.

• Is there any grind-heavy work that needs doing?

A good first step is to do some "grind" work; i.e. something simple, and repetitive that needs to be done. For example, writing additional tests for some uncommon edge cases or spell- and grammar- checking the documentation. This tends to be low-skill, high-effort work, and is vital for the health of a project.

Consider the remaining issues and see if there are any grind issues left.

• Are there any issues left?

There may not be any issues left and that's OK. There are a few things that will always be welcome.

• More tests - you can always have more tests
• More examples - is there an example of every possible use case of the product in the docs? No? Then there can be more examples.
• Are there grammar/spelling mistakes in the docs? Read through them and fix those.
• What about examples in the docstrings? Add some more to those.
• Has the product been tested in the field? Use it in anger! Find some bugs, make some issues, maybe even fix them yourself.

Aside: Prioritisation labels

You've probably seen variants on these before, but they are commonly seen in software when working with priorities. It pays to be familiar with the nomenclature.

1. BLOCKER
   1. The highest priority. Until this is fixed, the project is dead in the water
2. Critical
   
   1. This needs to be done as a matter of urgency. 
3. High/Major priority
   
   1. Until this is fixed The PM will not be able to sleep soundly.
4. Low/Minor priority
   
   1. We should really fix this, but we could probably delay it until next release if we have to
5. Unassigned
   
   1. No one is sure how scared to be of this yet

OK I have an issue and I'm ready. How do you do it?

The process for doing the work is actually fairly simple and universally applicable.

1. Assign yourself to the issue on the issue-tracker (GitHub/ADO/JIRA/etc.)
2. "get" the code on your computer (clone/fork/branch)
3. Make the changes (& make regular commits)
4. Push your changes
5. Make a pull request (mention the original issue in it)
6. Undergo code review
7. Merge your changes
8. Decide what to do with the original issue
   
   1. Did you make it? -> close the issue
   2. Did someone else make it? -> post something asking them to review the new changes -> they close the issue
9. Back to square 1

In commercial code development there are a couple of extra steps of QA that go in under #8, which I will mention here for completeness but are much looser generally in the open source world. As detailed in the previous article, you can still do QA testing in an open source project, but it is not as rigorous a step as in closed source development.

Commercial Development Additional Steps

When doing commercial development you don't simply close the ticket once it is complete. You close it with a reason. For example, "ready for QA". You can use a variety of reasons depending on why you're closing the ticket varying from the passive "Can't do" to the aggressive "Won't do".

After this, Quality Assurance takes over and reviews the ticket. They'll attempt to reproduce the bug and ensure your fix actually works. Once this is done then the ticket is closed.