On Fri, Dec 25, 2020 at 12:17 PM, Shal Farley wrote:
Also, maybe there could be donation incentives at the group level, either within the current Donation method and/or within the simplified (no Stripe) method I suggested.(list of perks, that are otherwise restricted by the group)
I don't think anyone should be able to bypass what the group's owners have specified as how the group operates. If on the other hand the group owner(s) are agreeable to allowing (some) members do things (like creating hashtags, post in HTML, etc., as Shai had postulated), then sure these could done as "perks" allowed by payment of a donation, and not allowed otherwise. It doesn't really sit right in my own mind, but it certainly is possible.
The code to implement this should not be actually a lot - added data structure to the definition of each group that indicates which features may be overridden on donation (and the parallel display code in the GIO group definition), each GIO member which shows features they are allowed to override above the groups settings (and the parallel display code in the member definition that allows them to select a perk override), and a small routine that does the member lookup to determine if that member is allowed to do that function.
A small variation on this would be that the perk features would have to be turned on (as opposed to being an override), and then the lookup code would determine if the member had paid and also marked this feature as their choice. Thus, members who haven't donated anything would still not be able to perform this feature, even though the feature was selected as available in the group definition.
Nevertheless, it doesn't sit well with me. There might be some features that a higher level of use might feel ok, if the member paid the donation, but not for all features. Basically, we would be creating a different level of member within each group, based on whether they donate or not.