Create an `inbox` tag identifies issues that need a response

[meltsufin]

Fixes: #264.

[tstromberg]

This seems to duplicate the recv tag, though with a slightly different behavior: the recv queue only is triggered if the last commenter is the original author of the issue/PR.

I'm concerned about the 'receive' vs 'inbox' naming. Is there a clearer name we could give this tag?

[meltsufin]

I'm open to suggestions, but inbox is the best name I was able to come up with. Personally, I wish recv had this behavior. The idea is that any comment by a non-member is something that may need a response.

PS: Thanks for creating this tool. It's really useful for us because we have many repositories we need to keep an eye on, and this allows us to see everything in one place. Of course, the other features are great too!

[tstromberg]

I personally found that it didn't scale as well on large projects for every subsequent commenter to send an issue back into the queue, but I can certainly see it work well on some projects - so I am all for this change.

Instead of inbox, what do you think about rethinking all of the names, with aliases for the current tags to prevent breaking backwards compatibility:

• in: current behavior, triggered if it's an author
• in-other: triggered if it's not the author
• in-question: triggered if a question is raised

I'm open to alternative proposals, but would prefer names that felt consistent and short.

[meltsufin]

Regarding scaling for large projects, we use inbox in combination with a responded: -14d filter, which sufficiently limits the volume for us.

I don't mind your proposal, but regarding in-question, would it apply to just author?

As an aside, why does recv and recvq include the author restriction? Can't one just combine inbox and author-last to get recvq. Similarly, why not have a simple q tag that would tell whether the last comment contains a question. I feel like the simpler tags can be recombined more easily to get the desired effect.

[joeyparrish]

@meltsufin, I've just been made a maintainer of this project after not being able to find anyone at Google active on it. I'm a user of it, and I've made a few small changes, but I don't have the experience to really understand backward compatibility issues without doing a lot more reading.

I'm going to put this on hold for now, but if you're still interested in this or similar changes, please let me know and we can discuss the best way to reimagine the tag system without breaking existing deployments.

[joeyparrish]

@meltsufin and I talked about this face-to-face, and we decided that a project's needs may require specific logic that triage-party doesn't provide. Although the send/recv tags seem a bit limited to us both, we don't want to change them (for backward compatibility reasons), and we also don't want to try to add new tags to cover every scenario every project might care about.

The more flexible system for this is issue labels, which can be automated with bots using custom logic specific to each project. Writing triage party rules for these automated, project-specific labels is the best solution for power users. The send/recv tags that are built in will stay for those who don't need something custom or who already rely on them as-is.