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.

 

[Ghast]

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 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.

Have you considered moving storage to a CDN platform? Perhaps that could come out as a more feasible and cheaper solution than what you currently may have? (eg https://bunny.net/pricing)

 

[Jenss]

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.


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.

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.

I don't really care who are in the team and I don't even know most of them. The things is that it gives the feeling that they are not doing anything and just spreading warnings to the active people on this site. I don't hate someone lol.

 

[Kuchy]

I don't really care who are in the team and I don't even know most of them. The things is that it gives the feeling that they are not doing anything and just spreading warnings to the active people on this site. I don't hate someone lol.

Ah. I see. I apologize for making that assumption.

 

[Kuchy]

Have you considered moving storage to a CDN platform? Perhaps that could come out as a more feasible and cheaper solution than what you currently may have? (eg https://bunny.net/pricing)

This is a nice idea but would this impact downloading a resource in any way? Additionally, how would it work with the placeholder system in place? Many authors use this system and I don't think they would want it to become unusable if MCM were to switch to a CDN.

I think the whole point of this rule, is pretty much 100% of resource authors makes bump updates with no file changes at all.
I.e. People saying they updated the server jar, when no new jars have been released in 1 year or more, or people using Java jargon to try and justify content when no file changes were made, FrogsLegs' resources are a great example of this.

For instances like these, I see no reason why authors who perform these practices shouldn't be warned for 6.5. However, 100% of resource authors is overexaggerated.

 

[Ghast]

This is a nice idea but would this impact downloading a resource in any way? Additionally, how would it work with the placeholder system in place? Many authors use this system and I don't think they would want it to become unusable if MCM were to switch to a CDN.


For instances like these, I see no reason why authors who perform these practices shouldn't be warned for 6.5. However, 100% of resource authors is overexaggerated.

 

[Splodgebox]

I can't say I don't agree that small updates shouldn't be allowed but at the same time, a "small update" that can be seen as just boosting could be a game-breaking bug that you have then just fixed.

The rule behind this does not make sense or is not in-depth enough to qualify and remove your resources.

I've seen this happen countless times on other sites like spigot where people will update with "Added optimisations" which is clearly just a ploy to bump their resource but at the same time, I've been in the position where I've spent hours optimising my code to then update with the same title.
I think the rules should expand and at least ask for more in-depth changelogs to remove the issue of deciding themselves if it's a ploy to bump their resource or not.

TLDR; I fully agree with Ghast but understand where MCM is coming from. They should update the rules to be more in-depth and maybe enforcing people give more details on changelogs.

Thanks for listening to my TED Talk

 

[ToastnBread]

I personally think this should only be for plugins. As the dev of the plugin is the only one able to edit the source. If someone buys a setup they should know how to work with the setup. How to edit it. Nobody buys a new car and doesnt know how to drive. Every setup I've purchased i never looked at the download page again. This is the soul reason why i dont sell setups on mc-market. Who wants to do all that work?

 

[ULTRA SETUPS]

As I see my resource reported there as bumping, I whoud like to say that most of the updates are directly asked from the users who purchased the setups, with new suggestions, bug reports, new features that they want to see and grammatical errors reported by them.
In all of my updates there is a folder named "update" where users can find what was aded in the last update so they update the setup easy and fast.

 

[Brandon]

I can't say I don't agree that small updates shouldn't be allowed but at the same time, a "small update" that can be seen as just boosting could be a game-breaking bug that you have then just fixed.

The rule behind this does not make sense or is not in-depth enough to qualify and remove your resources.

I've seen this happen countless times on other sites like spigot where people will update with "Added optimisations" which is clearly just a ploy to bump their resource but at the same time, I've been in the position where I've spent hours optimising my code to then update with the same title.
I think the rules should expand and at least ask for more in-depth changelogs to remove the issue of deciding themselves if it's a ploy to bump their resource or not.

TLDR; I fully agree with Ghast but understand where MCM is coming from. They should update the rules to be more in-depth and maybe enforcing people to give more details on changelogs.

Thanks for listening to my TED Talk

I completely agree with this - I do not think that just looking at an update message can actually give you an assumption of if there is a "significant update" or not. The only way you could see if an update was "significant" is by looking at the actual content of the resource, whether that be the config files, the code, and looking at the difference between them (alongside the update message signifying what has been done).
I'm not suggesting MC-Market introduce this as a new system, my point is that their current system is not in-depth or substantial enough to fully establish whether an update is "significant" and whether it should be removed.

As a developer, I understand that update changelog messages are often concise and just meant to give an idea of what has been done (for other developers' and your own sake), but does not necessarily signify the amount of work it took to do it. There are also times where a fairly small bug is fixed, and I would rather have that bug fix pushed ASAP despite the fact it was fairly minor - a bug is a bug and I don't believe that a resource should be left with one in simply because the update did not look "significant" enough to be published.

I agree that MC-Market should attempt to prevent users from bumping their resource with a pointless and fake update, but why not just have an "Up Resource" button, the same with posts? If this already exists feel free to correct me here, I don't publish resources on here so I have no idea if something like this is already a thing.

 

[moon10k]

lotta words in this thread, being a professional 4 year old, I think you're in the right. I feel like MCM staff tend to go a bit to hard with the small things.