There will always be complainers in any case. It’s a question of degrees and impact: is this particular criticism so widely held that it significantly impacts the project’s financial viability?
It’s impossible to say without hard data. Some sort of survey could be useful. I’m sure there are statistics nerds in the community who would be willing to help collect data 🙂
Exactly. 🙂
Let’s distinguish between the means and the ends. An admin policy is the result of the means by which administrators are selected.
The sticking point for many donors is a question of the means: they are unhappy that a conflict-of-interest exists in the current selection of administrators for a dev-owned instance. This is orthogonal to the subject of administrators’ concrete policies.
Which begs the question: do the devs acknowledge that the COI exists? If so, then is the team willing to incorporate the community’s feedback by closing the COI?
Maybe the team has a compelling reason to hold onto the existing COI (nuance exists); but it cannot be denied that the COI (1) exists and (2) is reducing the devs’ ability to raise community funding. Whether this is a ‘good’ or ‘bad’ thing is a matter of personal judgment. But the facts are what they are.
Side note: if there’s some set of admin policies that the dev team wants to see enacted in .ml, then they could easily select 3rd-party admins that they trust to enforce a policy that aligns with their own values without reproducing the COI that currently exists. Then, if there’s any conflict over those particular policies, that would be an entirely separate discussion.
My read is that they’re recommending that
I agree with this. The act of administering a dev-operated instance with live accounts + users while working on the dev team presents a conflict of interest which is a deal-breaker for too many donors.
So, rather than simply asking the community for more donations (which is understandable but doesn’t address the root of the problem), it would be best to incorporate the feedback of the community and do away with the conflict of interest. IMO, another way to resolve this COI would be to disable live accounts for anyone who isn’t a developer in the “test” environment.
I’ve seen a defense presented in this thread along the lines of “we should be allowed to admin .ml because it’s a test instance” — but again, due to the fact that there are live accounts for live users (outside of the dev team) in the “test” environment, this is a distinction without a difference.
It’s a practice called soft-deletion. The idea is that you flip a “deletion” flag on customer data and record the date of the deletion request. After some time, typically 30 days, a garbage-collection cron job will identify your data as having been “soft-deleted” N days prior, and then permanently wipe your data from their servers. This gives people a chance to restore their data in case they accidentally moved it to the trash or change their mind soon after.