Standing Firm against MC-Market's decision against resource authors

[Ghast]

Understanding the rules of MC-Market and its marketplace is one thing. Understanding the ethic and the decisions of its staff team is another. Over the period of the last 1 and a half year, MC-Market has continuously been unclear in its actions against the Cubed Team. I would like to now shed some light on the situation.

What led to this being made

As of yesterday, the MC-Market staff team decided to take down half of our setups available on the front page and to remove nearly every single existing update to said setups. The reasoning behind such action was justified with the following message:

Here’s my rebuttal


Exhibit A: The rules

The rules concerning the MC-Market marketplace are as follows:

RESOURCE RULES
The following rules apply to the use of MC-Market's resource system
6.1 Do not submit resources whose download is not and does not function as described.
6.2 Do not attempt to distribute services, external links, or ads via resources. Your download must contain the product.
6.2.1 Do not offer or require external assets/dependencies to your resource without providing a publicly accessible link to it within the resource description.
6.3 Do not miscategorize your resource.
6.4 Do not submit resource files which contain malware, viruses, or any other malicious program or script.
6.4.1 Do not submit resources so low in quality that it could potentially harm any of our members’ hardware/data.
6.5 Do not submit resource updates which do not contain significant improvements, with the intention of bumping.
6.6 Do not include content which you do not have the right to redistribute.
6.7 Do not violate our resource review policies. (Read more)

The most interesting bit we’ll be reviewing just now is the following:

6.5 Do not submit resource updates which do not contain significant improvements, with the intention of bumping.


Understanding this particular meaning of “significant” is the center of this dispute, hence I’ll try my best to debate where we as a team stand.

Making setups is a tedious arduous process. It’s long, frustrating, messy and can often be met with lots of issues with plugin incompatibilities, bugs and such caused directly by the plugin providers. Updating plugins is an extremely important task to have when operating such a business as it allows for the newer buyers to have everything as up to date as possible. The last thing you’d want when purchasing a pre-made setup is to run it and to enter the game with dozens of console messages stating “PLEASE UPDATE TO THE NEWEST VERSION”.

As the individual who provides support for said setups, such demands for updates have been brought to light on several occasions. Setups are a drag, drop and play, not a tedious process of updating everything after having spent a decent amount of money on a pre-compiled configuration.

Not to mention, plugins can also be custom. In the case a plugin is said to be custom, it would be normal to update the entire setup alongside it.

The decision to nit-pick this rule as “plugin updates are not a significant improvement” is as feeble as an opinion. It does not stand as sufficient backing to decide to shut down the entire operations and push onto our team 6 hours of work the staff team decided to take upon themselves. If you wish to warn us, so be it, it’s your site after all. However, the decision to limit our resources is truly the most pathetic.


Exhibit B: Nit-picking

I’ll let these screenshots speak for themselves:
All I can say now is “Nice enforcement of your guidelines. I’m sure everyone’s being treated in the same way!”

I hope my argument sheds a bit of light on this sheer silly and completely ridiculous decision on behalf of the staff team. Make some changes, for the better.

 

[Ally]

Updating a plugin from 1.0.0.0.....0 to 1.0.0.0.....1 is an insignificant update.

Unless the plugins makes breaking changes -- in which case you should ALWAYS notify the purchasers of your resource -- most plugin updates you put in there will be minor. Why wouldn't you be able to wait until at least a few, presumably active, plugins are updated and then release your update?

Not to mention the intention of using a setup. Who buys a setup and uses it, only to have to download it again and update each changed file manually? Unless I'm missing something, a setup is meant to set up a server. In which cases, again unless there's a breaking change, server owners can update manually.

Also with your 'nitpicking', report the resource. Like posts, RMs won't see every single resource, even less so if they're not reported. The rule is definitely enforced.

 

[solo]

This is ridiculous, I see people doing this with almost every setup how come they're only enforcing it on you lmao wtf?

 

[Ghast]

Updating a plugin from 1.0.0.0.....0 to 1.0.0.0.....1 is an insignificant update.

Unless the plugins makes breaking changes -- in which case you should ALWAYS notify the purchasers of your resource -- most plugin updates you put in there will be minor. Why wouldn't you be able to wait until at least a few, presumably active, plugins are updated and then release your update?

Not to mention the intention of using a setup. Who buys a setup and uses it, only to have to download it again and update each changed file manually? Unless I'm missing something, a setup is meant to set up a server. In which cases, again unless there's a breaking change, server owners can update manually.

Also with your 'nitpicking', report the resource. Like posts, RMs won't see every single resource, even less so if they're not reported. The rule is definitely enforced.

No one usually downloads updates from setups. The purpose of the update is to provide the latest content to newer buyers.

 

[Gambler]

Atleast someone is shedding light on this situation. Thank you!

 

[Harry]

Updating plugins contained within a setup does not constitute sufficient improvements. You don't put any effort into the update when you do such. You simply download a newer version and copy/paste the plugin's own changelogs into your update post. If the purchaser wants to keep their plugins updated, that's their choice to do so. It's not your responsibility to keep the plugins updated provide your setup still functions as described (which it will if you never post further updates), so such an argument truly collapses.

I cannot see us ever changing this enforcement unless we want to see low-effort updates spammed across our resource system.

The harsh enforcement here was a result of the inordinate numbers of violating updates, along with the fact that your business account member, FrogsLegs (who maintains these setups as far as I'm aware), has previously been warned regarding this. The fact that such updates are not considered significant was very clearly explained to him back in July of 2020, yet your Cubed business account has consistently violated 6.5 since even after the warning/explanation given.

This is not selective enforcement. Simply report violating updates by other authors and they will be removed. Just because you see other resource authors doing this as well doesn't mean we allow it.

Further, our resource system allows you to publish a new version of your resource without actually making an update post, thus the update post won't bump your resource, thus you can't be warned for rule 6.5. Simply leave the "Update title" and "Message" fields blank on the Post Resource Update page.

 

[Kjell]

It's indeed absolutely insane how this is handled if there are so many resources that do this but a whole team is being brought down with it instead of the other authors out there as well. (Not saying this rule should even be a thing)

The whole point of these "minor" chances is making sure to bring quality to a setup, just one minor change in one plugin of the whole setup can stop the whole thing from working.

If this rule is to be applied to resources, mc-market staff should make an announcement about it and do something about it themselves instead of wasting time. I know this rule has always been there but it seems like the team is enforcing it since today lol.

 

[Geek]

I've said this before on different issues and I'll say it again. We are one team of 16 people who try and dedicate lots of time out of our personal lives to moderating a site of over 240,000 (yes lots are banned, not the point). Of the 16 people who are on the team, 2 of them handle resources and work their butts off to make resource approvals, reports, and lots more behind the scenes stuff flow seamlessly and quickly.

I can assure you, we do not say "Ah Ghast looks especially yellow today, let me warn him", nor do we have a warn quota or anything to that nature. Quite simply you, the community, report each other relentlessly and that's how we are able to see the violations. In the past month or two, I can name off the top of my head around 6 people who claim to be "hard" and "not a snitch", yet they are the ones who are reporting the most (usually all in fact violations) and they are also the ones who are complaining in shoutbox. You can't have it both ways. We try our hardest to moderate without reports because it's true that there are things that get away because people don't want to report the OP because of friendship or something, but we can't see everything.

We quite simply don't have enough time in the world or enough bodies to effectively moderate every single resource update that is posted to the site daily. Additionally, there have been suggestions that updates be put under moderation for approval similar to publishing a resource. This is also not a feasible option. As it stands, our two resource moderators work tirelessly to get resources approved as quickly as possible. If we were to add resource updates to their list is duties to approve, your wait time would triple if not quadruple or more.

As Harry has stated, if you see content that is violating our rules report it. This brings it to the forefront of our attention and we can moderate it much more effectively. Additionally, if we notice common trends we can start a discussion about how to more effectively handle those trends. Additionally, consider just doing all your "minor changes" in one large update. I personally am a fan of Notion which allows you to make a Trello like board to track updates, progress, bug reports, etc. If you use a VCS such as Github, there's also their own built-in Trello like system. Consider using these to make larger bug fixes/minor changes updates; an update that would properly increment the build number 1.0.0 -> 1.1.0

 

[Ghast]

Further, our resource system allows you to publish a new version of your resource without actually making an update post, thus the update post won't bump your resource, thus you can't be warned for rule 6.5. Simply leave the "Update title" and "Message" fields blank on the Post Resource Update page.

When this ever mentioned..., ever?

 

[Jenss]

I've said this before on different issues and I'll say it again. We are one team of 16 people who try and dedicate lots of time out of our personal lives to moderating a site of over 240,000 (yes lots are banned, not the point). Of the 16 people who are on the team, 2 of them handle resources and work their butts off to make resource approvals, reports, and lots more behind the scenes stuff flow seamlessly and quickly.

I can assure you, we do not say "Ah Ghast looks especially yellow today, let me warn him", nor do we have a warn quota or anything to that nature. Quite simply you, the community, report each other relentlessly and that's how we are able to see the violations. In the past month or two, I can name off the top of my head around 6 people who claim to be "hard" and "not a snitch", yet they are the ones who are reporting the most (usually all in fact violations) and they are also the ones who are complaining in shoutbox. You can't have it both ways. We try our hardest to moderate without reports because it's true that there are things that get away because people don't want to report the OP because of friendship or something, but we can't see everything.

We quite simply don't have enough time in the world or enough bodies to effectively moderate every single resource update that is posted to the site daily. Additionally, there have been suggestions that updates be put under moderation for approval similar to publishing a resource. This is also not a feasible option. As it stands, our two resource moderators work tirelessly to get resources approved as quickly as possible. If we were to add resource updates to their list is duties to approve, your wait time would triple if not quadruple or more.

As Harry has stated, if you see content that is violating our rules report it. This brings it to the forefront of our attention and we can moderate it much more effectively. Additionally, if we notice common trends we can start a discussion about how to more effectively handle those trends. Additionally, consider just doing all your "minor changes" in one large update. I personally am a fan of Notion which allows you to make a Trello like board to track updates, progress, bug reports, etc. If you use a VCS such as Github, there's also their own built-in Trello like system. Consider using these to make larger bug fixes/minor changes updates; an update that would properly increment the build number 1.0.0 -> 1.1.0

1: That ur doing this in ur own time is ur own fault. You decided to accept this “Job”

2:Reporting doesn’t help, I’ve reported plenty people that are ban evading and end up scamming people.

3: time is ur problem not ours. Ask ur boss to hire more people

Updating plugins contained within a setup does not constitute sufficient improvements. You don't put any effort into the update when you do such. You simply download a newer version and copy/paste the plugin's own changelogs into your update post. If the purchaser wants to keep their plugins updated, that's their choice to do so. It's not your responsibility to keep the plugins updated provide your setup still functions as described (which it will if you never post further updates), so such an argument truly collapses.

I cannot see us ever changing this enforcement unless we want to see low-effort updates spammed across our resource system.

The harsh enforcement here was a result of the inordinate numbers of violating updates, along with the fact that your business account member, FrogsLegs (who maintains these setups as far as I'm aware), has previously been warned regarding this. The fact that such updates are not considered significant was very clearly explained to him back in July of 2020, yet your Cubed business account has consistently violated 6.5 since even after the warning/explanation given.

This is not selective enforcement. Simply report violating updates by other authors and they will be removed. Just because you see other resource authors doing this as well doesn't mean we allow it.

Further, our resource system allows you to publish a new version of your resource without actually making an update post, thus the update post won't bump your resource, thus you can't be warned for rule 6.5. Simply leave the "Update title" and "Message" fields blank on the Post Resource Update page.

biggest bullshit I ever heard. So you have to leave people behind with outdated plugins? Lmaoo

 

[Note]

1: That ur doing this in ur own time is ur own fault. You decided to accept this “Job”

2:Reporting doesn’t help, I’ve reported plenty people that are ban evading and end up scamming people.

3: time is ur problem not ours. Ask ur boss to hire more people



biggest bullshit I ever heard. So you have to leave people behind with outdated plugins? Lmaoo

As Harry said above, you are able to publish a new version of the resource without posting an actual update.

 

[Ghast]

Update

Seems that on top of receiving a warning for updates, we received a warning for... you guessed it... no of course you didn't. Spam. Yes. Updates are now spam.

Spoiler: img

 

[Harry]

When this ever mentioned..., ever?

It's not; it's a known feature of XenForo's resource manager add-on. But honestly, there shouldn't be any reason to use it. You should be posting the plugin updates within a larger update to your setup which does contain your own significant improvements.

Please be aware that we could've issued 2 warning points per violating update, and with the number of violating updates posted by your business account in the hundreds, FrogsLegs could've been banned in an instant for excessive rule violations. Instead, because we are reasonable, we issued a single bumping warning and a spam warning.

Had you simply opened a support ticket or PMed me rather than overreacting, this all could've been very easily explained to you.

It does not stand as sufficient backing to decide to shut down the entire operations and push onto our team 6 hours of work the staff team decided to take upon themselves.

The content is rule-violating. It was not our decision to post it, and it would take too long for us to remove it manually. Thus, it falls on you to remove it unless you want to delete the resource entirely and resubmit it.

Would you rather me spend six hours of my time continuing development on our API, of which I know you're very keen to see implemented, or spend that time deleting resource updates?

 

[Ghast]

Had you simply opened a support ticket or PMed me rather than overreacting, this all could've been very easily explained to you.

Alas if I ever had gotten a proper agreement with the team in the past concerning any of the trouble that came my way, I'd perhaps have stuck with doing such. Instead, I, unfortunately, have to resort to measures such as a suggestion in order to make this seen by the team.

As for the 2 warning points per violating update, you're missing the point. The issue here is where to draw the line between bumping and reasonable. You're blurring what is and what isn't a correct update, and hence due to the volume of updates we publish it most definitely grasps more the attention of the team towards us rather than towards individuals that may as well be violating said rules.

The content is rule-violating. It was not our decision to post it, and it would take too long for us to remove it manually. Thus, it falls on you to remove it unless you want to delete the resource entirely and resubmit it.

You're putting this burden on yourself and on us. There's no need to remove the updates, they've already been published, and these are not harming anyone. Most definitely, they're not about to magically bump themselves. Hence, I don't even see why their removal is needed in the first place. You could have very much just warned us and carried on with the works with said API in the first place if you hadn't gone as far as requiring us to republish half our setups.

 

[Kuchy]

I'm a little on the fence on this enforcement. Usually, I see eye-to-eye to the enforcement by the staff team as I've been there and I know how the conversations go. The team will not hesitate to ask one another should something be unknown or confusing. They are a team and as a team, they work together.

In terms of this enforcement, I'm a bit confused as to why resource authors who keep their resources up-to-date might be punished for updating the contents within them? What if the plugin needed updating broke the resource itself? Then we're not dealing with 6.5 but 6.1 which is 1 point more and lasts significantly longer. Sure the buyer can update the plugin manually but that doesn't change the fact the resource is no longer adhering to 6.1, which can get that author warning points. If I download a setup, I'd like to use it out of the box. If I see a bunch of "out of date plugin" in console, I'd be a bit annoyed that nothing is updated. I definitely would be leaving a 5 star review as it was inconvenient for me. One or two out of date plugins I wouldn't fuss over though. I'd like to see eye-to-eye on this warning but I simply can't understand why Ghast was warned with the current information provided. Now if someone repeats updates within the span on 2-7 days, then I'd argue it's 6.5, especially if it's something like the first picture in Ghast's Exhibit B argument. How does one put the wrong jar twice? Seems clear the individual is rushing updates and did not test it. Same case for the last picture. Too many updates within the same week. Why not do it all at once (in this case I'm assuming the plugins were updated long before the update post date)? It's not my place to ask about Ghast's warning. That's an argument Ghast needs to handle within the warning dispute.

Ghast in terms of your "Exhibit B" argument, it's not about you. I've talked with Harry long enough and I absolutely doubt he'd sit down at his computer to target a single individual. None of the team will. They wouldn't be staff if they did. Your warning, although I don't agree with it but it happened so I'm using it as an example, could have happened to any of those individuals first. The case is about the resource, not yourself.

It's not; it's a known feature of XenForo's resource manager add-on. But honestly, there shouldn't be any reason to use it. You should be posting the plugin updates within a larger update to your setup which does contain your own significant improvements.

Not many people know about, hell I didn't even know about it. With how the warning was given, it seems there should be a reason to use it now.

Jenss, your agruments just make me come to the conclusion you strongly dislike the team.

1: That ur doing this in ur own time is ur own fault. You decided to accept this “Job”

2:Reporting doesn’t help, I’ve reported plenty people that are ban evading and end up scamming people.

3: time is ur problem not ours. Ask ur boss to hire more people

In response to 1, yes it's their time but by taking the time, let's use Harry as an example, out of Harry's day to go through spam, he would be able to go through the resource moderation queue. If everyone simply adhered to the rules that wouldn't be an issue and I'd see less questions on "When will my resource be approved?" Plus less threads like this (again, I didn't agree with the warning but I'm simply speaking figuratively).

For 2, I'm not sure how things are being ran now, I doubt they've changed, but when I was staff, reporting does work. If there's substantial evidence of a user ban evading, then they will be banned. I'm not sure how big the queue is now but the staff team will get to it if they haven't already.

For 3, they recently had open applications. Those who were accepted, like sir Note, are already at their jobs. They can't start every new member at the highest level. Experience needs to be built and putting a person with zero experience on the front lines is a cause for disaster.


The rule is needed but I question on whether it was valid for Ghast's case. That discussion doesn't need to go through me as it's Ghast's warning dispute. I simply provided my take on it.

 

[Emissions]

Updating plugins contained within a setup does not constitute sufficient improvements.

But it does ensure that when someone new buys the setup they don't have to waste their time updating the plugins.
A setup is a collection of plugins, if a plugin needs an update then it should be updated.

 

[Note]

But it does ensure that when someone new buys the setup they don't have to waste their time updating the plugins.
A setup is a collection of plugins, if a plugin needs an update then it should be updated.

They can ensure new players have the updated plugins by publishing a new version of the resource instead of an update post.

 

[Ghast]

They can ensure new players have the updated plugins by publishing a new version of the resource instead of an update post.

Already discussed it with you. Feature wasn't known before this incident.

 

[Justis]

From what I see, Ghast was right in pointing out the presence of an issue here. While there are concerns which prevent the simple allowance of resource updates whenever a dependency updates, I do think there are some software changes which can be made on our end to address everything.

Problem: Limited space on our storage servers
MC-Market stores all past resource versions, even deleted ones. Primarily for the sake of ensuring that if there is a scam report, or a report of any kind, that we have viable records for processing that report. Allowing all of our setup authors to re-upload their entire resource simply to update a very small plugin file, when that update provides no bug fixes or feature changes, would be extremely costly in the long term, especially because of how large setups are and how much data becomes duplicated.

Solution: Completely replace our resource software
It would require a total overhaul, but we could replace our resource software, which currently stores each version of a resource as its own individual file, with software that stores resources as file changes. So you have your original upload in its entirety, then your next update, which may change only a few files, only stores those changed files as well as an internal record of exactly which files need to be present/excluded for that update. When someone downloads, that internal record is checked and the downloader is provided a compilation of files present across past updates which correspond to what has been added or removed.
I’m thinking that the best way to ensure we’re not causing undue load on our servers would be to allow resource authors to open up a panel that displays their resource contents, and then manually choose to update/exclude/add specific files, rather than updating the entire resource.


Problem: Unfair competitive advantage for certain products on resource landing page
Many of our resource products have a "final" version. An optimal form, where there are no bugs and no improvements to be made. It exists as it was originally intended to eventually exist as. Resources with dependencies have an advantage, because they get to update and make changes as the things they depend on update and make changes. Meaning they flood the "recently updated" list which is the resource home page, pushing all other product types to the bottom, making it difficult for them to find. This problem is infinitely more true when the updates happening to those resources are insignificant, such as a plugin included in your setup updating their readme.txt. Imagine being a hard-working plugin author who can only update their resource after weeks of working hard on adding a new feature, and then as soon as you’ve posted it, hoping to get more traffic, you’re immediately pushed off of the first page by setups who spent half a second downloading someone else's plugin update and then re-uploading it on all of their resources. It has a real and tangible effect on sales, and while it might be to the setup creator’s benefit, it’s not fair to everyone else who can’t use other people’s work as an excuse to draw traffic to themselves.

Solution: Provide a clear option for an update not to bump the resource & create an equal opportunity sorting list for the landing page that allows for bumping
We can create a clear and obvious tick box on our update page for resource authors to make minor changes to their resource files without bumping it as a product update. Moreover, and this has been discussed before, we can create a feature which will allow all of our resource creators to legitimately bump their resources, similar to how our thread authors are able to bump their threads. The creation of a default "Relevancy" sorting list for the resource page would sort based on the most recently bumped resources. This would allow all of our resource creators equal opportunity to be seen. Even resources which are in their final form would be able to continue to make the front page as long as the author was active and willing to promote it, giving them the chance to continue to compete with products like setups which update every time a plugin they use updates.


Problem: Deleting multiple versions takes too much time
Deleting a history of insignificant updates takes too much time, but not deleting them makes other resource creators think that those updates are acceptable and encourages them to do the same, even if the author was actually warned for them. The resource author was the one to upload them and it’s unfair to our resource moderators to ask them to spend an unreasonable amount of time correcting that violation for them.

Solution: Create a tool to remove "All older updates" and allow resource authors the ability to undelete updates
A simple tool that would be useful for both resource moderators and resource authors. While it wouldn’t be able to discriminate against genuine past updates and keep them, as long as the most recent update is functional, there should be no issue, and providing resource authors the ability to undelete past updates if they would like to keep them, would provide a solution to any complaints that could be made about valid updates becoming unavailable.


Obviously, the level of difficulty in implementing these changes varies greatly between them, so some solutions would take longer to develop before all of them can be deployed. However, I see what I’ve proposed as being the best for everyone concerned. Let me know if you agree, or if you think I missed something.