If you don’t feel empowered to make a decision whether something is a bug, feature request or help request just don’t touch the issue and leave it for the next triager to decide. The point I keep making is it doesn’t matter if you mis-categorize an issue as it will end up getting corrected along the way so don’t be scared of that.
It’s more important to clarify what the requester means and begin the conversation that ultimately get’s to the bottom of what the issue is about. I’m still not convinced adding another label will help further this goal.
You are looking into only one label, but my proposal had multiple additional labels (triage needed, needs feedback, MDG working on it, community working on it, waiting for somebody to volunteer/pull requests welcome) and I already explained why I think they work as a whole better: being clear very quickly that something is happening with a ticket, and in which state it is. It seems you do not agree that having an explicit verbose label tells things better than no label? You are saying that all readers of issues will be familiar with triage process and they will understand what no label means? And that they will read through all the comments to understand what is the state of development?
We’re not trying to solve for people who have stumbled upon the repo without having read the contributing docs. Adding more states/labels only increases usability if everyone involved has a complete shared understanding of what the labels mean and applies them perfectly and consistently (this is unlikely to happen). Otherwise they end up being extra work that is sometimes useful and sometimes just more noise.
Of course nobody will ever completely share understanding of all labels, even after reading docs. But you cannot use that argument to claim that labels will not improve understanding of the state of issues.
Anyway, some community members asked for labels, you do not agree with them, OK. But this could again be the case where it would be useful to have a Meteor foundation and clear decision making process so that we could make decisions as this.
We want to actually run the current process for a time being to weed out more of the issues before revising it (other contributors have suggested this too).