How to define Package rating / popularity

Dear community, this RFC is not directly in relation with the development of Neos. The Neos project need to do more promotion for the existing vendors that create packages for Flow & Neos. We have different plan, and an official announcement will be done later.

I’m really interested in what kind of metric help you choose a Package ? Feel free to add you bullet point in this feed, I will try to group every thing and try to sort them to see how we can build an algorithm for package recommandation and value metrics are valuable for you.

Collected metrics

  • downloads / average daily|weekly downloads
  • last updated / update frequency
  • documentation
  • code commenting
  • flow & neos version compatibility
  • forks
  • referenced by

Community metrics

  • i use this package
  • claim this package / vendor


  • downloads
  • last updated

I recently stumbled upon - maybe that “formula” helps?

1 Like
  • documentation / code commenting
  • as @stolle said “last updated” is definitly an indicator - maybe not only “last updated” but also “update frequency” in general (e.g. in respect to upcoming neos-releases with core changes)?

I also see last updated or update frequency together with documentation as the most important things.

Just be aware that such metrics could also have the opposite effect in case it’s a well done and single purpose package. It wouldn’t necessarily need to be updated regularly nor forked.

Couldn’t it just be optional which metric to sort by? With weekly downloads as default or something. Also it’s probably more useful with people actually rating packages than trying to calculate some number. Of course that depends on users being logged in.

Full ack, it’s a dangerous topic :wink: but i need input from more people. At some point we will have this “claim my package feature”, I also see something like “I use this package” pretty important.

Every metric need to be balanced, the formula from phppackages is a good start.

Different ranks like “trending”, “most stars”, “most downloads”, … could also work.
But in any case we should probably include some kind of time-factor or we will end up with a static top-x list (a little bit offtopic but still somehow related and intersting video:

1 Like

This one is pretty risky because of Jenkins and friends :wink:

@aertmann: Good point. In cases updates of a package may rarely apply… Maybe add something like a monthly/quarterly “author-ping”? Just to let interested guys get an idea whether the author of the package and the package itself is still “alive” and whether the author may be available for questions or whatever.

Just a small update after our hangout with @sebastian, for the initial version we will choose the following solution:

  1. Without search query: Filter by last update time, show dev and stable package
  2. With search query: use the function

We decide to not use the last update time to sort search result, because it’s a risky topic, we prefer to promote package activity, like download, fork, start, … and we will try to get those metric from package. The last update time, will be visible in the search result and in the package detail page.

We will normalized package version, like this:

Based on those value, we can build filter and range query for advanced search.

We decide to keep the scoring function simple for this first step, and iterate on top of that.

1 Like

A nice link by @dimaip: just for inspiration about package quality metrics:

nice one, the algorithm is explained here

Look like packagist hide not updated packages from the search engine, but I can not found more details on this.