Public locations for food distribution (Food-share points, open fridges)

[tiltec]

These are places where people can exchange food. Many foodsaving groups have this, sometimes as permanent places (public fridges), sometimes as pop-up events (e.g. Monday 10:00 regularly).

They should be per group, and publicly visible. A small to medium-sized backend task, and many people would like to have this feature.

Frontend: should show share points on the public map, enable group members to create and modify share points for their group.

Backend: design a share point model, serializers and endpoints Should include the following features:

• name, description, location
• group it belongs to
• optional: times of pop-up events

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events? But that's just a very first idea.

[djahnie]

This is very similar to stores, so we could think of ways to reuse existing code. Maybe generalize stores as location & description and pickup dates as events?

That sounds very reasonable to me and since I was just talking about this with Stefan from Taiwan I'll add my two cents:

• The marker on the map should look differently from the store's marker, e.g. different color.
• Pick-up dates are either not needed for the FSP or can be reinterpreted as cleaning times.
• In the group view the FSPs should be displayed above or underneath the stores in the list on the right. They could be seperated by a horizontal line and introduced by a headline saying 'Stores:' and 'Food-share points:' respectively.

When there's communication possibilities:

• In the detail view of an FSP the users should be able to post comments for when they brought food there.
• In the group view a new tab called 'Food-share points' could be introduced, that leads to an overview page where the newest messages from all FSPs, as well as upcoming and still open cleaning shifts are displayed.

[tiltec]

From foodsharing Poland

it would be very helpful to have an 'open fridge' pins on the map (i'm not sure about the english name, i'm talking about those places where we leave food for others to take). for now we will probably use blue pins, originally for 'negotiating' stores

[tiltec]

This seems to become more relevant. There have been related ideas such as scheduling hangout locations on karrot (ask Bruno) and marking locations to drop off food (Essen für Alle?).

[tiltec]

It's unclear whether we should generalize stores and pickups or add new data structures to handle locations and events.

[tiltec]

Would be useful to collect the requirements from groups:

• what should be publicly displayed and what should be internal?
• do we need event management or is a simple description enough?
• should there be a conversation feature attached (e.g. public wall)?

It would be good to write a post on the community forum about this and gather feedback.

[djahnie]

I wrote a post. You find it here.

[nicksellen]

So, I split it into two considerations:

1. implementation (whether to make stores/pickups generic)
2. user interface

I will share a few thoughts regarding 1 here, I think 2 can be discussed a bit more on your post, but can sort of happen in parallel.

I have the feeling that making stores/pickups generic is the way to go. Loosely store = location (but maybe the word "stores" is actually general enough anyway), and pickup = event (or "activity", or something else).

The post mentioned a few types of patterns we should consider, I would consider those as 3 different concepts:

1. places you can drop-off and pickup-up food (e.g. public fridges/shelves)
2. places you can drop-off food (e.g. charities)
3. events where the location is not dedicated for that purpose (e.g. distribution events)

For 1 and 2 the "store" is obviously the location, the "events" part of it is about related tasks (cleaning up, meetings, etc.). For 3 the event part of it is the main thing, and the location kind of secondary, so I would consider either: 3a. make "events" not need to be connected to a seperate "store/location" entry, but just have location information directly on them. 3b. have additional "locations/stores" that would not be really shown on the map by default (as you can only do anything there if there is an event) <--- I would probably favour that one

So, "stores/locations" might change in the following way:

• possibly change the name
• have a "type" field, something like:
  • sharepoint
  • dropoff
  • shop
  • cafe/restaurant
  • (the last two we don't bother distinguishing, but maybe it's useful whilst we're adding types!)
  • venue (or "transient") - would not be shown on map by default

then, "pickups" might change in the following ways:

• change the name to something more generic (event, activity, etc)
• have a type field, with maybe:
  • pickup
  • dropoff
  • event (seems a bit general, maybe it's just "other")
• ... maybe the types are limited depending on the store/location type, but maybe just leave it simple

Some things that would need changing/thinking about:

• email notifications would have to either filter just pickups, or maybe send notifications about other types of events too
• feedback is currently connected to only pickups, doesn't make sense for other event types (unless people want to record how much is dropped off too...)
• for pickups, we consider them not really ok unless they are full, but other event types are different
• would like to avoid endless if/switch statements from having different types

As I said before, in this I'm not considering anything about how they would be represented in the UI (which seems to range from completely seperate sections/names, or kind of combine them a bit more and have filters).

Would welcome more thoughts on this :)

[tiltec]

Great that you tackle this! Your plans seem reasonable, generalizing stores/pickups seems the way to go to reduce code duplication, but will probably increase complexity - it seems hard to avoid endless if-else switches.

Another way to go would be to have locations and events as abstract base models, and different actual models per type. Some common functionality should be shared, e.g. recurring event logic.

Some type of locations should be public (public fridges), others internal to the group (shops), other don't matter but are of less interest to the public (drop-off). Public information might be more limited than internal information: some events should be public (public fridge opening times, distribution events), others internal (clean up, meetings).

There could be a follow/unfollow membership per user and location, to keep users up to date about new or changed events (using the work-in-progress on-site notifications).

[nicksellen]

I got quite put off the django model inheritance stuff before. That seems to complicate things quite a lot in an abstract way. Anyhow, I think the next step here would be playing around with the code a bit and see how various approaches feel.

My goal would be to avoid lots of if/else, possibly by abstracting behaviours into seperate classes that can handle different types - so instead of 5 methods each with if/elses for each type, have a handler for each type with 5 methods each. This is still sort of inheritance (as the handler classes would adhere to an interface), but avoiding some complexity by not coupling this with the database/model inheritance. But yeah, needs some research and play :)

[nicksellen]

... on the other hand, totally separate models for each type of thing are the simplest thing conceptually. It might be that it depends more on the UI approach more than I thought too, whether the different types are more or less seperate things.

(I also have in mind (more with dreaming hat on) that it nudges it closer to being more suitable as multisharing/general type of platform if it's possible to add types relatively easy)

[taistadam]

Some UI ideas.

Open questions:

• are there events for drop-offs?
• how to prioritise pick-ups from events and distributions?
• color scheme to differentiate the activities instead of space-taking title?
• a better idea for a word rather than activities? "happenings"? "stuff going on you might want to join"?

[brnsolikyl]

Although the discussion about the feature itself and the reflections about implementation that Nick brought up here are obviously connected, I think we should open a new issue about making generalizations and possibly refactoring the backend. This can be especially interesting when trying out Karrot for new purposes, like organizing Bike Kitchens, as we mentioned on another post. The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

Being able to define locations and events as public or internal are applicable to different use cases, I believe. I can say that for Solikyl, having food-share points as public would be quite useful.

[nicksellen]

The broader classes of "location" (or "places", one might call it) and "event/activity" makes sense for this Bike Kitchen use case as well, whereas types would be something like "working shifts", "meetings" and "pickups", and that's a matter to be defined in the UI.

For me the question of where to define the types is more open than that, a few options/considerations:

1. could be defined in an instance configuration file on the server (so a whole instance has a certain set of types)
2. could be defined by a status field in the code/db (as we currently do for things that have multiple types)
3. could be defined in the UI per group by anyone that has editing rights

My default would have been to go with option 2. On the basis that:

• this is already our approach for managing different things that have the same representation in the code/db (e.g. conversation types, history types)
• it's flexible enough to add more, but inflexible enough that we have to think about the specific needs of each type

My concern with exposing the generic-ness in the UI (option 3) would be that different types might have different needs in terms of notifications, emails, UI, etc. For example it's much more important to notify people that a pickup has no collectors than a public event has no attendees.

It could be possible to implement these things as options when creating types, but then it also starts to get very complicated for groups that need something simple without configuring lots of options. It also would make stats reporting less meaningful if different groups did not have the same types (I find it much more interesting/useful to know if pickups are happening than if general meetings are).

The other aspect is branding/clarity kind of perspective - having a tool/site focused on saving food is much much clearer than a general tool that can sort of do many things. This doesn't have to be singular at the software level, but maybe at the deployment level, e.g. karrot.world to stay food saving focused, but maybe bike.kitchen is all setup and branded for bike saving. It might be each use-case/purpose have very different community needs too.

So, in general I am all for generalness and flexibility, until it comes at the cost of clarity and purpose.

[nicksellen]

We also have https://github.com/yunity/karrot-frontend/issues/359 which maybe can be reopened :)

[brnsolikyl]

Good points, Nick. Let me see if I understand. The status field on the code that you refer to on option 2, is that the status of the store as "Cooperating", "Negotiating" or "Inactive"? If yes, then I see what you mean and I believe that's a good approach. It's kind of how I played with the Karrot when we first put it up as a test-piece. Our plan is to make our own deployment, branded for the bike kitchens (and then obviously we'd like you developers to get involved ;), but we discuss that anytime soon). The question of having a generic tool for team self-management, not branded for specific purposes, can still be interesting and relevant for the future so it'd be good to keep the discussion open elsewhere.

[tiltec]

I experimented with public places in #1449, which allows to define a public description in a place. Then the place becomes a hybrid, it has a public part and an internal part, with the location and the name shared between them.

Some comments on this:

• cooperation status seems useless, pickups too
• a public fridge might need a public wall (which in turn might need moderation)

[github-actions[bot]]

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!

[tiltec]

As this issue had a lot of semi-related discussion, this could use an overview in a fresh issue.

[github-actions[bot]]

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!

[brnsolikyl]

This one I have a really hard time to let go of. hehe But probably it's better like Tilmann wrote above, to start fresh? There's a lot of discussion that is not up-to-date anymore.

[nicksellen]

I think this has two clearly distinct aspect to it:

• different place types - we have a good concept of how this can work now, based on how activity types are done (new issue -> https://github.com/yunity/karrot-frontend/issues/2244)
• public interaction - this needs a lot more conceptualization to understand how the interaction should be with these outside users (idea is to create a forum post to discuss this more widely)

[github-actions[bot]]

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!

[brnsolikyl]

I think this has two clearly distinct aspect to it:

* different place types - we have a good concept of how this can work now, based on how activity types are done (new issue -> #2244)

* public interaction - this needs a lot more conceptualization to understand how the interaction should be with these outside users (idea is to create a forum post to discuss this more widely)

I agree, and also there's a bunch of outdated discussion in here, so I will close this issue.