Is this level of granularity useful?
Would a simplified selection be more useful, e.g. consolidating the current list of 91 possible options down to something like:
As a developer I use component when checking what known issues are reported for an extension.
As a release manager I use “community” always to make a heading for community updates. For the major releases I often group the announcements based on components (so a heading for all WFS updates).
The vulnerability component is used more as a tag during the release process and could be handled another way (with a flag, or a vulnerability score, or link to a vulnerability report).
I agree with Jody. Vulnerability should be followed with another mechanism and should not remove the information of the component of the issue.
Regarding the granularity of the filter, this best practice page recommends to not exceed 20 items.
Given the number of extensions we have, I would avoid to have one component per extension. But we must separate official extensions from community ones.
Do we want to have tickets regarding documentation?
Okay I will look if I can make something like a vulnerability rating which can remain at 0 for most tickets, and go to 10 reflect CVE score for vulnerability issues.
With that in mind we can adjust components down to something smaller.
I do not find the component “geoserver” to be descriptive, and we can certainly go smaller that 20 components.
“Data Sources” - connection GeoServer to data stores, coverage stores, etc. To be clear that this is not output format issues encountered when using “web services” above.
“Docs and Website” - non functional documentation and communication.
“Internal” - for ‘main’ and ‘core’ and all of those java code things
“User Interface”, for the web or gui tickets.
“Security” I think this is okay, it is not the same as “internal” as this covers interaction with external systems, and is also different from data sources above
“REST and Configuration”, think these are close enough in spirit
“Extension Module”
“Community Module”
I was recently able to figure out how jira visibility settings work and updated the instructions for placeholder issues. There is a little lock symbol next tickets which you can use to hide tickets and make them visible only to the geoserver-security volunteers.