It's fairly common for people to show up and be interested in finding easy stuff to work on. This stuff basically doesn't exist and probably never will: it doesn't make much sense to deliberately leave easy bugs broken just because someone might show up and want to fix a couple of easy bugs.
Almost all of the work that's valuable to us requires a depth or bredth of context which can't be acquired in a few hours here and there, and probably always will. I think it also always should, in that as long as we continue refactoring and clearing technical debt aggressively and having solid static analysis support tools, we should never have a large backlog of human-intelligence codebase tasks. The closest we've ever come were probably pht() and phutil_tag(), which both have a lot of subtleties and we mostly automated phutil_tag() anyway. These tasks are also incredibly boring to write and review.
So, accept this as a reality and realign the contributor documentation to try to deal with this case:
- Set expectations about starter tasks not existing and throwing a couple of hours at the project writing code being a hard path.
- Suggest non-code contributions which anyone can do.
- Segue into code contributions with context and suggestions.
