add backlog section for discussion

Created by: Joelkw

@sourcegraph/web realized this wasn't documented after @AlicjaSuska asked me about adding a code insights issue to our backlog. Obviously, the whole backlog process is new for us and we can iterate regardless of what we decide here.

(This is non-urgent and perhaps something to discuss in our sync tomorrow.)

One question I have on ownership:

• Should we own the backlog (so, others create issues and label team/web and only we then add to backlog whenever we see, to verify they're actually web team issues)?
• Should just I own adding to the backlog? One reason for this – if you add something to 'to triage' I might not know it was added, unless I also track all new team/web issues (which I am currently) so I don't see too much purpose in asking you to take time to add it to 'to triage' if I still have to look at the issue anyway. It would still be helpful for me if you see a team/web issue that's not actually team/web in the codebase that you tag/comment as much, like Felix did here.
• Do we want people adding things to 'to triage' even if those people aren't on the web team (and I'll still use the 'team/web' notification I get in order to not miss triaging anything)?

And one more on overall purpose:

I created this for "slack time" (bugs, small issues, things we could work on that aren't RFC-level or big projects that ought to have multiple issues). I still think that makes sense. Does that mean we want or need a separate board to track our roadmap? (Do we feel a need to have code insights, extensions improvements, etc on a board even when we're not actively working on them? Do we feel this would help other teams beyond having them in our roadmap?)

My preference on that question is "no;" basically "backlog = small bugs/issues we can work on as need be," "iteration board = detail view of what we're currently working on," "roadmap = things we plan to work on but aren't broken up into details because we're not working on them yet." I'd rather not maintain a board to just map against the roadmap – if anything gets added to one it should be added to the other anyway. Nor do I feel like we need a combined single board – I think you all know well when to work off our iteration board vs when to grab something from the backlog.

(In the case of "should we have a code insights issue on a board somewhere" I've told Alicja at the moment that I think when it's a "single issue" it belongs more on a product+design board rather than our boards.)