I don't like "good first issues" If it's simple enough to be the first, I'd fix it in less time than writing an explanation of the problem. Anyway, when someon

I don't like "good first issues" If it's simple enough to be the first, I'd fix it in less time than writing an explanation of the problem. Anyway, when someone makes a post about a typo in the docs or error message of Racket, or something that can be solved editing one or two files, I like to post something like: > Nice report. The error is in the file [whatever]. Do you want to fix it and send a pull request? Otherwise we can fix it. Some people want to contribute and are happy with that. It's a good first step. They may send something more complicated later. Or just be happy to have a commit merged. (Anyway, good bugs reports are very useful, even if the submitter does not fix it.) As a general recommendation, start with tiny changes. Fixing typos is good because they must be fixed. For features, it's better let's say up to 6 hours of work. You never know if they are going to merge it, so it's better to waste few time. Later, once you have a few contributions try longer tasks.