Collecting stats of popular Recipes #555

New Issue

basebuilder · 2024-01-26T11:31:24Z

basebuilder commented

2024-01-26 11:31:24 +00:00

Copying in a quote from @decentral1se in #553

Just to note, I don't think we have no way to know what is "popular" atm.

From a general perspective of feedback loops and projects self-awareness I think this might be a useful metric to have. At least I would be curious to know. I think it's also helpful to drive interest and adoption in Co-op Cloud Recipes.

Without knowing anything about the server infrastructure or inner workings of abra- is it possible to parse some server logs of HTTP requests at a per recipe level? Or is that data not transmitted to Co-op Cloud's servers and only exists within Abra and the third party repos involved in the Recipe?

Obviously there are privacy implications depending on implementation to recording this data (if it's not already in Co-Op Cloud's server) .

Copying in a quote from @decentral1se in #553 > Just to note, I don't think we have no way to know what is "popular" atm. From a general perspective of feedback loops and projects self-awareness I think this might be a useful metric to have. At least I would be curious to know. I think it's also helpful to drive interest and adoption in Co-op Cloud Recipes. --- Without knowing anything about the server infrastructure or inner workings of abra- is it possible to parse some server logs of HTTP requests at a per recipe level? Or is that data not transmitted to Co-op Cloud's servers and only exists within Abra and the third party repos involved in the Recipe? Obviously there are privacy implications depending on implementation to recording this data (if it's not already in Co-Op Cloud's server) .

decentral1se commented

2024-01-26 23:24:30 +00:00

One thing we discussed before was #307 - knowing there are collective(s) actively commited to maintaining the recipe means it's reliable (and therefore popular?). This would also be simple to implement technically. Unsure how we'd shape process socially to keep up with who is maintaining, stopped maintaing, inactive etc.

One thing we discussed before was https://git.coopcloud.tech/coop-cloud/organising/issues/307 - knowing there are collective(s) actively commited to maintaining the recipe means it's reliable (and therefore popular?). This would also be simple to implement technically. Unsure how we'd shape process socially to keep up with who is maintaining, stopped maintaing, inactive etc.

👍 1

basebuilder commented

2024-01-28 12:01:40 +00:00

knowing there are collective(s) actively commited to maintaining the recipe means it's reliable (and therefore popular?).

While correlated to maintenance, I think it is also a different signal. A useful recipes will be used by 10x or 100x the number of ppl maintaining it and that number will in theory grow to Nx. But knowing a recipe is currently maintained would definitely be a good a signal for which to feature on the homepage and search.

> knowing there are collective(s) actively commited to maintaining the recipe means it's reliable (and therefore popular?). While correlated to maintenance, I think it is also a different signal. A useful recipes will be used by 10x or 100x the number of ppl maintaining it and that number will in theory grow to Nx. But knowing a recipe is currently maintained would definitely be a good a signal for which to feature on the homepage and search.

👍 1

basebuilder added the

recipes.coopcloud.tech

label 2024-02-06 11:00:56 +00:00

basebuilder changed title from ~~Collecting stats of popular Recipes~~ to Recipes: Collecting stats of popular Recipes

2024-02-06 11:01:05 +00:00

3wordchant commented

2024-02-10 20:50:25 +00:00

Agree that this would be super useful if we can find a way to do it.

Sadly Gitea doesn't yet seem to support Dockerhub/Github-style "how many times has this repo been pulled" stats: https://github.com/go-gitea/gitea/issues/7392

And, even with a high debugging level, the app container doesn't output fetched URLs in logs 😞

Agree that this would be super useful if we can find a way to do it. Sadly Gitea doesn't yet seem to support Dockerhub/Github-style "how many times has this repo been pulled" stats: https://github.com/go-gitea/gitea/issues/7392 And, even with a high debugging level, the `app` container doesn't output fetched URLs in logs 😞

decentral1se changed title from ~~Recipes: Collecting stats of popular Recipes~~ to Collecting stats of popular Recipes

2024-03-27 06:20:19 +00:00

basebuilder commented

2024-04-02 08:18:00 +00:00

We could encourage Operators to have a manual policy of clicking the Star button for every recipe they are using and have deployed.

This is obviously a slightly different signal from git clone ... but it has these attributes:

Pros

Is manual, intentional action
Removes any "noise" from bots, random clones, etc...

Cons

Requires a user account on the Gitea
Requires effort of Operator (albeit minimal)
Not guaranteed explicit

Looking at the Gitea API: repository, this data is accessible:

"stars_count": 0,

There is also Watch data, which could be used instead / in addition

"watchers_count": 0

We could use this data as a heuristic on the Recipes page

We could encourage *Operators* to have a manual policy of clicking the `Star` button for every recipe they are using and have deployed. This is obviously a slightly different signal from `git clone ...` but it has these attributes: **Pros** - Is manual, intentional action - Removes any "noise" from bots, random clones, etc... **Cons** - Requires a user account on the Gitea - Requires effort of Operator (albeit minimal) - Not guaranteed explicit Looking at the [Gitea API: repository](https://docs.gitea.com/api/1.20/#tag/repository/operation/repoMigrate), this data is accessible: ``` "stars_count": 0, ``` There is also `Watch` data, which could be used instead / in addition ``` "watchers_count": 0 ``` We could use this data as a heuristic on the Recipes page

nicksellen commented

2024-04-02 09:48:40 +00:00

I think operators are not necessarily participating here at all, this feels more behind-the-scenes, whereas an operator should be able to use co-op cloud + recipes without interacting with any of this layer IMO.

An idea to throw out: a recipe that collects stats about a server, so:

you abra app new usage-stats
it runs periodically and phones home with the stats
framed as "help us out with usage data"
stats could be just "which apps/recipes are running", but also perhaps more detail too

I think operators are not necessarily participating here at all, this feels more behind-the-scenes, whereas an operator should be able to use co-op cloud + recipes without interacting with any of this layer IMO. An idea to throw out: a recipe that collects stats about a server, so: - you `abra app new usage-stats` - it runs periodically and phones home with the stats - framed as "help us out with usage data" - stats could be just "which apps/recipes are running", but also perhaps more detail too

basebuilder commented

2024-04-02 10:59:37 +00:00

I think operators are not necessarily participating here at all, this feels more behind-the-scenes

Well, I think having operators be slightly more aware and involved in the recipes they are relying on was one aspect of my idea. Also because it just requires clicks. Not much code development.

Your idea does sound like a nice approach though 😄 👌 by my looking around, this sub-command abra app new usage-stats would be entirely new feature to be developed. Perhaps it would maybe be semantically better as:

$ abra recipe usage-stats <recipe>

And then the outcome of this command which could then be submitted to a CC analytics server would be:

{
  "recipe": "nextcloud",
  "deployments": "3",
  "versions": [" 3.1.0+25.0.1-fpm", "3.2.0+25.0.4-fpm"]
}

This could also be prompted on a per-app-installment during setup:

$ abra app new nextcloud -S
Would you like to send usage stats to Co-op Cloud
 - Automatically
 - Manually
 - Never

> I think operators are not necessarily participating here at all, this feels more behind-the-scenes Well, I think having operators be slightly more aware and involved in the recipes they are relying on was one aspect of my idea. Also because it just requires clicks. Not much code development. Your idea does sound like a nice approach though 😄 👌 by my looking around, this sub-command `abra app new usage-stats` would be entirely new feature to be developed. Perhaps it would maybe be semantically better as: ``` $ abra recipe usage-stats <recipe> ``` And then the outcome of this command which could then be submitted to a CC analytics server would be: ``` { "recipe": "nextcloud", "deployments": "3", "versions": [" 3.1.0+25.0.1-fpm", "3.2.0+25.0.4-fpm"] } ``` This could also be prompted on a per-app-installment during setup: ``` $ abra app new nextcloud -S Would you like to send usage stats to Co-op Cloud - Automatically - Manually - Never ```

3wordchant commented

2024-04-02 13:58:13 +00:00

Your idea does sound like a nice approach though 😄 👌 by my looking around, this sub-command abra app new usage-stats would be entirely new feature to be developed. Perhaps it would maybe be semantically better as:

I think @nicksellen's proposal was for a new recipe, a daemon that sends these updates regularly, in which case I think abra app new is fine (by comparison with backup-bot-two, or swarm-cronjob, other handy utility apps which are deployed using recipes).

And then the outcome of this command which could then be submitted to a CC analytics server would be

Looks great

This could also be prompted on a per-app-installment during setup:

If it's a server daemon, how about during abra server add?

> Your idea does sound like a nice approach though 😄 👌 by my looking around, this sub-command `abra app new usage-stats` would be entirely new feature to be developed. Perhaps it would maybe be semantically better as: I think @nicksellen's proposal was for a new recipe, a daemon that sends these updates regularly, in which case I think `abra app new` is fine (by comparison with `backup-bot-two`, or `swarm-cronjob`, other handy utility apps which are deployed using recipes). > And then the outcome of this command which could then be submitted to a CC analytics server would be Looks great > This could also be prompted on a per-app-installment during setup: If it's a server daemon, how about during `abra server add`?

basebuilder commented

2024-04-02 15:16:32 +00:00

Oh 🤦‍♀️ I see...

... a recipe that collects stats about a server, so:

Lol. That is a very different angle than I imagined 🤣 but I see how it also works... 🤷‍♀️ ?!

I guess there is one thing to consider with either idea- which is fake reports. Probably not worth thinking about at this stage (famous last words).

Oh 🤦‍♀️ I see... > ... a recipe that collects stats about a server, so: Lol. That is a very different angle than I imagined 🤣 but I see how it also works... 🤷‍♀️ ?! I guess there is one thing to consider with either idea- which is fake reports. Probably not worth thinking about at this stage (famous last words).

Sign in to join this conversation.

No Milestone

No project

No Assignees

4 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#555