Jay I like they way tagging ideas have developed 👏.
Re: Scoping
I understand concerns about a scoping tag. But I do like the idea of scoping because it shows users / potential users that the devs have though about a feature and have a top level ‘guesstimate’ of how much effort something is.
This is useful because (a) many a-time in a past life I’ve asked for features that seem trivial to me, but were in fact much harder and (b) the opposite - some features that appear hard, might actually turn out to be relatively straightforward. And for those that you’ve not yet had time to think about you don’t add a scope tag (or add one like ‘YetToScope’). We found that users were much more receptive to things not getting done if our devs had given some though and had a reason(s) why it was hard.
Also, Scope, has some bearing on Priority. A feature/bug scoped as ‘quick’, and asked for by a fair number of people might get done. But if scoped as ‘hard’ then it might not get done.
‘grouping’
One other thing that we used to try and do in my ‘managing a s/w company days’, was to ‘group’ certain features to address in a dev round. So, for eg., it might be that when done together, apparently un-connected features x, y, and z, allows you to more effectively address a wider market area - in this context maybe it means that WorkFlowy customers no longer have any reason not to use Legend (obvs, I just made that bit up to illustrate the point). But you can’t do this without having a broader view on Legend and where it stands relative to competitors + the direction you want to push it in.
