Paragon vs ploneawesome

paragon.plone.org is a nice idea to get an overview of the most interesting Plone addons. But it will fail. There is obviously not enough community support, many interesting addons are missing, many awesome addons are not yet written and will have a hard time to get on the list, and I doubt a jury is able to make a fair and representative selection of addons.

Why not doing it like http://vimawesome.com/ ? Vim Awesome shows a list of the most popular vim addons on github. It might not be a fair selection, but the rules are much simpler: the addon with the most stargazer stars wins. It also features categories, so you can view the most popular addons of a specific category.

We could do the same, and we can do it automatically. We just have to search the github collective. For categorizing, we could encourage to add proper metadata to setup.py. We could encourage people to give Github stars or count the downloads on pypi. I think that could be awesome: http://ploneawesome.com/

I just had to register ploneawesome.com, because that domain is so awesome. If this idea gets some traction, I would of course hand the domain name over to the Plone Foundation.

I <3 the idea to show the "awesome".

Otoh managing another [domain|subdomain] again is overhead.

I'd really like to see it as plone.org/awesome
With the upcoming new plone.org this should be simple. We already have a service prepared fetching data from collective and plone repositories at github and from pypi on a cron-job basis. PR pending here:
https://github.com/plone/ploneorg.core/pull/31

It would be easy to expand this to fetch additional information like githubs stars or pypi's download number of other packages (iow: I can add it if this is wanted).

I'd also like to see a list of new releases with catgeory Plone on PyPI showing up automatically - addons only, excluding core packages. Latter is easy, because we already have a list of the core packages via github repo's names.

More ideas in my head!

What I cant (do not want to) do is the visual design of such a page. Help needed.

One of the goals of paragon was to make recommendations based on more than popularity... overall reputation, translations, documentation, upgrade support, longevity, test stability, etc. I'm not sure that is automatable. But you're right: we do need to kick it in gear and get going.

If you think there are still add-ons missing from the list, please submit them - I think the form should still work.

http://paragon.plone.org

I only just came across this concept of "awesome-x" listing.
Looks like there are already "awesome-django", "awesome-flask", "awesome-pyramid" and of course "awesome-python" listings:
http://awesome-python.com/#web-frameworks

Did the paragon project bring results, or is the hunt still on?

1 Like

I think to have a ranking of the add-ons is very important for newbies that want to begin with Plone!
And maybe one important criteria should be the quality of the add-on docs...
Me, for instance, I get lost... I've asked this in in another post, can someone help?
-> with Plone 5, are collective.dexteritytextindexer or collective.folderishtypes needed??
do they add some new feature/functionality to the P5 default content types?
Also, by the way, are there any recommended add-ons that extend or add important and/or relevant features to the P5 dexterity content types?

(I believe these are the type of questions a newbie will ask...?)

I've registered ploneawesome.com a while ago and wanted to create something like http://vimawesome.com/ ( https://github.com/divad12/vim-awesome ) which lists all repos in github/plone and github/collective, ranked for github stars or watches or pypi download counts.
But that's on my TODO list, I didn't start it yet because of lack of time.

IMO that would be a nice thing along the curated paragon site.

It would be better not to have another place to look for Plone related information...so let's avoid another domain

One issue I'm wondering about is why count the number of views on Github? Only developers will be looking at add ons there. Pypi similarly counts only downloads, not popularity of use, or the size of a site that an add on is used on.

Let's try to incorporate your thoughts into paragon, and let's kick paragon back in gear.

PyPI download numbers are broken since the beginning.
Ranking by Github stars...that's something for developers. If you focus on Plone users then other criteria are more important in addition to the fact that you need to distinguish between add-ons (providing visible additional functionality to Plone) and "internal" packages that are not of interest to Plone users.

-aj

Right, totally agree with @zopyx, that distinction is important.

By the way, I did not manage to install collective.cover in Plone 5:
/Plone5/buildout-cache/eggs/plone.app.stagingbehavior-0.1-py2.7.egg/plone/app/stagingbehavior/browser/configure.zcml", line 5.4-11.10
ImportError: No module named intid.interfaces

Maybe related to this??

2016-01-31 13:57:30 ERROR plone.app.iterate plone.app.stagingbehavior should NOT be installed with this version of plone.app.iterate. You may experience problems running this configuration. plone.app.iterate now has dexterity suport built-in.

Anyway, my time testing Plone is coming to an end... tomorrow a decision will be made for the new project, and unfortunatly the winner seems to be Drupal :frowning:
Plone is very good but right now is too much trouble!
Hope in the future to come back and see if things improve.

Are there other options?

We also might have a look at Django Packages and it's source code on Github.

Seems that already been some effort to create the Plone variant in 2005. See http://blog.aclark.net/2011/10/24/plone-first-class-python-citizen/
Unfortunately plone.opencomparison.org seems down.

I think Django Packages works great, especially the cross table comparison.

Plone 5 is clearly not listed as supported in collective.cover:

I would have to start adding more restrictions to packages to avoid people trying to install add-ons under Plone 5 until a clear support path is defined: collective.cover/setup.py at master · collective/collective.cover · GitHub

Yes, my mistake, but Plone and is ecosystem is just too much confusing, probably not for normal people.
I wonder how many developers actually know the insights of the Plone core??
Good luck, I will come back when there is a new major release, to see if things improve.

@ebrehault :

Regarding
https://github.com/collective/example.p4p53

" But anyway, if you inspect your page in your browser, you should see the 2 resources. "

No, I still don't see, but maybe my Plone install that is broken?
Anyway, thanks, but that does not matter anymore.

An update :slight_smile:

The https://plone.org/download/add-ons/popular-add-ons page, which you get to from https://plone.org/download , is one curated list that came out of Paragon v1.

You can recommend additions to the list by filing an issue at the new repo https://github.com/plone/paragon.addons/issues

Let's try this and see what happens.

To recap, we do not have reliable, meaningful statistics on which to base an automated ranking. Our attempt at a thumbs up/down manual voting on the old Plone.org did not have a good response (too sparse, not a good quality measure). What we have now is a good start with a promisingly workable process that incorporates human judgement.

The list mixes Plone 4 and Plone 5 addons. For example, collective.contentleadimage doesn't make sense in Plone 5, since this is a core feature of plone.app.contenttypes. Some of these plugins do not work in Plone 5. I think we need to clearly point out Plone compatibility.

3 Likes

I don't get is this short list taken into count from the long dead paragon.plone.org or not.
For example: I don't find a very common add-on like sc.social.like

We need to repeat the voting process on https://github.com/plone/paragon.addons ?

we can fix it using a simple table with Plone 4/Plone 5 columns and and a mark.

I told @tkimnguyen the same thing yesterday; I added a proposal:

"vertical markets" separation is a bad idea, imho.

  • who decides what are the verticals?
  • many add-ons serve multiple verticals
  • many sites/integrators won't recognize themselves as being in a specific vertical

and yes, that could theoretically be solved with tags instead of separate lists. Although tags describing what the add-on actually does would be much more helpful.

But then again, remember what happened to the old plone Product centre: nobody maintained it, nobody had any clue if any of the add-ons mentioned there would totally blow up your site and mix red socks with your white laundry. In end effect, that was useless.

So, paragon was an attempt to have a small, human-curated list. Yes, the paragon initiative failed, for multiple reasons. Still, we need something where (human) maintainability will be prime concern, above grand (technical) designs.

So: separating things into Plone4 and Plone5: totally good idea. But only if we can get the info directly from pypi, otherwise that will be a burden on whoever gets to maintain this site in a years time.

1 Like

the current list is a bad one as those are not the most popular add-ons by any measure; that list can only be valid by using real download statistics.

I can buy the idea of tags; now, trying to get the supported Plone versions from PyPI is by no means the only solution: classifiers can or can not be accurate, as already pointed here.