There has already been several discussions on this. There isn't an official listing and its not a simple thing to solve. The pypi list is as official as it gets but people forget to update the categories in setup.py so it's not entirely accurate. If someone wants to step up and find the plugins and maintain the list then I'm sure it would be welcome.
@hvelarde we need to move forward, so it would be better to put energy into improving the new downloads section. I think we are going to create an Add-On content type and allow "well-maintained" add-on listings to be submitted and reviewed for publication. Periodically we will expire any that have not been updated in some time. That will give add-on creators and maintainers incentive to keep the listings updated.
some (me included) expressed concerns about how that list was made and tried to offer alternatives that were not accepted; somebody even mentioned that trying to maintain that list as an static HTML file in GitHub when we have a full, enterprise-grade, CMS was really a very bad idea. I think we already are aware of that because we are talking now about an add-on content type, which is BTW what we had before.
if you have a good argument on why not adding a link to the old list of add-ons, I want to read it; but arguing about it while doing nothing but wait, will not help in the mean time.
I expect that this will not work. As all of Plone, Add-Ons is volunteer work. Most Add-Ons are likely developed based on a specific need by its author and published (only) to give something back to the community. Few authors actually gain something by the actual use of their Add-Ons. Therefore, "incentives" like the above may be counter-productive.
I suggest to develop Add-On descriptions where important information can be provided not only by the authors themselves but also by Add-On users. My main use case looks like follows: an Add-On author is still happy with Plone 4; a user of his Add-On has already moved to Plone 5 and found it compatible.; he should be able to attach a note to the Add-On description "works with Plone 5".
another problem with this is that then we will have yet another place to maintain our add-ons and we will finish with the same issues as in the past: people stopped uploading their add-ons to plone.org to reduce the administrative overhead of it.
we need to think more about this issue before addressing it.
We maybe could do a PR on each individual package to add trove classifiers
"Topic :: Software Development :: Libraries :: Python Modules"
"Framework :: Plone :: 5.0" and/or "Framework :: Plone :: 4.3"
and ask for a new release from the package maintainer?
It seems this is not an easy task, but this is a very important ones, more than thinking at Plone 5.1
I've a couple of "power user customers" that are scared about the current add-ons situation and I need to reassure them every time (there's people that think Plone 5 can't still work with LDAP).
Links to pypi search are useless... 70% of packages listed are Plone core.
I think we need to take a direction. Now we are talking again to develop an add-on/content type but this approach has already been taken by paragon.plone.org... and (for reason I don't know) it was dropped.
Whatever direction we take, the list of add-on must not be (only) under the control of the product's developer or we'll end in the same swamp of old plone.org (deprecated information, missing add-ons, ...).
The static HTML list managed by pull request is not too bad IMHO, but the layout must be enhanced someway... we need sections with structured additional information like a categorization (it's an end user add-on or a developer targeted ones?) but, more important, Plone 4/5 compatibility.
As pull requests are probably for developers, we can also allow simple issues for users that ask for adding the add-on X or Y. We can take advantage of github issue template for this, asking the user to fill basic information needed.
Can a new "add on" content type work in the same way? Maybe, but we need a very open workflow for this (a large group of plone.org users must be able to update those contents).
In that case, can't we use the paragon.plone.org ones? I think it was developed TTW.
The Munich planning sprint which starts Friday is one place this discussion is scheduled to take place (somewhat in person, but remote participants are welcome). There is also the Castle sprint, in September, and then of course the Boston conference sprint. Since I know I will be at the Boston conference I vote for having this issue argued (with shoes pounded on table, gnashing of teeth, rending of clothes) and finally coded up & implemented there.
I like the look of it and would be happy to implement that on plone.org. The harder question is which add-ons to list, how to get and maintain that list (manually or by script, with or without human input such as voting), and what information to put in each listing and how to keep it current.