x/tools/gopls: triage process for feature requests

[findleyr]

This is a meta issue.

We've had limited bandwidth for ad-hoc feature requests in gopls for the last 6-8 months, due to some fundamental work on scalability landed in v0.12.x and v0.13.x.

Meanwhile, we have an active triage rotation for bugs, but do not have a similar process for features. We should revisit our backlog of feature requests to re-prioritize and identify good contribution opportunities. We should also endeavor to close feature requests that we're unlikely to ever implement, rather than leaving them in limbo.

Tentative proposal:

• Create a public GitHub project to sort feature requests into categories:
  • Planned: features that we actively plan to do ourselves. Most of these should be associated with a release milestone.
  • Help Wanted: features that we don't immediately plan to do ourselves, but would be happy to accept as contributions.
  • Future: features that we'd like to do eventually, but which don't make good contribution opportunities.
  • Likely Decline: features that we probably won't ever do. We should make a comment on each of these indicating their status (in addition to sorting them to this category) so that folks have an opportunity to disagree.
  • Untriaged: issues that we haven't discussed yet.
• Actively sort incoming feature requests into these categories during our regular bug triage meeting, and meet ~quarterly to refresh the project board.

CC @golang/tools-team