Summary: 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. Test Plan: Generated and read documentation. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8872