Great idea, @Grum999. It would be so great if it were mandatory to pick a tag—and only a single tag—then maybe feature requests could be kept to a single item (thus eliminating the dreaded “laundry list” feature request posts).
For a feature request concerning vectors + animation, having the possibility to put 2 tags is mandatory
In this case it’s not a problem, I think the feature request will just be ignored by developers
I don’t know
It seems tags are available per category, I don’t know if in 2 different categories we can have the same tag name
In worst case, we can change “Vector” to “Vector tools” or “Vectors”
No it would clash. Two tags can’t have same name sadly. Tags can be restricted to per category but they live in same space so there can be duplicates.
I’ll check all tags you listed and add them if possible tomorrow. We need to come up with names differently. May be add a suffix like “animation-FR” or something else.
I would also suggest tag like - enhancement, user interface, etc
Here an updated list, taking in account existings tags, I think “related” suffix will be better than “FR”
With “FR” I initially thought to french related thing
Tags
Cover
animation-related
Everything related to animation in Krita
brush-engines-related
Everything related to brush engines in Krita (UI, brush engines, options, brushes…)
color-management-related
Everything that could be related to color management: color profile, color space, color picker, …
files-related
Everything related to files: open, save, import, export, UI, supported formats, …
filters-related
Everything related to filters: filters, but also filter layers
layers-related
Everything related to layers: layers, layer stack, UI, …
resources-related
Everything that is related to resource: management, bundles, brushes, UI, …
scripting-related
Everything that is related to scripting: API, UI integration, …
user-interface-related
Everything that could be related to user interface: shortcuts, UI, theme, …
tools-related
Everything related to tools: brushes, line, circle, paint, selection, …
vector-related
Everything related to vector layer: text, shapes, …
User interface was already in the list
Concerning enhancement, by definition a feature request are made to improve/enhance something…? Or I might misunderstood the meaning of a such tag?
For other tags if needed, it could be possible to add them later
Currently I tried to build list from components list in bugs.kde.org (not exactly the same, because tags here are more related to a global domain than a specific functionality)
I forgot about it . For enhancement I meant improvement of already existing feature.
Can we think more about the suffix or prefix? the related suffix is good but If we can find something more shorter then good otherwise we can fallback on this.
Also let me know when you want to make the tags, the tags need to be put in groups and then that tag group be restricted to the category.
Oh ok
Then having new-feature and improve-feature maybe?
Yes, related is not short
But it was really easy for everyone to understand. More than “FR” acronym I think
I’ll try to find something else.
I don’t know if it’s possible to rename a tag? I mean, once it created and used, can the tag be modified? already tagged topics are updated with new tag name?
If yes, we can start with related suffix and change it later? (I prefer suffix than prefix)
I’ve some availability today to do it, as soon as we are agree with tags names
On my side it seems I can create tags when creating or modifying a topic:
Don’t know if when it’s created it’s for the current category only or all categories.
I don’t think I have the grant to define category for a tags once created.
Text related feature requests could be a category of its own. And something for Keyboard shortcuts/ canvas input settings would also be helpful, I think. Those requests are usually rather small and tend to go unnoticed as a result. So sorting those by tag would at least give them some visibility.
How about “Keyboard input” for both? Or perhaps something more descriptive that I cannot think of at the moment.
We can define tags for each functionality, but it will become useless I think.
And after we will have request for a specific tags to clipping mask
The idea with my proposal here is to get general domains for features request; you can still indicate in feature request title "new shortcuts for doing XXX " and tag it as “user-interface-related”
And concerning text, I have hesitated… I’m not sure about that because it’s a tools + vector related thing and, as for shortcuts, starting to create tags for specific function might be useless at the end if there’s too many tags
I only mean to include 2 additional tags, because I think that those are the only two areas that are not covered by the others.
Text can get very deep in terms of settings, language support, styles, etc. There is quite a lot that could be added there, depending on the direction Krita goes.
-related → initial proposal -request → same length than ‘related’, I prefer ‘related’ -domain → I’m thinking about this one, shorter from 1 character than ‘related’ -scope → ? -wish → I’m not convinced, but that’s currently the shortest proposal…
We’ve got two different ideas going here; -FR, -request, and -wish are redundant as to restate the category (“feature requests”), -related, -domain, and -scope are redundant as to purpose of a tagging system (a tag for “tools” already implies “something in the realm of tools”).
As for which is preferable, I don’t know.
I thought of another idea, though; -idea/-ideas.
Simply put the users will see both the posts from development and the artwork in one page when they click the tag. And it would be counter productive to our goal of segregating the posts thus making the tags useless.
Emoji is not possible I think. The tag text are sanitized and emoji are converted in their shortcut form like this -
P.S. To accommodate tags in categories other artwork we have already removed the masonry layout for tag pages. It is now a list of post with small thumbnail whereas earlier it was only big thumbnails arranged in a responsive pinterest style layout.
That’s what I was wondering too, you beat me to it. But, it’s easier to type in -wish to search for the feature request tags than having to look for the unicode…
Otherwise, I prefer “-Wish” as indicator for feature requests. It has become a convention for Rhino, where most feature requests have a title like this: “Wish - Implement feature X”. So if users see these tags being used, they’ll eventually adopt them themselves. In short, I find -Wish plenty of descriptive.