Document potential refactors for first time contributors

[doodzik]

Problem

A couple of months ago, I asked for pointers for first-time contributes to RubyGems/Bundler via slack. One of the problems that @indirect brought up is there aren't enough starter issues to meet the demand for first-time contributors. It would be good to enable more people to contribute to bundler.

Solution

I noticed that some PRs surface ideas for potential refactor but are unrelated to the original PR and thus don't get implemented. Often, those ideas are possible to implement by a new contributor. So instead of losing track of potential refactors, why not document them and make it easy for people to contribute. Those refactor are also an excellent way for new contributors to familiarize themselves with the codebase and make more complicated changes.

What do you think if we start documenting potential refactorings in issues and assign good first issue labels to them?

Here are some of the kind of refactor I had in mind:
remove magic number from subprocess.rb
abstract make_program into a dedicated class

[indirect]

Sure, this seems reasonable to me, although I would want to hear from @deivid-rodriguez and @simi as well. I expect they will get snapped up quickly and then we will be back to having not enough starter issues. 🙂

[doodzik]

I would love for that to be the case! That would mean people have build context around bundler/rubygems and the codebase has become a bit better 🙂

[deivid-rodriguez]

@doodzik I agree, I try to open issues for things I feel need improving but I won't be tackling myself directly, but I did miss the one about documenting exit codes in our test helpers, I'll create an issue for that now. The thing I struggle more with is to decide what's a "good first issue" and what's not. Sometimes I have the feeling I'm assigning this label to "easy tickets", but I feel I'm proposing boring stuff to new contributors, so in essence, I believe everyone should work on what they find more rewarding, even if it might be a bit too challenging initially.

[doodzik]

The thing I struggle more with is to decide what's a "good first issue" and what's not. Sometimes I have the feeling I'm assigning this label to "easy tickets", but I feel I'm proposing boring stuff to new contributors, so in essence, I believe everyone should work on what they find more rewarding, even if it might be a bit too challenging initially.

Agreed, it shouldn't be about dictating, but rather giving markers of what good starting points are. I personally found bundler/rubygems to be quite challenging projects to onboard and I would have benefited from issues that allowed me to build context.

I wonder if a good way to approach it would be to include some followup issues that would be more challenging. So that there is a progression.

[deivid-rodriguez]

Done! #5165