Hey @decentral1se and welcome back
I’m really happy our direction go more generalized is interesting to you, we figured the basic features of karrot are actually quite general purpose, and could be suitable for many more use cases. Well, let’s find out!
Development activity is a bit low right now, partly because of me, I’m on a bit of a “summer pause” (preparing for a long awaited cycle trip)… but we focus on slow and steady, comes and goes in flows. I think you know all this kind of stuff anyway
Would could be a really nice approach that we’ve started doing more, is do a video call with screen share where you can show us how you organise at the moment, e.g. with foodsoft, and whatever other tools. It makes it really real for us, and helps to see how the flow of karrot can be… and quite motivating later on when I see karrot being used for real stuff (compared to my seed data local dev database).
So, more specifically in reply to the ? points:
The closest we have right now is using “Places” for non-geographical purposes, there are groups doing this already, you don’t have to choose a location when creating a place (which is not obvious). And we don’t have explicitly membership of the places, but when users star/favourite the place, they will be automatically subscribed to the wall, which can be used for communication.
You can sort of see who has favourited a place (on a place page you can click on the star on the left, and it shows you the avatars of the users).
There is scope here for improving all these aspects things within the Places feature, but I also wonder if we need a bigger concept which is more like subgroups or teams at some point. As the groups scale, they do get unmanageable at some level, one current solution is just having multiple groups (a few of the groups do it like this, and it can actually be quite good for supporting more autonomy amoung the parts of a group).
There was a bit of chat on a related topic here → How to make Places more suitable for conversations? and @bruno is using Places for non-geographical uses (as we are in karrot now, with our meta group).
Usually the groups are using external tools for more content, and linking to them in the descriptions. Our upcoming agreements feature might work for that use case - they will support democratic process to add/update agreement documents (we have the feature prototyped over at https://karrot-prototyping.netlify.app/ - actual dev hasn’t been started yet).
For some groups that might be a bit cumbersome process to go through a whole process, instead of just editing a doc directly, but for that case maybe just a public pad (or BigTechCompany Doc) linked from the description is sufficient?
We have the group application feature, which just has a freetext field question and answer, when we built that I imagined one day it might be great to include a form builder to it, I think that feature would make sense, and can be incrementally added to what we already have.
Group applications are already modelled around a conversation (with applicant + group members, who can opt in/out to be notified about new applications), so maybe that aspect already fits?
All issues at the moment are group wide, and also the outcome options are focused on the worst case (removing the user from the group), as those were the conflicts that were most critical to support. But one of the most common things requested is less drastic “conflict” options, which go along two lines:
- “graduated” conflict - if appropriate, encourage dialog between only impacted people, then if needed bring in people that opt-in to be mediators, and if that fails, then go group wide
- subtler outcomes (e.g. locked out of account for 1 week, remove a role, offline resolution, … or I guess just a nice warm feeling inside having resolved something, it’s based on a dialog as we have a general hope that most/many issues/conflicts can be resolved with good communication, and are often just misunderstandings)
I feel we definately started to focus more on the human and community features of karrot, over “technical resource management” type stuff, and my hunch is that resource management realm is perhaps already better served with tools, than the community features… so great if that makes sense to you as separate apps, I think those are a lot of work too, and in a very different direction.
What sounds like one of the biggest needs from you is the work groups part, and I wonder what are the basic needs of those? How is access to a work group managed? (assuming they already exist in the offline reality of the group)
Ok, that’s my thought dump for now!