A good first bug is one that has been tagged specifically as a good place for interested people to get started. The idea is that it doesn't require a lot of deep knowledge, is reasonably clear, and won't take too long to fix.

Finding Good First Bugs

For Taskcluster, you can find good first bugs in Bugzilla on https://codetribute.netlify.app/projects/taskcluster Codetribute]. We are less consistent about tagging good-first-bugs in github, but you can also look at our list of github issues.

Once you've found something to work on, do a little research about it. Find the source code yourself, or try to reproduce the issue. Then, based on what you've learned, post to the bug and show you've done your homework. Something like, "I ran the app locally and reproduced the issue using the steps above. I think the fix would be in the flub function in flubby.py. Am I on the right track?"

Making Good First Bugs

It's a great problem to have: lots of people solve our good-first-bugs, especially as warm-ups for programs like Google Summer of Code or Outreachy. So, we need a steady supply!

To make a good-first-bug, create a new bug in bugzilla. In the keywords field (not the whiteboard!), add "good-first-bug". In the mentor field, add your name. Because of the heavy integration with the rest of Mozilla, we have a much higher rate of bug pick-up in Bugzilla than for Github issues, so prefer to file good-first-bugs in Bugzilla over creating Github issues.

Tips for inventing good-first-bugs:

• [GOOD] That moment when you think, "boy, that's annoying, I bet I could fix that quickly, but I should probably stay on task". File a bug! Maybe a UI issue in the TaskCluster tools site, or a refactor of the implementation of an API method in a microservice. Or maybe taskcluster-lib-foo is missing a convenient method.
• [GOOD] A bunch of similar-but-slightly-different tasks. This might involve using a newer version of a library with a different interface, across all microservices. Or adding a list of commands to a tool. These are nice for newcomers because after the first is done, the diff provides nice context to guide them in finishing the next tasks.

Anti-Patterns:

• [BAD] A project that sounds boring and not very creative, like fixing lint issues or running npm-update. These don't help a newcomer to learn about the service, and are either trivially easy or (if things go wrong) too complicated.
• [BAD] Anything requiring design. Newcomers are wonderful people, but they will have ZERO context for TaskCluster, so asking them to come up with a solution is not practical. If you can propose a solution, and it's not too complex, then *implementing* that solution will make a good first bug.

Tips for writing good-first-bugs:

• Point to the source code - at least the repo, and preferably a few of the relevant source files
• Give steps to reproduce, so the newcomer can be confident they understand the issue
• Write one to two sentences of getting-started steps to help newcomers do the research mentioned above. Suggest checking out the source and building it using the instructions in the README, and getting things to the point of being able to reproduce. Point at the tests as well, especially if the solution should involve adding new tests (it should, right?).