Log: incoming feedback in raw format

Feedback from Robin Foods:

and one more little thing: maybe u can forward this - after 60days people get kicked out - a setting where we can change that would be nice or extend it to 120 days or so… lots of people want to join after some time and get demotivated because they were kicked

Makes sense to have it as a group setting I think…

Von EfA (auf die Fragen habe ich schon separat geantwortet)

  1. Wer bekommt die Info, wenn man “Unterhaltung öffnet” und eine Nachricht verschickt in einem Favoriten Betrieb an einem Datum?
    Ist es niemand, weil z.B. noch niemand eingetragen ist für diesen Termin, oder
    sind es alle, die den Betrieb als Favoriten haben?
    Hintergrund meiner Frage ist, dass wir rund 60 Mitglieder sind. Immer nur eine kleine Gruppe kümmert sich idR um einen Betrieb und hat ihn als Favoriten.
    Bisher läuft es jedoch so, wenn einer mal einen Ersatz braucht, dann schreibt er an die Wall und rund 60 Leute erhalten eine Mail, obwohl es z.B. nur 5 interessiert.
    Das möchte ich gerne verbessern. Ich möchte die Wall für die Infos belassen, die wirklich an alle gerichtet ist.

  2. Automatisches Scrolling nach Abgabe eines Feedbacks:
    Könntet ihr da bitte wieder abstellen. Es war nicht immer so.
    Wenn man seit einiger Zeit ein Feedback gibt, dann dann scrollt das System gleich nach der Abgabe zurück zu den allersten Feedbacks, die für diesen Betrieb gegeben wurden. Bei uns sind das mehrere Jahre. Das ist ziemlich nervig.

  3. Vereinfachung der Löschung von Mitgliedern, die sich nicht mehr melden und ggf. nur Daten abgreifen:
    Hier sind wir nicht auf dem neusten Stand, aber wir müssen demnächst wieder einmal aufräumen bei unseren Mitgliedern. Einige fallen nicht auf inaktiv, weil sie die App immer öffnen. Gleichzeitig sind sie z.B. seit längerem nicht mehr dabei, melden sich jedoch nicht aus dem System ab.
    Hier wünschen wir uns ein weniger aufwendiges System den Mitgliederstamm zu bereinigen.

Joining a new discord group two ideas came up that inspired me to have ideas for Karrot.

1. Joining questions

It had a nice dialogue with a set of questions (custom for the group) that I had to answer, I thought that was a nice feature!

I’m not actually sure if I had to answer them before joining, or after I joined…

It had questions that would then detirmine which channels you automatically got added to, things that might go into your profile, etc…

For karrot it might have options to:

  • automatically subscribe you to certain places
  • configure your roles in a certain way
  • update your profile/phone number or picture (although these are currently instance-wide…)
  • write an introduction message that gets posted to the group wall? or some other place wall…

These feel like kind of “post-joining” questions so maybe don’t fit into the application process… (which could also have custom questions to be answered). Not sure

2. External verification process

Actually, this is not a feature of discord, but a manual process they have added.

In order to find out if you are actually a proper signed up green party member (which is stored in a separate membership system), they ask you to manually share your account info, and someone will check it, then add you to specific groups I guess.

In the context of Karrot, I was thinking about those groups that have an organisation structure that is not fully represented in Karrot (most of the bigger groups seem to have a legal entity or some association). For those, they might have processes outside of Karrot to elect people to board membership or similar.

We could have a feature whereby Karrot can make a request to query an external resource (could be an externally hosted spreadsheet, or public info on an official webpage, or whatever…), and then make those users in Karrot have specific “external” roles.

That could then allow certain people in the group to access features that are not otherwise available to “self organised only” mode Karrot…

It kind of goes back on some of the self-organised vibe of Karrot, where we try and have community-only power structures, but the reality is that groups maintain an external organisational structure anyway… so at the very least could make it visible within Karrot.

Groups are able to request manual changes to the database (e.g. removing users) already, so this could be a way to enable those actions to be done directly by those members - and code an accountability process for it (so any actions are logged for the group to see).

One feedback I got in a conversation

If I could only disable the things I don’t need.

Also the list of activities you signed up for seems to be confusing, as it blocks your view of the main wall or you need to scroll down quite a bit.

Mobile seems to be the primary use.

The group is really small (4 members). We use activities quite a bit for events (to coordinate the use of a shared space). Each event needs a “buddy”. The buddy doesn’t need to be there all the time, but makes sure the person hosting the event has everything they need (access to the physical space, knows the rules, signed the contract etc.). The people hosting are not in the karrot group, the ones who can be buddies are. I thought that’s a nice usecase for participant types but what was confusing is the language of “join activity” as you don’t necessarily join, but “take care of it”. I guess that’s not a big deal as we figure out how to adapt karrot to our use case.

Another conversation that came up is the need for an internal place. E.g. a place that can only be accessed by certain roles, so you can have a more private discussion. Back to our scenario, we are (or I am :smiley: ) wondering whether to invite more people to the group. But it’s clear that only certain people can take decisions e.g. what events to hosts (there is the possibility to object) or who is the buddy for what. As everything is open and accessible in karrot, there is the concern that discussions can blow up or that people interfere in discussions where they have now decision power and that doing the actual work will get draining. Or that it’s just difficult to say “no” to a request when the person who’s asking is in the same group and can see your discussion about it.

Personal note: it’s an interesting scenario for me, as I’m deeply involved in karrot and came in with a vision of how the software could be used, but what’s actually needed might be different to how I imagine a community to run :slight_smile: