Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show group pickup statistics #355

Closed
tiltec opened this issue Feb 27, 2017 · 16 comments
Closed

Show group pickup statistics #355

tiltec opened this issue Feb 27, 2017 · 16 comments

Comments

@tiltec
Copy link
Member

@tiltec tiltec commented Feb 27, 2017

Update see here.


Original message:

The new /history endpoint can be used to display some statistics per group and per user.

On user page:

  • pickups done for each group (that the users have in common)

On group page:

  • pickups done per store
  • total pickups per group

Later on, the backend would provide some more statistics and aggregate them for reduced server load.
yunity/karrot-backend#253 will provide the weight of the food, so this could also be used for stats.

@tiltec tiltec added this to the Release 4 milestone Feb 27, 2017
@tiltec tiltec modified the milestones: Discussion (lesser priority), Current discussion (higher priority) Jul 2, 2017
@D0nPiano
Copy link
Contributor

@D0nPiano D0nPiano commented Jul 24, 2017

So far, I can think of:
Overall:

  • no. of groups
  • no. of stores
  • no. of members
  • no. of pickups
  • amount of saved food

In Groups:

  • no. of members (already displayed)
  • no. of stores (could easily be displayed)
  • no. of pickups
  • amount of saved food

Store:

  • no. of pickups
  • amount of saved food

User page:

  • pickups done for each group (that the users have in common)

...which of course there is no need to implement all of them 😉


@tiltec
amount of saved food waits for https://github.com/yunity/foodsaving-backend#253, but what about the overall stats? If we wanted to display them on the landing page, or on an extra stats page, would you just load the whole lists on users, groups, stores etc.? Or should there be another backend endpoint?

And also, would you create a seperated endpoint for Store: no of pickups and Group: no of pickups ? Or load it from the current history api somehow?

@tiltec
Copy link
Member Author

@tiltec tiltec commented Jul 30, 2017

Having a cumulated foodsaving.world stats endpoint makes sense, since anonymous visitors don't have access to the users and stores endpoint.

I would like to take some care that the stats make as much sense as possible, i.e. only showing the active users (at least one sign of activity per 2 months), only showing the pickups where people signed up to get the food.

I would deliver the group stats through either/or

  1. an additional stats field in GET /api/groups/:id/
  2. an additional endpoint GET /api/groups/:id/stats/

Similar for stores. (1) seems easier for the front-end, but (2) would make it clearer that these are not the group data, but something else. Would prefer (2) therefore.

@D0nPiano
Copy link
Contributor

@D0nPiano D0nPiano commented Jul 31, 2017

Would something like

group = {
id: 5,
name: StoreName,
stats: {
  pickups: 513,
  stores: 15,
  members: 20
}

..work for (1)? I think it would be clear that it's stats, without having an extra endpoint.

@tiltec
Copy link
Member Author

@tiltec tiltec commented Jul 31, 2017

Yes, that would be the structure of (1).

How would you handle updates? Currently we always send the whole modified group object back to the server via PATCH. Would make sense to only send changed fields back if we go for (1), which would make the frontend a bit more complex.

On the other hand, (2) would mean adding another service method and another resolve entry. Seems quite straightforward.

@D0nPiano
Copy link
Contributor

@D0nPiano D0nPiano commented Jul 31, 2017

Wouldn't it be fine if we keep the update function like it is, and the backend is just not updating the stats when getting PATCH requests?
I'm fine with either one of the versions though, and 2 definitely makes sense, too. And frontend wise it wouldn't be hard to implement either way...

@tiltec
Copy link
Member Author

@tiltec tiltec commented Jul 31, 2017

Yes, the backend doesn't have any problem if it gets more fields than expected.

@djahnie
Copy link
Member

@djahnie djahnie commented Mar 28, 2018

We collect statistics into influxdb, now it needs figuring out what statistics we want to show on karrot itself. We are yet unsure if we should let Django read from InfluxDB or write statistics into PostgreSQL.

@tiltec
Copy link
Member Author

@tiltec tiltec commented Jun 29, 2018

Silvia from Efa asked

Wenn ich auf den Betrieb gehe und mir dort das Feedback ansehe, dann finde ich oft nur das letzte Feedback, oder maximal das Feedback aus dem Monat.
D.h. auch bei der Menge, die insgesamt in den Betrieb gerettet wurde steht dann z.B. für Bäckerei Darmstädter nur 52 kg, vom 23.+27. Juni.
Dabei bin ich dort 2x pro Woche. Und es waren in diesem Monat bestimmt schon über 200 kg.
Könntet Ihr das so machen, dass die Mengen über den Monat und über das Jahr angegeben werden?
Das wäre uns eine sehr wichtige Funktion, damit wir Rechenschaft ablegen können.

I'll raise the priority of this issue, but details need yet to be figured out.

@tiltec
Copy link
Member Author

@tiltec tiltec commented Jul 10, 2018

Next steps:

  • analyze response time for store statistics endpoint (via grafana.yunity.org)
  • add some kind of caching, either via django caching infrastructure or by precalculating values in the database
  • make store statistics more prominent in the frontend (currently they are quite hidden on the feedback page)
  • add group statistics endpoint
  • add user statistics endpoint
  • add fancy statistics UI to frontend
@nicksellen
Copy link
Member

@nicksellen nicksellen commented Jul 27, 2018

@tiltec
Copy link
Member Author

@tiltec tiltec commented Oct 31, 2018

Group statistics ("kg") were requested by Foodsharing Warszawa again. Nick commented that our stats are probably unreliable because people might not give feedback or enter the wrong numbers. Janina says that the exact numbers don't really matter and we should publish them. I think we could publish a roughly rounded number ("more than 100kg" or "about 150kg") and show the number of feedback.

@djahnie djahnie changed the title Show statistics Show group pickup statistics Jan 30, 2019
@github-actions
Copy link

@github-actions github-actions bot commented May 12, 2020

This issue is marked as stale because it has not had any activity for 90 days, remove the stale label or add a comment on it, otherwise it will be automatically closed in 7 days. Thanks!

@github-actions github-actions bot added the stale label May 12, 2020
@tiltec tiltec removed the stale label May 12, 2020
@robxrocks
Copy link

@robxrocks robxrocks commented May 26, 2020

Hi,
If this issue is still open I'd like to help out with. I was looking for an OS Python project to contribute to and Karrot ticks all the boxes for me. Please let me know if I can go ahead.

@tiltec
Copy link
Member Author

@tiltec tiltec commented May 26, 2020

Welcome to Karrot @robxrocks !
We talked about this recently and we need more certainty about what would be most useful to implement. Our idea was to hold an "online design sprint" with users before we go on with this topic.

In case you are looking for some other issue to work on, you could join our team chat on https://chat.foodsaving.world, then we might find something Python-related for you :D

@robxrocks
Copy link

@robxrocks robxrocks commented May 26, 2020

Thanks @djahnie and @tiltec, I just joined the channel

@github-actions
Copy link

@github-actions github-actions bot commented Aug 25, 2020

This issue is marked as stale because it has not had any activity for 90 days.

It doesn't mean it's not important, so please remove the stale label if you like it, or add a comment saying what it means to you :)

However, if you just leave it like this, I'll close it in 7 days to help keep your issues tidy!

Thanks!

@github-actions github-actions bot added the stale label Aug 25, 2020
@github-actions github-actions bot closed this Sep 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants