Should we be filing issues in the same repo Issues · plone/Products.CMFPlone · GitHub regardless of whether the problem is likely in Volto vs classic?
e.g. on my 6a1 site the default Events collection aggregator does not work, and I cannot edit it. If I try to add a new Collection, the page is blank (FF 94.0.2). I'm assuming that collections work in classic 
so should I file the issue in the Issues · plone/plone.volto · GitHub repo?
In this case, in particular, it's a plone.restapi problem, I'd say it goes to that (plone.restapi) issue tracker.
Thanks @tiberiuichim – could you explain your reasoning, so that I (and others) could try to follow the same chain to determine where best to report issues?
Hi. I would still prefer to report issues in the respective repository. But there will be cases where devs, particularly newbies, can't filter out the destinations the issue/bug/feature should go.
We can also debate a central issue tracking system like https://www.mantisbt.org/ or Redmine.
Personally I watch activity in the plone/volto and plone/plone.restapi repos. I don't really know which repo should be used, that should be decided and communicated by the framework team, maybe? Volto team, perhaps?
Now, going one step further from your problem, assuming that you get the bug entered into the right tracker, whichever is most popular and gets the most eyes, you know how it is... somebody has to be bothered by it enough to pick it up and fix it. The fact that this particular problem wasn't fixed so far is an indication that it is a feature that's not really useful in Volto (because the listing block exists and together with the page composition capabilities, you get a more flexible solution). It is the sort of thing that needs to be fixed to get Plone 6 to be complete, probably. Who, how, when will it be fixed, I don't know. But as Timo says, Plone is a do-ocracy. For better or worse.
The reason to recomment plone.restapi bug tracker is the error message that the server gives when serializing the Collection schema:
{
"message": "",
"traceback": [
"File \"/home/kitconcept/.buildout/eggs/Zope-4.5.5-py3.8.egg/ZPublisher/WSGIPublisher.py\", line 162, in transaction_pubevents",
" yield",
"",
" File \"/home/kitconcept/.buildout/eggs/Zope-4.5.5-py3.8.egg/ZPublisher/WSGIPublisher.py\", line 371, in publish_module",
" response = _publish(request, new_mod_info)",
"",
" File \"/home/kitconcept/.buildout/eggs/Zope-4.5.5-py3.8.egg/ZPublisher/WSGIPublisher.py\", line 266, in publish",
" result = mapply(obj,",
"",
" File \"/home/kitconcept/.buildout/eggs/Zope-4.5.5-py3.8.egg/ZPublisher/mapply.py\", line 85, in mapply",
" return debug(object, args, context)",
"",
" File \"/home/kitconcept/.buildout/eggs/Zope-4.5.5-py3.8.egg/ZPublisher/WSGIPublisher.py\", line 63, in call_object",
" return obj(*args)",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.rest-2.0.0a1-py3.8.egg/plone/rest/service.py\", line 22, in __call__",
" return self.render()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/services/__init__.py\", line 19, in render",
" content = self.reply()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/services/types/get.py\", line 114, in reply",
" return self.reply_for_type()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/services/types/get.py\", line 136, in reply_for_type",
" schema = get_info_for_type(dtype, self.request, portal_type)",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/utils.py\", line 303, in get_info_for_type",
" schema = get_jsonschema_for_portal_type(name, getSite(), request)",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/utils.py\", line 253, in get_jsonschema_for_portal_type",
" return get_jsonschema_for_fti(",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/utils.py\", line 217, in get_jsonschema_for_fti",
" properties = get_jsonschema_properties(",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/utils.py\", line 177, in get_jsonschema_properties",
" properties[fieldname] = adapter.get_schema()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 89, in get_schema",
" schema.update(self.additional())",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 286, in additional",
" info = super().additional()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 277, in additional",
" info[\"items\"] = self.get_items()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 266, in get_items",
" return value_type_adapter.get_schema()",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 89, in get_schema",
" schema.update(self.additional())",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 437, in additional",
" \"schema\": value_type.get_schema(),",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 69, in get_schema",
" \"type\": self.get_type(),",
"",
" File \"/home/kitconcept/.buildout/eggs/plone.restapi-8.13.0-py3.8.egg/plone/restapi/types/adapters.py\", line 93, in get_type",
" raise NotImplementedError"
],
"type": "NotImplementedError"
}
Yeah no 
that would be a big change to accomplish what is essentially a routing problem...
In the interest of trying to keep things simple for newcomers (to Plone, or to Volto... as is my case), could we have everyone continue to report them to the Products.CMFPlone repo but then (if only) we could move the issue to the appropriate repo...
Agree. That was just an opinion. Reporting issues on products.cmfplone and then linking to desired repo(s) could be the easiest approach that can be adopted in the earliest.
Quoting https://plone.org/support/bugs:
If you think your bug involves a core component of Plone, check to see if that component has its own repository at Plone Foundation · GitHub. If it does, use the component's issue tracker to submit your bug report. If the component does not have its own repository there, submit your bug report in the catch-all CMFPlone tracker on GitHub.
What I usually saw in the recent years is that:
So I would keep this relaxed attitude