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
Summary: Fixes T3426. This describes all the weird stuff we've got, at least. We can expand this as we get more contributors or after writing CSS lint.
Test Plan: Read document.
Reviewers: btrahan, chad
Reviewed By: chad
Subscribers: epriestley
Maniphest Tasks: T3426
Differential Revision: https://secure.phabricator.com/D8720
