This was copied from this etherpad discussion: https://pad.disroot.org/p/future-of-foodsaving-tool/

*Discussing the future of the foodsaving tool
*
*Feedback for finished pickups
https://github.com/yunity/foodsaving-backend/issues/253
https://github.com/yunity/foodsaving-frontend/issues/159

Seems a nice easy thing that someone can just get on with?
Yes, it's already specced out and gives good insight into many parts of Django+DRF. I could do a simple frontend implementation as well to make it useful for the users.

*Statistics

can be built on top of existing data & the comment field, but since there are no groups who actively use the tool (to my knowledge), I wonder how much sense it makes at the current stage
(Bruno: it can motivate people to know the number of pickups they've done and the total number the group has done. It would make it easier for us to calculate an average of kilos saved)

*Share points:
    RGSoC: There are the places (shops, bakeries etc.) where people can exchange food at certain hours. Many foodsaving groups have share points/places as permanent places (public fridges), sometimes as pop-up events (e.g. Monday 10:00 regularly). Permanent places or pop-up events should be per group, and publicly visible. We are going to design a share point model, serializers and endpoints that will include 1. name, description, location 2. group of foodsavers it belongs to.

    It still makes sense to have, but I think groups would still use local advertisement and facebook groups/pages to promote those sharepoints. So we should maybe first build in more community features to get users active on the page before we add share points.

*notifications
https://github.com/yunity/foodsaving-frontend/issues/257
Planned:
    - Mail
    - Slack
    - other webhook-based sytems (can share code with the Slack integration)

Ideas:
    - Telegram
    - (Android-) App
    - Facebook
*
*roles / capabilities
https://github.com/yunity/foodsaving-frontend/issues/356

-> How to decide on the different options? Have a bigger discussion with more people? Involve the ones who are using the tool? Foodsharing.de experiences?
We need it for two things: legal agreement and student/instructor mode. Either build a system tailored to those case, or build a more fine-grained system that allows different roles. Maybe we should rather call this 'capabilities' then (e.g. check for any operation if a user has the capabilities for it, or is in a *team* that has the capabilities for it). The default mode could be that all users have all rights in a group.

A reasonable starting approach could be to find best practises in django apps, find the cool libaries, and limit ourselves to features that can be implemented using those. When me and Matthias originally tried implementing permissions it got very complicated very quickly.

Django has permissions, but they are site-wide. Could do some tricks with namespacing them by group, which would allow us to reuse tested Django code. Possible source of confusion: our own "Group" model vs. the Django permissions group model (that was my naming mistake)

Use the capabilities to implement group admins/trusted users:
    The groups on the Foodsharing platform meet to collect food from different companies together. Some of these groups want to designate one of them as administrator. Admin roles should be optional and per group, by default all users are equal. If the admin feature is enabled, a non-admin user should not be able to do the following things:
        - edit the group
        - create/edit/delete stores
        - create/edit/delete pickup dates and series
The usual actions a non-admin user can do:
    - join/leave group
    - join/leave pickup date
    - give feedback (when implemented)

I see this library that builds on top of Django Group/User roles - http://django-role-permissions.readthedocs.io/en/stable/index.html
This can do "object permissions" too, e.g. user having a given permission for another database entry (see https://django-role-permissions.readthedocs.io/en/stable/utils.html#has-object-permission )
One of the tricky things is to get lists, e.g. give me a list of all objects of type X that I have Y permission for

Tilmann points out that Django Rest Framework already implements object permissions - http://www.django-rest-framework.org/api-guide/permissions/#djangoobjectpermissions (seems equivelent to Django Role Permissions lib)

*legal agreement
https://github.com/yunity/foodsaving-frontend/issues/324

I have the feeling that those groups who have a legal agreement also have more hierarchies in their org. So they would probably want only some kind of group admins to be able to edit the legal agreement. To do: get in contact with those who want it (I think Stefan from Taiwan was one?) Unai from Bilbao also requested this

*student/instructor mode
https://github.com/yunity/foodsaving-frontend/issues/99

That should be designed closely with people from Gothenburg (maybe Bruno?). It could also make sense for many groups, at least I've seen it quite often in Germany.
(Bruno: I personally think this is not a priority. Much of people's first pickups are done outside of the platform, so the platform itself does not need to be so specific about it. I'll talk to Nicco again, who had this idea, and see what he thinks...)
*
*Quiz Framework:
    RGSoC planning: This is meant as an additional step before people can join a group. The questions and answers should be set by the group members. This is a bigger task and has to be planned and discussed in cooperation with the developer team.

    I came to the conclusion that I would rather go for the student/instructor mode than putting a quiz there. The quiz in foodsharing.de was the block off people who are interested but not qualified or *interested enough*, but first there should be a training infrastructure in place.

*community features and public landing page for communities

One of the main complications has been not having community-building tools available inside the tool (forums, chat, whatever) or a way for communities to have a nice landing page to explain what the community is about.

*Landing Page
The public landing page access could be implemented by having a quick way to automatically deploy wordpress sites for each community (I have been learning too much about how to automate wordpress installations lately...). Although still I tend to favour things built into the application.
Not such high priority to provide a public landing page for each community, but it would help them. Still, most groups manage to do this on their own right now.
I started with the groupInfo page, e.g. https://foodsaving.world/#!/group-info/20 - it's public and could be extended as an advertisement page. But maybe it makes sense to give them a full wordpress site instead (e.g. harzgerode.foodsaving.world or so)
I think the groupInfo page is a good start - it would make sense to include markdown there soon. And if it also had the option to include photos it'd be a very good start and sufficient for the next couple of releases... (sufficient by our standards? or the user communities?) -> Sufficient for groups to present themselves. If they get bigger, they might also have their own pages anyways like solikyl.se

*Chat / Forum
My impression is Tilmann more favours integrating with other tools (matrix, discourse, etc), and Nick favours building into the application.
We could do a factual discussion about the pro/cons of doing our own vs using something else.
Reasons for doing our own:
    - tight integration
    - only implement the necessary features

Reasons for taking an existing solution
   - might get to use existing client software that we would struggle to build (e.g. mobile chat apps)
   - closer to the dream of building software using pre-existing blocks of features
   - hopefully other people thought about the best design/architecture, so we don't have to

I noticed today that http://libretaxi.org/ is built as a telegram bot (so all features are accessed by using regular telegram client afaik). Not sure what you can do with telegram bots that might be useful here.
Just brainstorming: what would we need if we want to use telegram as chat system?
- server adds users to a group
- send messages from server to user (as notification)

For using matrix as a chat backend, they make available a js sdk for integrating (works in browser and nodejs) - https://github.com/matrix-org/matrix-js-sdk
I gave some feedback in the github issue - the biggest problems seem to me on the server auth side. The js sdk is a rather shallow wrapper around the matrix API.

See:
   https://github.com/yunity/foodsaving-frontend/issues/520 - Integration of communication features (chat, forum, ...)
   https://github.com/yunity/foodsaving-frontend/issues/431 - Branding/theming and/or CMS integration

*pickups not only as pickups, but events (e.g. "clean the public fridge" etc)
   Quite some refactoring work in the back&frontend. Generalized todo events (e.g. a "rota tool") are definitely useful to all kinds of people (e.g. community living, festival planning...), but I would still only focus on foodsaving groups right now

*food baskets (person to person sharing)
   First the community features, then those. If there are no users, who will see the food baskets?

Browser not supported