Currently the plone.org/download page has a link to "all Plone add-ons" and to "all Plone 5 add-ons"; these are queries run on pypi.python.org, where eggs are released to (this is where you get the name of the egg you put into buildout.cfg).
About 3.5 years ago, the Plone community started a project called paragon.plone.org to try to evaluate objectively the "best" add-ons for Plone. The project died because it ended up being too much work. That is why plone.org/download has a (lame) list of recommended add-ons... it was a first cut created by a small group of people, and it's no longer up to date.
Alternatively, rather than doing pure coding, you could come up with a more streamlined system or process for identifying good add-ons, something that is better than what we tried with paragon.plone.org and yet that doesn't depend on thumbs up/down ratings as they used to on old.plone.org (people would not bother to log in to register their thumbs up or down on a particular add-on).
I don't know if it would fare the same fate as "two thumbs", ie too much effort to login and vote, but I have an alternative idea with the following benefits
you don't have to find all the add ons you like plone.org and click like for each one
doesn't rely on download stats from pypi which are somewhat meaningless.
doesn't require you run buildout on your production instances
gives some more useful stats like which plugins are used together, which plugins are compatible with each other or with a given plone version.
could have a gamification motivating feature of listing who manages the most plone sites. With two thumbs your effort wasn't personally identifiable which could have reduce its uptake.
doesn't rely on subjective opinion.
The idea is that plone.org would invite you to create a small zmi python script with same pasted code. This code does an audit of the installed plugins and creates a POST form which sends the data to plone.org. You would then have some options of blocking the site url from appearing on plone.org and some of the plugins (in case they are sensitive). You would have to run this once per site you manage but only once after you first create it, or do any major upgrade.
Then of course plone.org can use these stats to sort plugins by "most installs" as well has have badges which indicate the plone version is used on and what other plugins this is commonly used with.
Ah yes the phone home idea... I'm in favour as long as an admin can disable it (opt out or at least an installer question that asks them to enable it to help us).
That would provide good data.
However, the work on the add on listing needs to proceed so we can at least display Plone add ons on Plone.org
@tkimnguyen read it. it's not the same phonehome you are thinking of. The phonehome plone addon idea doesn't really work because it's actually more work and more risk to install a new addon in an existing production site than is worth to give ploneorg that data. Plus everyone is concerned like you are that you won't have control of the data transmitted.
The process I outlined avoids both of those problems.
Unless we do come up with a way to keep plone plugins on plone.org up to date and relevant (ie suggesting the most popular?), is it worth it? Won't it just degrade into a mess like before? or is the plan to just show what pypi shows?
Here is what I have understood about the idea so far, Please correct me if I am wrong.
The purpose of ploneorg.addonlisting is to create add-on listings for Plone.org in a visually engaging manner. Allow highlighting of curated add-ons(editor's choice) , simpler/cleaner descriptions of add-ons with relevant tags,version compatibility, and automated retrieval of data from pypi.python.org, sort by rating/recommendation.
Initial version of this at GitHub - plone/ploneorg.addonlisting: Add-on listing for Plone.org
2)In order to get data about the installations of the addons, compatible versions and other such data, a zmi script can be invoked by the admin. It would send POST data to the Plone.org.
3)Some examples for inspiration that were referred in the above mentioned discussions were Extending Pyramid, Odoo Apps | Odoo Apps Store.
I have a few doubts, though.
Where can I learn more about zmi python scripting in Plone?
2)When and how would the admin be invited/ reminded to invoke the script?
3)To quote from the discussion at Plone.org add-on listing - #5 by zopyx,
would the script help in getting these extra statistics/data as well?
@pavithirakc Just to be clear the ploneorg.addonlisting and phonehome (via zmi script) ideas are different. I'm not the mentor for this project so you don't have to listen to my input.
addonlisting intends to take download stats and compatibility info from pypi. Pypi download stats depend on things like how often versions are released and how often people run buildout I suspect. Compatibility information on pypi is only up to date for people who remember to update the classifiers. But people could be reminded more often if its more visible.
good question. Possibly whenever they view addons they can be reminded to add the sites they own. Possibly there could be a mail campaign once a year to rerun to ensure the data is fresh. Otherwise decommisioned sites would still be in the data.
I think phonehome stats do give us an indication of it its quality in that it tells us that is good enough to be used in X number of sites. Neither pypi or phonehome tells us about tests or being translated. Pypi does give an indication of maintaince however via last release date and frequency of releases which would be useful to include. But then certain kinds of plugins don't require frequent updates.
You could complete ploneorg.addonlisting so that we can get it onto plone.org - I think that would be a nice feather in your cap, to be able to point to something you helped write that the main Plone community site is using in production. However, on its own it may not be a very demanding project; it will require attention to detail and some design work, if I recall correctly (@Alexander_Loechel can provide more direction).
If you can come up with a solution to the stats problem, that would be nice for the community as well. But again, is that a GSoC-worthy project? It's less about coding than it is about human problem solving, if we go with the "human action is required, even periodically" approach.
Or you could plan on trying to use some "no human intervention required" approach, which probably shouldn't rely on pypi statistics, but should rely on some sort of (optional?) reporting (periodic or maybe one-time) from each Plone deployment.
To answer your questions:
ZMI Python scripting means going into a Plone site's Management Interface, e.g. http://localhost:8080/Plone/manage_main and adding a "Script (Python)". These use Restricted Python so imports and other possibly harmful things are not allowed; however they probably can do what @djay suggests.
That's a nice thought: add a viewlet to the Add-ons control panel. It could show some interesting stats on the installed add-ons based on what has already been gathered centrally; it could also include a button to "Help Plone by sending anonymous non-sensitive information about the add-ons on this site".
IMO I'd like this feature to be part of Plone core. Or in the unified installer, and a decision on whether to make it an opt-out or an explicit yes/no.
Hi @tkimnguyen. Other ideas that were of interest to me(but not listed in the final list of GSOC ideas) were an e-commerce add-on for Plone (bda.plone.shop enhancements), integration of Plone with Discourse forums and an enhanced theming editor that lets you drag & drop elements around, a la wix.com. Do you think any of them would be GSOC-worthy? If so, would they be given equal priority as the other ideas already listed. Also, would it be difficult to get mentors for these ideas?
@pavithirakc as I am the current author and maintainer of that ploneorg.addonlisting package / project, you could also work with me on improving it and het it ready.
I'm not sure how much work bda.plone.shop needs; @jensens and @agitator would know more.
Plone & Discourse integration would be nice - we might even end up using such a thing on Plone.org
Drag & drop in the theming editor would be pretty awesome, and of these three ideas, would definitely be GSoC material in my opinion.
Given that I added those ideas to the list, unless someone else wanted to step in I could be a mentor for them. For the shopping cart, though, @jensens or another Blue Dynamics Alliance member should be the mentor.
I don't think the ideas listed at Google Summer of Code are the only acceptable official ones, but I'm not closely familiar with the rules. @cewing would know.
Hi @Alexander_Loechel. Plone add-on listing is definitely one of the ideas that I am interested in. I am planning to apply for GSOC this year and would like to work on a coding-intensive idea proposal that would need 3 months of development time. @tkimnguyen had mentioned that completing ploneorg.addonlisting in itself may not be a demanding project that would get accepted in GSOC. What do you think about it? Is it possible for the idea to be expanded to result in a plan of action for 3 months? Or do you suggest that I go ahead with the other ideas that were of interest to me?
Plone Add-on listing might not be a project for intensive 3 Month alone, but it is just one of several plone.org Addons that need some love that help the Plone community in Total:
Thanks for the response @Alexander_Loechel. I would like to work on the above mentioned GSOC idea. I am currently going through Plone docs on add-on development. Please let me know about what I could do next.
One of the ideas on the ideas list is "Your Own Idea", which I've always read as "feel free to propose any project that interests you". The idea here is that working on code you are invested in is the best way to ensure success. If you have ideas that are not on the list, we welcome your proposals.
I would temper that by saying that you should investigate if any of the mentors listed (or any community members who are not listed) would be interested in mentoring your idea. We do have a pretty good idea of what will and will not work for Plone.
What about combining the vulnerabilities checks and the stats.
Why?
Because to check for vulnerabilities you need to compare the packages and version you have installed with the packages versions in a central vulnerabilities database. So we would have at least good stats about the usage of Plone out there. We should not save to much data on plone.org here, because we don't want to create a database which can be used to find out how has vulnerable packages. But if we don't save the ip's and url, but just stats about packages and versions it should be fine.
But on the other side the control panel in Plone could now tell the admin if some Plone version needs an upgrade. It could also extended to add-ons, which i would recommend.
With this in place, we could also have the needed stats for a add-on listing on plone.org and also good s stats about, the Plone installations out there.
I don't see any problem here, but maybe i miss some thing.
Feedback welcome, any thought about that?
@MrTango nothing wrong with the idea in theory but even with motivation knowing if your site is vulnerable or not, it would still take a lot of time to get installed on a reasonable % of sites. To even get it installed on most new sites it would likely have to be in the core. This plugin already exists for example - https://pypi.python.org/pypi/plone.phonehome
Also, most maintained sites have support staff who already are aware of security patching. Those that aren't, aren't likely confident enough to install this plugin.
So I think it would take sometime to get meaningful data. Hence why I suggested the temporary shortcut of a manual process anyone with admin access could do without having to touch buildout. But I guess it could also give a warning about vulnerability status too.
