Code of conduct for modding and mapping

The code of conduct for modding and mapping is a set of rules and guidelines that apply to the entirety of the osu! modding and mapping ecosystem and an extension to the osu! community rules and general ranking criteria. In order to ensure that mapping and modding discussions in threads take place in a constructive, positive and productive environment, a code of conduct is crucial to get everyone on the same page. When participating in the modding and mapping ecosystem, it is mandatory to follow this code of conduct. Misconduct that violates these rules might lead to penalties issued to your account.

Behaviour and conduct

  • The goal of modding is to help a mapper improve their work so that it can be pushed towards the ranked status if the mapper chooses to do so. If you're not interested in helping people, steer clear of the discussion to avoid hurting them.
  • When modding, consider who the post is directed at, what you aim to achieve by posting and what response you expect to receive. This will ensure your best intentions are conveyed and your post is easy to understand.
    • Don't shy away from new mappers and modders — these people are the ones who can benefit the most from your input! Be patient, understanding, and provide as much explanation as possible so that they can learn and improve more quickly
    • If you're new yourself, don't be afraid to say so! This will allow more experienced community members to point you in the right direction. Everyone was new and in your position once!
  • Treat others as you wish to be treated. People are more receptive to kind, helpful suggestions than hostile ones. Try to understand others' point-of-view rather than attack it — nobody likes to feel worthless, incompetent or stupid. If you are a masochist, assume that all others are not.
  • If you wish to comment on or discuss a beatmap, go to that beatmap's discussion page — not social media outlets, or the comment section, as it is unlikely your concerns will be heard by anyone with the power to address them appropriately.
  • Personal attacks, hateful comments, misplaced joking, derailing the thread and general drama-initiation are not acceptable in any form and will not be tolerated.

Making a mod post

So you downloaded a map and you've thought of some things you aren't happy with — now's the time to put your thoughts to words and help improve the map. But how can you get the mapper to see your point of view, test your suggestions and give you feedback? After all, no one likes feeling that their time has been wasted.

  • Before modding, ensure your intentions are good and you are focused on the task at hand. No one likes to receive a rude or lazy mod.
  • When making suggestions, try to differentiate between what is intersubjectively / objectively bad or wrong, and what you simply dislike on a personal level. All types of suggestion are fine as long as they are put forward accordingly.
    • Objective Issues - Prohibited by rulesets and must be fixed.
    • Intersubjective Issues - Not prohibited by rulesets, but are agreed upon as being "wrong" by a majority of people. Should be fixed in most cases unless there are opposing intersubjective arguments with equal size, or if the mapper can exhaustively explain why they feel it is acceptable.
    • Subjective Issues - Something that you believe or think on a personal level. Might become intersubjective if many people agree with it.
  • Unless the concept behind a beatmap is fundamentally flawed from the start, modding should aim to improve the map in its current design - not force your own style upon it. If you truly believe the map has too many significant issues to address individually, try to give a general statement of why this is the case and what direction you think the map should go in to get back on track.
  • When pointing out "issues", inspect each thoroughly and consider exactly what it is about the particular "thing" you dislike. Then, try to offer a potential solution or improvement and consider exactly how that suggestion will improve the map. If necessary, try multiple suggestions to see which work best — the more help you can offer the mapper, the better.

Suggestions themselves should ideally consist of four main parts, though based on the experience of the mapper and/or your personal relationship to them, you may want to be more lenient:

  1. A statement of the issue itself and where it can be found - including a timestamp is a huge help so that the mapper can find the part in question quickly.
  2. A brief explanation of why this causes a problem - this is essential in convincing a mapper to even consider your suggestion. Mappers are much more receptive to criticism and change when it's accompanied by clear, understandable and valid reasoning.
  3. One or more alternative suggestions, accompanied by explanations of how they address the problem(s) - much like the above, explanation is key here. Even if you can convince the mapper that their current work can be improved, what makes your suggestion better than theirs, or anyone else's?
  4. The wording (or even language) used should take the mapper into consideration. Are they a fluent English speaker? If not, stick to simple and easy-to-understand language. If you both speak the same language, by all means write in that language, but try to append an English summary of your mods and mod replies if possible, to ensure everyone stays on the same page. If necessary, support your suggestions with screenshots, illustrations, or even short video clips to help get your point across.

There are any number of ways to present your mod post, so feel free to experiment, but try to keep the visuals simple and formatted in a way that it is easy for the mapper and others to work with.

Responding to a mod

Someone just posted some suggestions on your map, great! However, it doesn't simply end there. For the record, it's necessary to give a proper response for two major reasons. Firstly, so that future mods can be tailored more specifically to your concept or style, resulting in fewer unhelpful suggestions. Secondly, just as a mod post helps you improve your mapping ability, providing a detailed mod response helps the modder improve their modding ability, meaning they gain experience and can provide more helpful and detailed mods in the future. You never know who you may need to ask for a mod next time around!

  • Treat all suggestions as valid and equally important until you have thoroughly inspected and tested them — even minor stylistic changes or alternative viewpoints can help improve the quality of a beatmap
  • As with making a mod post, be sure to explain yourself as much as possible. State what you changed, and if you didn't accept the suggestion for some reason, explain why and what you did instead.
  • When declining a suggestion, remain calm and professional, say what needs to be said in order to explain yourself and leave it at that. No matter how impolite, confusing or unhelpful the suggestion was, getting angry and responding with hostility, sarcasm, etc. will not help the situation.
  • Beatmap Nominators (BN) and Nomination Assessment Team (NAT) members will review previous mods before placing any icons and may want to initiate or revisit discussions during their checks. Any assistance you can provide as to why you did or didn't do something takes very little effort, and could be a huge help to all parties later on.

Further exchange and discussion

Sometimes, a single mod and response isn't enough to bring all parties to agreement, or fully resolve an issue. Perhaps the mapper doesn't agree with a suggestion, and the modder isn't satisfied with their response. Alternatively, both parties might agree that although one option is better, it isn't the best option and could still be improved further with additional input. Continued feedback is the best way to improve a beatmap, so get people involved and talking to get as many different ideas, or see things from as many points of view as necessary.

  • If you're unsure about something, ask the person in question to explain what they meant. They should be more than willing to explain things to you in more detail.
  • Still can't reach an agreement? Ask someone with more experience, such as a member of BN or NAT. Remember they are busy people, however! Should you realise there's a more suitable alternative to something you originally suggested, don't be afraid to put your pride aside - sometimes being wrong can be far more valuable than being right.
  • There is no such things as a "wrong" opinion — it's up to the mapper and modders to come to an agreement in a civil manner. Try to understand alternative points of view rather than attack them, as you never know when it might be useful in the future.
  • If you can't explain something through logic, you will not be able to explain it to them through violence either. Rather than continue a discussion that isn't progressing, walk away and try again with the next modder/mapper.
  • When things look to be getting out of hand, or if the discussion is struggling to stay on topic, call a moderator. Don't contribute to the problem by continuing to post.

Qualified beatmaps

The Qualified section allows beatmaps to receive any final suggestions for change or improvement before reaching ranked status. When modding a qualified map, everything you consider "not minor" should always be mentioned — minor issues are also worth mentioning however, especially if they affect gameplay. If a qualified beatmap accumulates a significant number of minor issues, or if there is one or more major/unrankable issues, the beatmap should be disqualified so that fixes and improvements can be made before attempting requalification.

If you're unsure on the nature of a potential problem, ask for other opinions or review previous mod posts to make sure the "issue" presented isn't something done intentionally by the mapper — if so, it will likely have been discussed already. If there has been no prior discussion, feel free to open one as if you were modding the map normally, and post a brief outline of your concerns.

Note that it is the community's responsibility alone to report issues with qualified beatmaps. It is not guaranteed that any BN or NAT member will actively check and disqualify beatmaps without being prompted to do so.