TrueCharts Nextcloud vs. iXsystems Nextcloud

[indivision]

I'm testing to see if it's possible to rely on a Nextcloud install on SCALE for long-term, semi-critical use.

I started with the TrueCharts version because Traefik makes it easy to securely set up an external connection. However, it's not really viable for long-term, critical use because major version updates can happen at any time and as a matter of TrueCharts policy, users can expect no support or troubleshooting information of any kind if major version updates break their install.

So, I have three questions:

1. Does the iXSystems version of Nextcloud have a similar support policy? Or, do they define a different commitment to the survival of installs between updates? Whether that is counting a failed upgrade as a bug and fully testing upgrade scripts against real-world cases or simply linking to manual steps users can take to transition. I need to know if someone is considering the actual long-term usage of that kind of application.
   
   
2. Is there a guide available that explains how to set up secure, remote access to the iXsystems version?
   
   
3. What has the upgrade health been like so far for that version? Has anyone using it had to start from scratch due to bad upgrades? Or has it survived so far?

Thank you for any help you can offer!

 

[morganL]

I would recommend either getting "Enterprise support" and/or running Nextcloud as a VM if this is mission critical.
You need someone to be testing your specific setup well before you switch over to new software.
The VM provides better isolation if this is a critical application.
Perhaps next year we'll solve some of these issues, but at this stage its best-effort, not a guarantee.

 

[DaSnipe]

TrueNAS SCALE in itself is still relatively new, so you're going to see bugs from the top down. I think you'll see bugs and failed upgrades from time to time still, especially with charts, since there's not a large userbase of installed users and they can't account for everyone's systems or setups. Also as morganL said, if you're relying on this to be semi-critical you might need to use a different system and not update/upgrade often.

 

[truecharts]

We're sorry for your negative experience with our Nextcloud App.
This month we're making a huge effort improving our Nextcloud App for Performance and stability and we're sincerely sorry for the downtime this has caused some of our users, like you.

But we want to highlight that the breaking change your experienced, was a complete rework of our Nextcloud App to, especially, allow for semi-critical and higher-load usecases.

We aim to always announce major updates before they happen and they are always semver-tagged with a major version increase and excludable from our TrueTool auto updater.
If there are known migration or mitigation steps, we aim to always supply those, but in some cases (especially on complex Apps like Nextcloud) there might be either upstream breaking changes or general "flakyness" that is not pre-defined.

"Breaking Change" and "major" versions of TrueCharts Apps, needs to be seen mostly as a warning to the administrator:
"Watch out, There might be dragons".


---

The biggest difference is the fact we offer free support via our support staff, whereas iX Systems (understandably) only offers a paid enterprise support option. That's also the reason we needed to limit the support-ticket option to not include breaking change updates.

All sorts of Helm Charts (which is what SCALE Apps are) have breaking changes from time-to-time, some more frequent than others.
So if you really need this level of support, we would advice managed solutions or payed support contracts.

---

So In your order of questioning:

1. Best-Effort in both cases
2. Any normal reverse proxy and manually configuring Nextcloud would do for the official App
3. No big breaking changes for the Official App this year as far as we're aware.

 

[indivision]

I would recommend either getting "Enterprise support" and/or running Nextcloud as a VM if this is mission critical.
You need someone to be testing your specific setup well before you switch over to new software.
The VM provides better isolation if this is a critical application.
Perhaps next year we'll solve some of these issues, but at this stage its best-effort, not a guarantee.

Thank you. VM makes a lot of sense as I could just use the upgrade processes published directly from Nextcloud. Will research that approach more.

As much as I like the app/chart system and still have a lot of uses for it, I think Nextcloud may just not be a good fit for that model. It's almost like an OS. Re-install, especially if a lot of people are using it is pretty much catastrophic.

Most other apps are smaller in scope. With a little preparation, occasional re-installs aren't the end of the world. So, if using charts is a must, it would probably be better to do what Nextcloud does with 3-4 manageable apps rather than 1 big system.

TrueNAS SCALE in itself is still relatively new, so you're going to see bugs from the top down. I think you'll see bugs and failed upgrades from time to time still, especially with charts, since there's not a large userbase of installed users and they can't account for everyone's systems or setups. Also as morganL said, if you're relying on this to be semi-critical you might need to use a different system and not update/upgrade often.

That's where I see a paradox for Nextcloud. What use is there for it that isn't at least semi-critical? It's made for multi-user organizations. As such, you can back the raw data up. But, restoring working versions with all the user data to get the install running where it left off is made harder within the chart system.

If there are known migration or mitigation steps, we aim to always supply those, but in some cases (especially on complex Apps like Nextcloud) there might be either upstream breaking changes or general "flakyness" that is not pre-defined.

Thank you.

Then it should be made clear, a user should never really rely on a chart for anything critical (with this support policy) unless it is one that they can restore from scratch.

Otherwise, they risk having the application either broken unexpectedly or at best orphaned forever at some less-then-latest version.

I think someone paid to manage an install like this would also make the same choice (to install in VM or other direct manner) for the same reason.

 

[truecharts]

@indivision
We offer more support for our Nextcloud (and other) Apps than most other communities out there. It's just the simple fact we don't always exactly know what the breaking changes are, for example:
Nextcloud tends to break things when upstream pushes a major release, as they also follow semver. We also tag that as "Major" and "breaking", because we simply want to inform our users that it might contain breaking changes. That does not mean we know every single thing that would break from that update.

The same would also apply for a VM running nextcloud though: If you install a Nextcloud Major release, that also might (and does, frequently) break some of the Nextcloud Apps.


So we really do not agree with our statement about "this support policy".
Just because we have our limits what we can offer in terms of support for our free(!) catalog, does not mean we always know everything. Even if we do not officially support something, often our support staff still helps out if people ask for help elsewhere in discord, we just don't accept support tickets for it because we don't officially have the manpower to help out.

If your level of wanted support is "I want someone to be available for when my App breaks after a major version increase or want migration guides that cover everything", that really is a level of support that is almost always paid-for "enterprise support" or "managed services".

If users really want to run something from us as (semi-)critical infrastructure and need such a contract with or without SLA, they can always reach out and we will try if we can find a solution there.
But those contracts and guarantees do not come cheap anywhere.

That being said:
When asked we always are quite open about the fact we do not think SCALE and TrueCharts are ready for SME (aka: semi-critical) usecases yet. We're working very hard to validate a number of Apps in our catalog for such usecases though, but that will take time.

 

[indivision]

The same would also apply for a VM running nextcloud though: If you install a Nextcloud Major release, that also might (and does, frequently) break some of the Nextcloud Apps.

Yes. But, the direct process for restoring to backed-up code is typically documented and entirely within my control. Unless I am doing something really off the beaten path, others will report the same issue and it will be fixed. I've been doing that type of thing myself for years.

In the charts system, that part of the process is managed by others that I share no insight with. So, if the ball gets kicked back to me I now have the added task of having to figure out how they set things up, what their script does/doesn't do, etc. It makes fixing it a lot harder, for me and/or anyone that I pay as well.

So we really do not agree with our statement about "this support policy".

I'm not seeing how you are really differing from my point.

You are saying that you can't fix everything. That's fine. I understand and accept the limitations that you have. I also have shared/maintain both free and paid software that I authored. So, I fully understand the differences users should expect there.

But, you also agree that the support policy you have does not cover all that is needed to run a mission critical application without someone else doing additional fixes to it (if/when a major update breaks it).

Isn't that conclusion directly related to "this support policy"? For instance, if the support policy included the activities I mentioned in the OP then running such apps would not require someone else to reverse engineer and troubleshoot broken chart updates. It would be addressed in one way or another by the different support policy.

If your level of wanted support is "I want someone to be available for when my App breaks after a major version increase or want migration guides that cover everything", that really is a level of support that is almost always paid-for "enterprise support" or "managed services".

Hm. Typically, on the projects I've worked on, these things get addressed via increased QA cycles, queues, staging versions, etc. There are options beyond jumping to one-on-one support. But, again, I'm not insisting on any certain support policy. It's not my right to do so.

When asked we always are quite open about the fact we do not think SCALE and TrueCharts are ready for SME (aka: semi-critical) usecases yet.

That seems very close to: "a user should never really rely on a chart for anything critical (with this support policy) unless it is one that they can restore from scratch."

I guess the only difference is that I'm saying that there will never be a point in time where the user can count on updates to work in this case. So, without more support (that they have to pay for) they should not rely on it.

 

[DaSnipe]

Thank you. VM makes a lot of sense as I could just use the upgrade processes published directly from Nextcloud. Will research that approach more.

As much as I like the app/chart system and still have a lot of uses for it, I think Nextcloud may just not be a good fit for that model. It's almost like an OS. Re-install, especially if a lot of people are using it is pretty much catastrophic.

Most other apps are smaller in scope. With a little preparation, occasional re-installs aren't the end of the world. So, if using charts is a must, it would probably be better to do what Nextcloud does with 3-4 manageable apps rather than 1 big system.



That's where I see a paradox for Nextcloud. What use is there for it that isn't at least semi-critical? It's made for multi-user organizations. As such, you can back the raw data up. But, restoring working versions with all the user data to get the install running where it left off is made harder within the chart system.



Thank you.

Then it should be made clear, a user should never really rely on a chart for anything critical (with this support policy) unless it is one that they can restore from scratch.

Otherwise, they risk having the application either broken unexpectedly or at best orphaned forever at some less-then-latest version.

I think someone paid to manage an install like this would also make the same choice (to install in VM or other direct manner) for the same reason.

Not to speak for everyone. But my personal upgrade went fine, and have had no data loss, running same install of TrueCharts Nextcloud for 6 months (reformatted apps pool). The changes in version 15 of the TrueCharts app also helps prevent user data loss by splitting config and user data by default along with the tremendous increase in speed. Basically you’ll be able to use it semi-critical soon but you can’t get guaranteed stuff on a free service/setup

 

[truecharts]

Yes. But, the direct process for restoring to backed-up code is typically documented and entirely within my control. Unless I am doing something really off the beaten path, others will report the same issue and it will be fixed. I've been doing that type of thing myself for years.

In the charts system, that part of the process is managed by others that I share no insight with. So, if the ball gets kicked back to me I now have the added task of having to figure out how they set things up, what their script does/doesn't do, etc. It makes fixing it a lot harder, for me and/or anyone that I pay as well.



I'm not seeing how you are really differing from my point.

You are saying that you can't fix everything. That's fine. I understand and accept the limitations that you have. I also have shared/maintain both free and paid software that I authored. So, I fully understand the differences users should expect there.

But, you also agree that the support policy you have does not cover all that is needed to run a mission critical application without someone else doing additional fixes to it (if/when a major update breaks it).

Isn't that conclusion directly related to "this support policy"? For instance, if the support policy included the activities I mentioned in the OP then running such apps would not require someone else to reverse engineer and troubleshoot broken chart updates. It would be addressed in one way or another by the different support policy.



Hm. Typically, on the projects I've worked on, these things get addressed via increased QA cycles, queues, staging versions, etc. There are options beyond jumping to one-on-one support. But, again, I'm not insisting on any certain support policy. It's not my right to do so.



That seems very close to: "a user should never really rely on a chart for anything critical (with this support policy) unless it is one that they can restore from scratch."

I guess the only difference is that I'm saying that there will never be a point in time where the user can count on updates to work in this case. So, without more support (that they have to pay for) they should not rely on it.

We want to highlight what we mean with "not offering support":
It just means we do not accept support tickets for it. As our support staff isn't able to deal with those issues.
In practice however, we are always trying to help out our users and the same was the case in your case..

One of our developers explained to you what we needed (information without cloudflare attached) and asked you to file a thread in our development channel if you applied our migration guide in the announcements.
Sadly enhough you've not picked up on that offer, but that does not mean we don't aim to offer more support than we officially do every single day.

We always aim to look into issues our users report if they are related to our works. We just don't accept support tickets for all of them, as our support staff aren't necessarily our developers.

We always aim to have support tickets worked-out in 24 hours if we can. For other, more complex, issues the timeframe can vary. But even bugs often get fixed within 48 hours.

We always go above and byond to try and help our our users. But the users needs to be open to recieve help as well.

---

On the topic of QA and migration guides:
There is a migration guidance in our announcement to the new version and that will also get expanded if more issues show up. Which always may happen with breaking changes of this scope (complete rewrite).

We're a free project and don't have hunderds of QA testers ready to manually test every single Nextcloud variation.

---

While we're working day-after-day towards our goal of offering the most dedicated support any opensource project can offer, we cannot offer the same amount of support that a company recieving money can offer. While we try to get close, it will always be "best effort".

But even so: If one really needs to use our software in critical applications we have people available that might be able to work out a support contract as well. It's not something we do frequently, but we understand that for some critical applications that might be required.

---

As you've not even taken us up on our offer to go over it with the developer initially, there is nothing more we can do for you.
We wish you the best finding a project and/or company that can offer the a better depth of service for free!

 

[indivision]

Not to speak for everyone. But my personal upgrade went fine, and have had no data loss, running same install of TrueCharts Nextcloud for 6 months (reformatted apps pool). The changes in version 15 of the TrueCharts app also helps prevent user data loss by splitting config and user data by default along with the tremendous increase in speed. Basically you’ll be able to use it semi-critical soon but you can’t get guaranteed stuff on a free service/setup

My install was also pretty close in 15. It finished booting. But, some network issue was introduced that caused a 502 gateway issue. Another user DM'd me saying that they had the same issue. So, it wasn't just me.

But, when I brought it up they just moved to shut down communication entirely, said it wasn't supported and that I shouldn't use cloudflare. Which is strange because the setup videos I followed for Traefik, from TrueCharts themselves, referred to using cloudflare and it hasn't been a problem with any chart I've used for months.

In any case, people are getting the wrong impression if they think I'm insisting on anyone changing what support they do. This was a test run. I had hoped I could trust using Nextcloud via TrueCharts. But, it's better to find out that I cannot now than down the road in more critical use.

In practice however, we are always trying to help out our users and the same was the case in your case..

It's nice to hear you say that. And I would agree that is true in past cases with some staff I've worked with. But, this was not remotely my experience today.

One of our developers explained to you what we needed (information without cloudflare attached) and asked you to file a thread in our development channel if you applied our migration guide in the announcements.

I did not intend to get into this aspect of it here. But, I feel that I must correct the record as that is a mischaracterization of events.

First, other staff were helping me to make good decisions rolling back and trying new versions. I was very clear that I needed help with those decisions and did not want to break the install.

At some point, another staff member jumped in and said that the issue I had was fixed and the new version was available. I tried it, and it actually mostly did work. Except that some new networking issue was introduced. But, he said helping with that is not supported because I used cloudflare. (Which again is strange since cloudflare was referenced in the TrueCharts Traefik setup tutorial I followed). He closed the ticket at that point with no mention at all about development channel, etc.

I opened a new ticket to ask clarification questions about where the last one left off. It was only after a very lengthy conversation, mostly about this staff member telling me that I'm on my own that he said something about the other channel. But, it wasn't framed at all like you say here as if there would be people eager to help in the correct channel. It was more along the lines of "piss off, maybe someone will help you over there."

Sadly enhough you've not picked up on that offer, but that does not mean we don't aim to offer more support than we officially do every single day.

Err.. I haven't picked up the offer because the above mentioned staff member removed my posting privileges on the server for an entire week! lol

Again, I didn't want to bring this up. To TrueNAS staff, I understand that you guys may not want drama from other communities brought here. However, these systems are so closely tied together now that I think this has become relevant to all TrueNAS users and people should really be aware of what and who they are getting involved with.

So, apologies in advance. But, I think my experience and the follow up is helpful for users here to know:

Why did my posting privileges get revoked for an entire week? Because I broke a rule "To not give personal feedback in public channels."

To be clear, I was civil the entire time. Even after they called me a name and laughed about it. The "personal feedback" that got me kicked for a week was that the staff member in question gave confusing instructions that did not consider the context of my support ticket, etc. I suggested that he was a good coder but his personality type was not conducive with helpful support. (I've been around for a while there. So, I can confirm 100% that I'm not the first user to make this same suggestion).

NOW, some interesting things have been revealed when I go back to the channel where I was kicked:

But, staff at TrueCharts can be as personally insulting as possible in public channels. No worries there!

This is what TrueNAS is sending users in to with TrueCharts. Where leadership views the civility maintained here with disdain.

I've been a member of this community for years. There was indeed an earlier time when it was just as toxic on this forum as it is in the TrueCharts discord.

It was only through a concerted effort by TrueNAS staff that the toxicity was systematically removed. And it was a huge improvement. Far more people volunteer helpful advice and the community here now thrives.

As SCALE grows and consequentially use of TrueCharts grows, this divide between support theories is going to become a problem.

We always aim to look into issues our users report if they are related to our works. We just don't accept support tickets for all of them, as our support staff aren't necessarily our developers.

...

As you've not even taken us up on our offer to go over it with the developer initially, there is nothing more we can do for you.
We wish you the best finding a project and/or company that can offer the a better depth of service for free!

I'd love to believe this. But, as you can see above the actual experience can fall way short of this characterization.

 

[truecharts]

We're sorry about the fact our responses to your original ticket wheren't clear for you and you've (potentially) damaged your setup because of that. That's not our goal and definately something we are working on to improve.


We're not going to respond on community issues from other communities. Primarily because this isn't relevant to this forum, nor give a balanced contextualised view of any situation.
We do want to highlight the fact above converstation is part of the less-moderated "rants" channel, for less... "tastefull" discussions to take place.

That being said:
I think it's pretty clear that this topic is not actually about the qualityor support of our Apps, but more about the personal preferences and feelings of @indivision

 

[DaSnipe]

Reddit - Dive into anything

www.reddit.com

You might need to stick to more commercia stuff, less features and slower / more stable updates, might need to stick to Core or a VM or something. Things break, even on the TrueNAS side, windows side, etc

I saw the exchange on the Discord, people get heated when things break, sorry to see, but it's going to happen, and I see the unhappiness even here, Reddit, etc. Volunteer projects working on donations verus a company that has an image to maintain will have different ways of working.

My install was also pretty close in 15. It finished booting. But, some network issue was introduced that caused a 502 gateway issue. Another user DM'd me saying that they had the same issue. So, it wasn't just me.

But, when I brought it up they just moved to shut down communication entirely, said it wasn't supported and that I shouldn't use cloudflare. Which is strange because the setup videos I followed for Traefik, from TrueCharts themselves, referred to using cloudflare and it hasn't been a problem with any chart I've used for months.

In any case, people are getting the wrong impression if they think I'm insisting on anyone changing what support they do. This was a test run. I had hoped I could trust using Nextcloud via TrueCharts. But, it's better to find out that I cannot now than down the road in more critical use.

 

[indivision]

We're sorry about the fact our responses to your original ticket wheren't clear for you and you've (potentially) damaged your setup because of that. That's not our goal and definately something we are working on to improve.

Thank you.

We're not going to respond on community issues from other communities. Primarily because this isn't relevant to this forum, nor give a balanced contextualised view of any situation.

Please. By all means point out any context I have left out that is important.

We do want to highlight the fact above converstation is part of the less-moderated "rants" channel, for less... "tastefull" discussions to take place.

This is the same channel where I was kicked for a week for writing something way less personal than the quotes above.

That being said:
I think it's pretty clear that this topic is not actually about the qualityor support of our Apps, but more about the personal preferences and feelings of @indivision

The whole thread is about the quality of your support. Anyone can see that I initially left out details of the communication today until you brought it up.

But, it's all relevant to users of these systems.

 

[indivision]

Reddit - Dive into anything

www.reddit.com

You might need to stick to more commercia stuff, less features and slower / more stable updates, might need to stick to Core or a VM or something. Things break, even on the TrueNAS side, windows side, etc

I can manage. In fact, I have already fixed my Nextcloud install on my own.

"Things break" just isn't really complete enough of an answer for critical applications. There needs to be a clear understanding about what the path forward will be when they do break. Who is going to fix what. How much support/information can someone expect regarding updates. Etc.

If the answer at TrueCharts is that you can't rely on an app to work unless you hire expensive staff to fix it, that's fine. Seems pretty important for people to know before making long-term decisions, right?

I saw the exchange on the Discord, people get heated when things break, sorry to see, but it's going to happen, and I see the unhappiness even here, Reddit, etc. Volunteer projects working on donations verus a company that has an image to maintain will have different ways of working.

I'm familiar with this. I am a developer myself. I have been managing other developers and support staff as well for many years. On both paid and free software projects.

When it comes to support, it makes a big difference whether or not the staff understands that (free or not) users are wanting to trust them.

 

[truecharts]

I can manage. In fact, I have already fixed my Nextcloud install on my own.

Great to hear!

"Things break" just isn't really complete enough of an answer for critical applications. There needs to be a clear understanding about what the path forward will be when they do break. Who is going to fix what. How much support/information can someone expect regarding updates. Etc.

With the planned documentation overhaul, we're planning to more clearly document support expectations and limitations.

We've not seen many (any?) opensource helm repository document such guarantees at all though, so it's more a problem with expectations than with our project specifically.

If the answer at TrueCharts is that you can't rely on an app to work unless you hire expensive staff to fix it, that's fine. Seems pretty important for people to know before making long-term decisions, right?

We're an OpenSource project, not a company. Even so we've setup some streamlined support experience for free.
Then, even if your specific issue is out of scope of support, often our developers jump in the fix it and/or the community does on one of the not-support-staff-managed channels.

You can expect minor and patch versions (last two version digits) to be expected to be "non-breaking" and the first digit to be "potentially breaking", often with specific migration instructions available. But it's software: Things do break with updates and it's not always 100% known beforehand what might break for every specific usecase.

That's the case with every piece of software, even TrueNAS itself.
In our case: Sometimes it gets fixed by our developers, other times it's an upstream issue and often our Support staff is very capable to filter that out and our developers very eager to fix your things.

But:
It's all volunteer effort. Not a company.
There is no formal guarantee for anything, you're not a customer, you're a user and/or community-member.

I'm familiar with this. I am a developer myself. I have been managing other developers and support staff as well for many years. On both paid and free software projects.

When it comes to support, it makes a big difference whether or not the staff understands that (free or not) users are wanting to trust them.

You're getting code, time and effort for free.
It makes a big difference whether or not the user understands that those people actually want to help them.

Just as we are not entitled for your trust (and are sorry for breaking that trust when we broke your install on 14.x.x earlier), you're not entitled to our effort to help you out.

If you want to be entitled for support, which we feel is the case here, you need to hire someone to do that for you. If you want to depend on volunteer projects, you might sometimes not-get the support you want. That's, sadly enough, a common theme in OpenSource.

While we do aim to give a good support experience and help out whenever we can, if you really need to depend on support of OpenSource projects, you are putting yourself in a bad place. Because when you don't pay people and demand things from them, they might be less inclined to offer it when there is no obligation to do so.

 

[indivision]

With the planned documentation overhaul, we're planning to more clearly document support expectations and limitations.

...

While we do aim to give a good support experience and help out whenever we can, if you really need to depend on support of OpenSource projects, you are putting yourself in a bad place. Because when you don't pay people and demand things from them, they might be less inclined to offer it when there is no obligation to do so.

I've already addressed these points multiple times now.

I wasn't acting like a customer or demanding anything. I know that some people do those things because I've been on the other end of that myself. But, that is not what happened with me and has no relevance here.

Just the opposite, I've managed support staff who become seduced by the "powers" they have as moderators and are inclined to abuse them. Sometimes its because they are having a bad day or have other personal issues. Other times it's because they want to avoid certain support processes they don't like doing. I don't let them persist in these behaviors because it damages the community over-all. I think you should consider the same.

Notably, the quotes I provided above were in response to another user who was communicating the same concern I am.

 

[truecharts]

Just the opposite, I've managed support staff who become seduced by the "powers" they have as moderators and are inclined to abuse them. Sometimes its because they are having a bad day or have other personal issues. Other times it's because they want to avoid certain support processes they don't like doing. I don't let them persist in these behaviors because it damages the community over-all. I think you should consider the same.

Notably, the quotes I provided above were in response to another user who was communicating the same concern I am.

While we understand your concern, we're not going to comment on quotes or community related issues outside the community they belong.

We do like to note that the suggestions you throw-up about our staff, are uncalled for.

 

[indivision]

While we understand your concern, we're not going to comment on quotes or community related issues outside the community they belong.

And I think that goes a long way toward reinforcing the concerns I have expressed here.

We do like to note that the suggestions you throw-up about our staff, are uncalled for.

I provided quotes from discord that clearly show that they are called for.

 

[truecharts]

And I think that goes a long way toward reinforcing the concerns I have expressed here.

Our formal statement about this is as follows:

We're always open for feedback and, as a project, welcome it gladly on discord or via email. With a preference towards discord, as we prefer feedback be given in a way that other users can also respond.

This feedback might lead to changes of policy and culture, as it has done many time by now. However, that's not guaranteed.

Our staff members, besides their duty as staff, also, just like any user, have the right to have and voice opinions. Some of those opinions might not-be in line with our views as project or staff-team as a whole.

On the other hand, we're not going to go over statements made by users (staff, founder or otherwise), making all sorts of official statements at the expense of real people.

We do not find it reasonable to burden other communities, with a discussion about our community. It's an internal staff policy of ours not to do so, for quite a while and not limited to this case.

We want to make clear, that this policy is also in-place to respect the privacy of banned users. More often than not, banned users, do not want to disclose the actuall ban reason and we find it bad-practice to name-and-shame bad behavior of our (past) community members.

Everyone is free to build their own opinion of our project, staff and community. Just as they are free not to use any of it.
We would advice people, however, to do so based on their own experiences and testing.

 

[indivision]

We do not find it reasonable to burden other communities, with a discussion about our community. It's an internal staff policy of ours not to do so, for quite a while and not limited to this case.

I don't have this policy personally. I think that it should be discussed because it's a significant factor for users making long-term decisions about apps they may need to rely on in the future.

I would discuss it at the TrueCharts discord. But, my ability to do so was removed. Additionally, it has become clear that a commitment to civility, reasonable rules and moderation are not meaningfully enforced there. So, I don't trust that it's a place where even productive, two-way communication can happen. Let alone troubleshooting efforts where stakes can be even higher.

I hope that this changes over time. I guess it might take another 20 people like me voicing the same thing. I've personally witnessed at least 3 others doing so already.