
Thought: It takes work to verify a reproduction is valid or not, and the process can yield a lot of context (in this case, a PR to fix the moneta require issue even). When I tried to reproduce their example, I couldn’t, and it looks like the issue had already been fixed. Bug reports are easier to work with than feature proposals. Thought: Many issues straddle the line between feature and bug report. Document: Deprecation warnings and other problems that come up that might be good for future contributions. The reproduction example runs now that the original reporter gave us without an error. Add the missing require to fix the failure.
Moneta is defined as a dependency in the Gemspec. Search for where Moneta is defined (Is it internal? Is it external?). GITX BUG LIST CODE
Ask: “Where is this code or constant defined.”.In the video, this is where we found the bug “uninitialized constant Moneta.”.Reproduce: On bug reports with reproduction steps, see if you can follow the reproduction steps and verify the bug.In addition to the code referenced, try to see if there are other references to the code.View: If the reporter mentions code you’ve never seen before, find it.Click: Check linked issues for possible additional context.Issue 2 Examples produced by the CLI don’t show correctly help options #28
If you don’t have enough context from the issue, likely, others don’t have enough either.
Context building is an important activity. If they give benchmarks, run them, and verify the results. When someone talks about performance, ask for benchmarks or other ways we can quantify it. As the triager, you do not need to fully understand every aspect of the conversation, but you need to work to drive the issue to completion. Ask: “Can you point me at another location where this is implemented?”. Grab some example code or write some pseudo-code to validate we understand each other correctly. If we don’t know if it’s a priority, how could we find out? Is there a way for us to test our assumptions about prioritization? i.e., how could we write a benchmark to quantify “give some nice speedups.”. List your assumptions, ask for clarification if needed. Use the GitHub UI to identify commentators of note Contributor/Author/Member. Triage session 1/4 Issue 1 Heroics should use keep-alive connections #16 If you like this “with me” series, find me on twitter and pitch me what you would like for me to work on live and record for another session. Recommended: Increasing the playback speed to 1.5x or higher since I didn’t cut out the “umms” and pauses either. Recommended: Increasing your resolution on YouTube to the maximum so you can read the text better. I’ve never triaged the issues on this repo before, so be prepared for a raw and real-time triaging session. As a result, they should be accessible to someone from any programming language background. This open-source repo is written in Ruby, but the issues tended to be about higher-level concepts such as stdout/stderr and accessing APIs via HTTP. The videos are split up into 4 sections with a bonus video at the end of my work on a PR to remove some deprecations. As you’re watching, try asking yourself how you would respond and what questions you might ask.
While I don’t recommend you sit down and try to respond to every open issue in the repository, hopefully, by watching me triage issues, you can help get a sense of how you might be able to dig in and start contributing. Afterward, if you want to come back to a piece of advice or technique, you can skim my notes instead of re-watching the whole video. I cleaned up my notes and put them all here along with the videos so you can follow along. I re-watched the videos and took notes on the types of problems I encountered and the questions and solutions that I explored along the way. I didn’t edit the videos, so any mistakes and accomplishments are raw and live to see. In this post and video series, join me as I triage 11 issues on a repo that I didn’t create and don’t have much experience with. Contributing to open-source can be intimidating, especially when you’re getting started.