Active / non active members

my group has big problem and in the future it will be bigger.

ok, we have the members but when we have constitution and says every decision has be made by 50%+1 votes of all the members, that mean members that have some months to get in they count and in the end we won't have the required participation.

We need an option that we can put members inactive if they haven't log in after some period time, and also we will need to know which member has log in last time (we need a timestamp, perhaps in membership list).

Indeed, a "last seen at" sortable column on the membership list could be a good way of solving this problem.

However, realistically, I think this probably isn't that high on the development priority list at the moment, so it might be a while before it gets developed (given all of the other high-priority issues that we're trying to fix).

Is there a way you can get around the problem in the meantime?

@jonlemmon now that we are still few members, we can fix it. But sure in 2 to 3 (maximum 6) months we will need an option so any member haven't log in e.g. 6 months will turn automatically inactive and don't count on decisions until he/she log in again.

@christaklis cool. Hopefully within a couple months we'll be in space where we can easily solve this problem.

Thanks I will be waiting...

@christaklis did you get a solution to this problem yet? It may be that your group can solve this by changing the rules you agree on about how you use Loomio, rather than needing to change something in Loomio itself. For example, you could change the 50%+1 rule you've made to a super-majority (say 75% or 80%) of those that vote. Or you could agree that A clear majority (more than 50%) of those who voted would allow those who agree to take action, but dissenters would not be bound to act on the decision. To make a decision binding on the whole group would require either the 50%+1 of all members or super-majority of those who voted.

Another option, which could be used in parallel with your existing rule or any of the above options, would be to devolve as many of your decisions as possible to subgroups. Subgroups, being smaller and more agile, are more likely to be able to function by "rough consensus and running code" rather than formal majority votes, and their coordinators could remove inactive members (according to a rule agreed in the subgroup), without them being removed from your main group.

Thanks @strypey. But i haven't used Loomio for some months now. So i don't know what have changed.

Loomio is still a very beautiful platform, and really wishes movements and groups that i belong to use Loomio, but they are even bored to try it.

Those are good practical workarounds, but I do think that community experiences could be made much more efficient ultimately if Loomio (eventually) enables accounts to be toggled as active/inactive-- by their users, and potentially also (ideally per group settings) by admins.

I'm not trying to revive an old discussion here; just throwing my relatively recent two cents in. Thanks for suggesting workarounds to technical limitations.

I agree these would be good features, in the same way that separating pending users from actual users in the UI (and the member limit) was a good feature. I definitely have groups I'd like to mark as dormant (or even closed) so people aren't frustrated by signing up to zombie groups.

But the reply from @christaklis suggests to me that the problem wasn't really the feature limitations of Loomio, but his group's willingness to engage with it. When this is the case, no amount of tinkering with the software or UX is going to solve the problem.
EDIT: typo

But the reply from @christaklis suggests to me that the problem wasn't really the feature limitations of Loomio, but his group's willingness to engage with it.

I don't think anyone will ever really know. A group's willingness to engage with a tool is not isolated from the feature limitations of the tool.

We may have to agree to disagree on that. In my experience, if people are committed to using a software tool, for whatever reason, they will come up with social and other hacks to work around its limitations. For example, Evan (@rabble) of Twitter said in his OSOS talk, that @ mentions and #tags and a bunch of other things that are now hallmark features of Twitter (and now becoming generic practices) were created spontaneously by users. Software tools are always used by non-developers in ways the developers never expected or planned for, and the evolution of the software is guided as much by the emergent behaviour of users than by any 10 Year Roadmap decided by developers.

I described a number ways Chris' group could have made the tool work within their agreements without any UI changes. This is why I conclude the base problem was not technical, but social. I find this a lot pitching free code replacements, particularly to activists. We tend to be obsessive social game players, very concerned with whether the person who suggests a software/ platform will somehow gain power in the group if they suggestion is accepted, and all too often this has nothing to do with any informed evaluations about how software can and can't confer power (eg proprietary peonage vs software freedom).

BTW I just want to say I really like the text truncation and "show more" feature. Loomio crew #UXWin !

In my experience, if people are committed to using a software tool, for whatever reason, they will come up with social and other hacks to work around its limitations.

Many groups won't commit to using a new tool if they're significantly put off by many of the limitations-- and, why should (or shouldn't) they? I think that must be determined uniquely by each community.

I think you focused here on trying to help that specific group, and that's fine. I'm commenting on potential active/non active member feature which is the topic of the old OP here. I consider it highly appropriate for me to publicly express my view that that's a desirable feature.

Yes in some way it was also the willingless of the users.

But now the group doesn't exist anymore. And i am trying to bring other groups to Loomio but they have ancient minds and prefer just to stay at simple forums which doesn't help a lot.

But i can't bring them to Loomio with force. I like Loomio and it is becoming better and better... and more useful tool to communities and groups...

Perhaps some of the new features in beta testing could help with this? Especially the ability for people to participate in polls without needing to join a Loomio group, or even have a Loomio account.

Is still Loomio open source? And if yes all the new features are available so to try to install it in a group's server?

And can you give the link to the source (so to try to install it)...

source is available here https://github.com/loomio/loomio

Yes, Loomio is still AGPL, and I assume the code for all the new features are available in the source code repo, thanks @samparkin for the link.

BTW I'm hoping that the liberation of Loomio polls from being embedded discussions/ groups will make it much easier for other free code platforms to integrate a version of Loomio, or interoperate with an existing Loomio server. I'm hoping we can do that eventually with CoActivate.org.

BTW I'm hoping that the liberation of Loomio polls from being embedded discussions/ groups will make it much easier for other free code platforms to integrate a version of Loomio, or interoperate with an existing Loomio server.

Yep: I can't predict all potential results of Loomio's increasingly modular usability, but it's a potentially explosive (in a good way) development.

Would you mind expanding on what your use case is with CoActivate?

My hunch is that, at this point, all of the tooling is there, and the last missing piece is some documentation on how to do what you're looking to do.

Happy to. Is this the best thread for that conversation? Is there an existing thread about integrating Loomio into other apps that I could contribute this background to? Would I be better to start a new thread? @richarddbartlett @hannahsalmon

New thread sounds good to me.

Ka pai. I'll open it in the main group. Feel free to move it to the appropriate subgroup as appropriate.
EDIT: Seems like I can't start new threads in the main group, so I've started one in this subgroup

That's a shame @christaklis . Have they moved to a different set of software, or just given up on trying to do decision-making online?

I consider it highly appropriate for me to publicly express my view that that's a desirable feature.

Of course. I'm sorry if you felt silenced by my comments, that was not my intention. To be fair though, the comment I replied to was:

A group's willingness to engage with a tool is not isolated from the feature limitations of the tool.

This comment was not about a particular feature, or the desirability of it. It was an empirical claim about the relationship between user groups and software, one that I disagree with for the reasons I gave in my reply. As I said, we can agree to disagree about this for now, because it's a complex subject, and this is not really the place to go into it in the level of detail I think would be needed for us to find consensus :)

Please feel free to steer the discussion here back to the feature you are proposing, and the details of how it could be implemented in Loomio.

Thanks @strypey . For whatever it's worth: you're correct that my comment was an empirical claim, because I wrote that willingness to engage "is not isolated" from feature limitations, as opposed to expressing uncertainty. Frankly, I think that that empirical claim is sounder than claiming that willingness to engage can be isolated from feature limitations. (In fact, much of my commentary in many discussions exists only to dispute empirical claims which I consider to be mistaken.)

But be that as it may, I can certainly agree to disagree.

I lack the capacity to focus on the OP topic now, unless I feel that discussion gets badly confused or misdirected. I may come back to it eventually.

Frankly, I think that that empirical claim is sounder than claiming that willingness to engage can be isolated from feature limitations.

I think we're in danger of hurling claims at each other from either side of a false binary. I can certainly agree with you that users won't keep engaging with software that provides no useful features, or lacks a feature essential to their use case. But I also know that more experienced users (especially radical software freedom activists like me) will often choose the less feature-complete free code option, over the feature-complete proprietary option. Usability is an important consideration in software choice, but it's not the only one, and considering that usability is a moving target, I'd argue (along with Stallman) that it's not the most important one.

But I also acknowledge that people newer to using software tend to approach it like buying an appliance. They assume that the way it is now, is the way it is. Period. They don't see it as a fluid thing that will require ongoing development to keep working at all, and that can be improved over time in response to user feedback. They haven't learned from bitter experience of having start-ups offer them a great, gratis service, then get eaten by one of The Stacks (eg EGroups, YouTube, Instagram), or start charging with no data export option (eg Ning), or adding intrusive ads (Google, FarceBook, Twitter), or paywalling features/ content (Medium, Academia.edu).

I appreciate the added nuances; thanks. I think that all of our theoretical discussion is tangential to this topic.

i wanna recommend use gender-free term "ze"

OK Thank you. Let's see if they wish (our group) to use it on our server!