The iNaturalist discord server maintains several different projects on iNat now. We always have a yearlisting project going, as well as an all-time project. These projects as well as others we manage share a requirement that observations must be made by certain users, those users being the constantly changing list of our server members. When a new member joins or leaves our server, we have to change the user list for several different projects at once. We’d find it very useful if we could have one list of users that we could apply to all our projects at once. Would this be a feature that we could add?
I’ve tried to outline what I think this feature would need to be functional:
A list of usernames that can be used for the “observed by user” rule on multiple projects at once
Can be edited by multiple different “list admins”, the same way that a list of users built into a project works
Can be accessed by any user on iNat, like how projects are accessible by any user
Can be coupled with a server’s “only show observations by project members” function
Alternatively
A different way this could work is instead of having a separate list, providing us a new option to set a project’s observed-by-user list to match another project’s user list. This method would have to update the list whenever the source project’s list updates, not just be a one-time “copy the other project’s user list”. This would be a less open-ended feature, but would probably be more reasonable to add
sounds very much like how lists (eg mail) manage groups… it wouldn’t be a simple implementation, but it certainly would bring it’s weight in functionality! Especially as iNat continues to grow, and established members find new ways to enrich their iNat experience!
@mws I like your alternative to just have the list be another project with user rules. In fact, something like this was asked for here but it didn’t go anywhere.
i do think it would be useful to be able to set up groups of people so that you could filter that group (in project settings and also as a general filter), but i think that would complicate the way project trust works.
If I understand this correctly, “the way project trust works” is that[edit: my comments here support my following argument, but don’t really hit the mark with project trust … see my next comment about that] … the standard model is the open membership option, where the user has ultimate control over whether they are in or out of the project if it is created with “include only member observations”. And ours is the closed membership option, which maybe somewhat runs contrary to the trust model because admins can add user observations to the project independently of their wishes. Is that accurate?
The thing is, we (the iNaturalist Discord community) don’t really have or even want a closed membership. Anyone can join our community - we share the invite far and wide - and we don’t add anyone to our project “must be observed by” rules unless they request it. I would describe what we have implemented as a moderated membership. I would further argue that this is closer to the iNat ideal of openness than a fully closed membership because it operates on requests to join or leave initiated by the user, but it is much harder to maintain: it is completely disconnected from that “Join” button, relying instead on admins noticing that signaled intent to change their membership and taking action.
This feature request would reduce the admin burden of moderated membership by only requiring the admins to add users to the “approved” list once. Thereafter, users retain the ultimate control to join or leave any project that make use of that approved list. It’s a small reduction of workload that would be reduced even more if moderated membership were formally supported (e.g. via “Join”, followed by an admin pressing “Approve”) - but that’s a topic for a whole other feature request.
Oh, I’m slow. Something just came back to me from another conversation elsewhere - can’t put my finger on where - about project trust. Users have the option, for example, to allow project admins to see their included observation obscured coordinates. But that permission should probably not also extend to any projects that use that project as an “include these users in the rules” list. I don’t think the proposal here breaks that model, though, because that privileged access would still only be granted when the user also clicks “Join”, and not by mere inclusion of their observations via those “must be observed by” rules. Do I have it now?
yes. i think that’s more or less what i was getting at in the other thread. the membership thing and the include users thing are separate. there’s trust option associated with the membership thing, but not with the include users thing. so what i was trying to say was that the trust wouldn’t necessarily carry over from the membership on one project to a user list on another project. or if you wanted to make it carry over, it would complicate the trust model by making trust model have to incorporate the included users, too, or something like that…
the primary request here includes requirements tat sort of try to blur the lines between membership and user list on projects, too. so it’s also asking for some extra complexity. however, the “alternative” ask looks fairly clean (though the functionality is much more limited / niche), and i would almost extend that request to allow syncing of any of the rules from one project to another. even if staff don’t work on this any time soon, i think it would be possible to use the API to write something that would handle the “alternative” request, or perhaps something simpler like allowing you to add / delete users, place, etc. for inclusion in / exclusion from multiple projects at the same time.