Please note: This is my opinion, based on the information currently available and my experiences so far.
I am aware that this is currently an idea and not finished/fully functional.


I've seen some big modding queues before, and almost all of them failed because the modders were overwhelmed by the high number of requests.
But, there were also functioning ones, the Christmas queue being a prime example.

WideBrezzi wrote:

Once a beatmap gets accepted by enough modders it'll automatically get removed from the queue.

This might never happen for some maps, as preferences or the map itself might not be to the liking of many modders.
This would likely result in a list that goes on for ages in the worst case, so there should also be a time limit for a request to be displayed, like a max time of 30-45 days after submitting the request.

Also, how exactly would you get a count for how many modders have accepted a map, and what is "enough"?
For the first part, I'd assume you would make a login available with a button for modders to click on. (like osump for example)

The second part, "enough modders" is what bothers me, seasoned mappers might only need a hand full of people to look at a map before they go to a BN, for less experienced or totally new mappers with zero experience the number of mods needed could differ a lot.
Also taking into account that modders have different levels of experience themselves.
One modder might accept something and puts in a lot of posts in the discussion tab.
Another modder accepts but due to a lack of experience is only able to make a single comment that might also not be helpful at all.

In my opinion, (due to the above-mentioned points), needing a total of 3 is too low of a threshold for a request to be done.
Suggestion, put it at 5 by default and put a dropdown option for the mapper to select the number of mods (from 1-10 I guess)
Also, how would hybrid sets (more than one mode) be handled?
Perhaps like this? {osumode_symbol}: 2/5 | {catchmode_symbol} 1/5

WideBrezzi wrote:

Yow won't have to bother with rules or preferences

Absolutely no rules could result in maps being posted that have no business in a modding queue, so basic rules should be present for the queue. (Map must be finished, no aspire/2b or other unrankable maps, beatmap set must be your own/you need to have a GD present in the set)

WideBrezzi wrote:

You'll always get new maps on your feed based on your preferences

Always on your feed based on preferences, can I understand this as some sort of notification system? (website only)
Like "{username} requested a mod for {song} with {prefered genre}" (Just an example)
If that would work, that would be nice, but that also brings me to a problem which especially new mappers sometimes face.
Getting Tags and Genres correct or having them in the map (tags) in the first place. If you'd fetch those from the map itself, it might result in some requests not having any of those filters applicable.
You'd need to have a selection present at the stage where the mapper submits the request, with at least 1 selection required for Genre/Language/Style, possibly with a tooltip that shows up when hovering over those.


Those are my thoughts about this so far, I may edit this at a later date with "Edit: {date}" as a marker.

Because of my inexperience I can't fully flesh out all of the operational aspects of this project myself. I hope to discuss/test these with more experienced individuals once I have a working prototype done.

Kinmiri wrote:

but IF this actually becomes a thing, it could have too many requests and would probably wont get mods at all if u dont post it in someones queue instead

Jason X wrote:

I've seen some big modding queues before, and almost all of them failed because the modders were overwhelmed by the high number of requests.

Not much I can do about this. It largely depends on the mapper to modder ratio using my website. We'll just have to see how it goes. If this actually becomes a problem maybe I can incentivise more modding by prioritizing maps (setting them higher in the queue) from people who also mod on the website (some point system or something...)

Jason X wrote:

This might never happen for some maps, as preferences or the map itself might not be to the liking of many modders. This would likely result in a list that goes on for ages in the worst case

Yes, there will be a time limit exactly like you suggest.

Jason X wrote:

Also, how exactly would you get a count for how many modders have accepted a map, and what is "enough"?

There will be a OAuth login required for both submitting and modding a map. Modders will click to accept a map.
Number of mods requested will be selected by the mapper (exactly how you suggested).

Jason X wrote:

Also taking into account that modders have different levels of experience themselves.

That could be solved by reserving a slot on every map to modders with more experience (determined by amount of kudosu for example)

Jason X wrote:

Also, how would hybrid sets (more than one mode) be handled?

I'm thinking of handling every difficulty of a mapset as it's own request. Each difficulty of any mode will have it's own "slots" for modders to fill in. The modder won't have to accept all difficulties.

Jason X wrote:

Absolutely no rules could result in maps being posted that have no business in a modding queue, so basic rules should be present for the queue.

Some basic rules yes. But the website should also be open to new mappers who are still learning, and ranking is not the main point of their maps atm. These could get separated into categories when submitting (like a dropdown of what the intent of the map is: "Ranking", "Feedback", and possibly more...)

Jason X wrote:

Always on your feed based on preferences, can I understand this as some sort of notification system?

I worded this inaccurately. I meant always new maps in the queue filtered by their preferences. But a notification system is a great idea which I'll probably integrate into the website.

Jason X wrote:

Getting Tags and Genres correct or having them in the map (tags) in the first place. If you'd fetch those from the map itself, it might result in some requests not having any of those filters applicable.

There will be selections to fill out when submitting. Genre / Language will be fetched from the map itself, and maps without these filled out will be rejected, and the mapper instructed to fill these out, before submitting.

There will be a need for some sort of moderation to remove maps submitted with incorrect information. Possibly a reporting system, that automatically removes maps that get some threshold of reports (like 5 for exmaple). Such a system could get abused though.

WideBrezzi wrote:

There will be a need for some sort of moderation to remove maps submitted with incorrect information. Possibly a reporting system, that automatically removes maps that get some threshold of reports (like 5 for exmaple). Such a system could get abused though.

Automated report & removal systems are prone to abuse, this sort of abuse could be circumvented by having volunteers look at reported maps and confirm or deny the report.
Such Volunteers could be selected from active modders using the website.
If a point system (see quote below) becomes a thing this might be a base from which to seek out volunteers (other than those offering to help directly).

WideBrezzi wrote:

maybe I can incentivise more modding by prioritizing maps (setting them higher in the queue) from people who also mod on the website (some point system or something...)

The point system could be handled like kudosu was in modding v1, a modder got 1-2 kudosu from a mod, and this could be converted into star priority for one's own or someone else's map, pushing them higher in the priority list.
Kudosu
Star Priority

Suggestion: 5 points total

1. 1 point for modding any diff in the requested set.
2. 3 points for modding 50% of the diffs in the set.
3. 5 points for modding all diffs in the set.

This suggestion is of course not ideal, as this can't really be applied to every set as is, some sets are single diff and hybrid sets should also be handled differently.