Organising rules in the manager service #313
Replies: 2 comments 1 reply
-
This is brilliant. Thanks for making sense of this, Jon! I can’t think of more users right now and looking at options, I’d be inclined to go with 3.Both as long as it’s very clear to rule owners what is a tag vs. what is a category. If we take a step back from the idea of categories and tags and look at everything we have, we see that we are using terms that relate to: What is the origin of a rule
What is the purpose of a rule
What is the content of a rule
What topic/event/story does the rule relate to?
It may be worth looking at the language to make it clearer to rule owners. One thing to consider is if this rationalisation would entail having to restructure the content of the existing rules and how would we go about it so we don’t have to go rule by rule to do so. |
Beta Was this translation helpful? Give feedback.
-
@pradasa really useful, so in your list we've got origin, purpose, content, topic
So perhaps
What do you think? |
Beta Was this translation helpful? Give feedback.
-
In our google sheet, there are two cells we can add metadata to help us organise rules – the category, a single, mandatory value, and the tags, an optional comma-separated list of strings.
Examples for categories include ‘Style guide’, ‘Check this’, ‘Names’, ‘Style guide and names’, ‘Typos’, ‘Dates’,’Style guide and names’, ‘Typography’. Examples for tags include ‘Names’, ‘MP’, ‘General’, ‘SG’ (Style guide), ‘Tokyo2020’ (since removed!).
We can see a few problems here:
In figuring out how to proceed, it’s worth clarifying the question – what user stories are we attempting to satisfy with categories and tags? Do we need either, both, or something else?
It’s worth noting that while there’s plenty of overlap between tags and categories as they stand, we can see some legitimate use cases for more than one category emerge:
1. As a rule user, I can see a high-level indication of where my rule has come from.
At the moment we use categories to do this. The uppercase text at the top of the match tooltip shows the category:
‘Style guide and names’ is obviously not specific enough, but the hypothesis is that it’s useful to know where a rule is coming from. This is related to Typerighter’s vision of transparency – ‘When Typerighter matches text, it will be clear why that match has occurred.’
2. As a rule owner, I can identify rules that relate to one another, making it possible to discover all the rules that belong to a particular domain – and remove them.
At the moment rule owners use categories to do this. One example above is ‘Tokyo 2020’. The rules for Tokyo are now gone – no longer being relevant – and each rule having the same category made it easier to find them all and delete them once they’d served their purpose.
Are there more stories we can think of?
A few options:
Appendix: our current categories and tags
Tags
Organising rules in Typerighter
In our google sheet, there are two cells we can add metadata to help us organise rules – the category, a single, mandatory value, and the tags, an optional comma-separated list of strings.
Examples for categories include ‘Style guide’, ‘Check this’, ‘Names’, ‘Style guide and names’, ‘Typos’, ‘Dates’,’Style guide and names’, ‘Typography’. Examples for tags include ‘Names’, ‘MP’, ‘General’, ‘SG’ (Style guide), ‘Tokyo2020’ (since removed!).
We can see a few problems here:
In figuring out how to proceed, it’s worth clarifying the question – what user stories are we attempting to satisfy with categories and tags? Do we need either, both, or something else?
It’s worth noting that while there’s plenty of overlap between tags and categories as they stand, we can see some legitimate use cases for more than one category emerge:
At the moment we use categories to do this. The uppercase text at the top of the match tooltip shows the category:
>>>>> gd2md-html alert: inline image link here (to images/image1.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>
‘Style guide and names’ is obviously not specific enough, but the hypothesis is that it’s useful to know where a rule is coming from. This is related to Typerighter’s vision of transparency – ‘When Typerighter matches text, it will be clear why that match has occurred.’
At the moment rule owners use categories to do this. One example above is ‘Tokyo 2020’. The rules for Tokyo are now gone – no longer being relevant – and each rule having the same category made it easier to find them all and delete them once they’d served their purpose.
Are there more stories we can think of?
A few options:
Appendix: our current categories and tags
Categories:
Tags:
Beta Was this translation helpful? Give feedback.
All reactions