Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Better controls for bundle managers

A topic by DriftWare created Jul 30, 2023 Views: 634 Replies: 17
Viewing posts 1 to 6
(+9)

It would be nice if bundle managers had more control over their bundles. Right now, we can't even remove people from the bundle who won't approve and are just wasting everyone's time. Right now, the only way to do things like remove bundle members or convert jams to bundles is by contacting itch.io support, which is very untimely seeing as support has a bunch of things to handle besides bundle requests. It would streamline the process if there was simply a bundle dashboard or even a couple of buttons on the bundle page to do these things. Thanks for your consideration, 

DriftWare

Pinned ReplyAdmin (2 edits) (+1)

All participants must approve to the entire bundle. We don’t allow you to change anything about the bundle after you’ve sent the page out for approval because you could change the bundle in a way that would violate the expectations of the people in the bundle who have already approved.

So, if you need to make substantial changes then you will need to create a new bundle and have everyone re-approve it. If the changes are minor then you may contact support and they can see if they can adjust the bundle in a fair way.

That said, though, there are definitely a few minor things we could change to streamline some tools for bundle hosts, but the guiding philosophy regarding bundle edits will remain the same.

Hope that makes sense

(+1)

this is a terrible decision to be honest. I agree. Changing stuff like Price after people already approved should not be allowed. But requiring people to recreate the whole bundle due to one person not approving it, is bad. People should be able to either leave the bundle and automatically delete themselves in that moment, or allow the bundle creator of purging people from the bundle who did not approve. 

The current state of the approval process just allows certain users to use the approval process to annoy everyone else. 

And it would NOT hurt itch.io if people can leave a bundle they do not approve. This would save your mods tons of work.

(+1)

Removing members from the bundle should definitely be something that bundle managers should be able to do. Changing the price wouldn't have to be part of that, but it's a pain to remove low effort creators and people who won't approve.

I completely agree. And basically: Yes, you are allowed to decide to NOT Join a Bundle if you do not want to. But they should not be allowed to cause trouble for everyone else who actually wants to join the bundle. And should not be able to hold the bundle "hostage" in a way.  Basically, admins need the rights to either delete people from the bundle who do not want to join, or there needs to be a function of auto deletion.

And it does not infringe on my rights if another person is thrown out of a bundle due to that person not approving. The only thing which then might happen to me is that the price needs to divided through less participants, thus I get more money. 

I agree. Some aspects like pricing or bundle descriptions should not be changeable after people approved. Because these bear abuse potential, But the function of purging non approving people does not belong to this problem.

(+1)

I honestly think that if there was auto-deletion, it could just automatically change the distribution between creators when it removes members.

Admin (1 edit) (+1)

There are many scenarios where removing one or many participants may substantially change the line up of the bundle in a way that may be misleading to the other participants. I could imagine us adding something in the future that lets you remove participants if it represents under a certain percentage of the total bundle.

A follow up question I have is why are are there people in the bundle you have organized who don’t end up approving the bundle? Were random people added with the hope that they would participate?

I can’t imagine why you would see the approval process as a means to “annoy” others unless you’ve invited untrustworthy people to the bundle.

(+1)

The 2 bundles where I saw people refusing to accept the bundle later had basically the following scenario: (i did not host them.)

The admin made a game jam where everyone could submit games to the bundle if they liked. It was stated that everything submitted will put into the bundle after a certain date. In both cases, people submitted their stuff to the game jam, then waited for the bundle host to create the bundle, waited that more than 50 percent accepted the bundle, and then publically stated they wanted to get out of the bundle. These persons had plenty of time to leave the bundle beforehand, but instead, they decided that they wanted to leave the bundle at the time when it would cause the most trouble for everyone else involved. 

This is what I meant by "to annoy other people"

(+2)

He did never add random people to any bundle but had people who wanted to join actively submit their stuff.  Everytime. And the people who refused to accept actively submitted their stuff. But extremely later, they changed their decision. (They changed their decision exactly at the moment where it was the most complicated to reverse it.) 

(+2)

This indeed what happened.

(+2)

yes

(+1)

I agree with you bro !

One small thing: it’s impossible to edit a bundle’s url. I appreciate this feature so that the url of games whose funny typography (like, francophones) is deleted from the url can still be searched in browser history and understood (a small accessibility feature)

So, are we getting changes or are we just getting blown off?

What’s the use of being rude?

Because the dev's generally don't seem to care about qol improvement for their clients.

Explaining the reasons for your instatisfaction doesn’t answer my question.

But I see you’re a client of itch. As I’m just enjoying it for free, I don’t have the same expectations.