forum

Code of Conduct: Modding and Mapping

posted
Total Posts
50
show more
Ardiemerde
Would love to translate this to Indonesian so that it could be localized.

Well, when it's amended though.
Lily Bread
a good post.
JBHyperion
Thanks for all the feedback so far guys! I'll do my best to go over it in the coming days, so stay tuned for an update in the near future!
Topic Starter
Loctav
As he said, we will review your input and make adjustments, before we reopen this discussion again. Thanks everybody for contributing!
Topic Starter
Loctav
We are unlocking this thread to reopen the discussion about our adjusted Code of Conduct. Based on your suggestion, we have made various changes to the set of behavior rules and we wish everyone to participate once again!

When the deadline expires, we will lock this thread again and make final adjustments to the code of conduct before making it official part of the Ranking Criteria, so leave your feedback while there is still a chance!

Read the first post of the thread for all information!
Endaris
Looks pretty good on first read now.
Mismagius
Hi, I'll probably edit this with more info later but

Loctav wrote:

  1. Unless the concept behind a beatmap is fundamentally flawed from the start, modding should aim to improve the map in it’s current design - not force your own style upon it.
People are currently using this as an excuse to stop technical maps (such as HW's) from getting qualified, and I feel like the wording on this doesn't really specify that it's pointed at mapsets from new mappers and mappers that don't really know what they are doing. I think that the first part of the sentence could make it clearer about what kinds of map we're directing this to
Endaris
Tbh, I don't feel like HW ever had problems ranking her maps that feel more gimmicky. When even a map with SV6.2 overlapping fullscreensliders that won't get followed by the player ever (he will aim for each individual slidertick instead) gets serious modding I don't think there's any reason to worry. I don't mean to discuss about specific maps here (just an example how tolerant the community is towards experimental mappers) but when they're experimenting even experienced mappers who usually know what they're doing can create a design that is flawed or at least needs major adjustments. Simply because they're doing something new and their experience isn't worth as much in such cases.
Mismagius
but the point of that section is to point out objective issues, while these 'experiments' are often subjectively good/bad
Endaris
I still don't think it needs a separate note. A separate note would easily boil down to something like
"If you don't understand the map cause the mapper is too pro, come back when you got good so you may see what's going on."
Which can easily be interpreted in the way that the modders are just too dumb to see the true genius of a map.

In terms of feedback it's not much different from letting two players play a map that is mapped on Insane-level but has Metadata as if one applied EZ-mod. One is a regular EZ-player and the other isn't. The former can play it and will actually be capable to say something about the map's quality. The latter can't play it nor say something about the quality but the feedback he he will give regarding the map's readibility with EZ is still not worthless.
The example is obviously a bit extreme because even the EZ-player can tell the mapper that the map is hard to read but on more nuanced levels such issues might not be as obvious to the experienced player.
The mapper is free to disagree with the proposal of remapping and can work together with the person who doesn't understand a thing to make the map more accessible while keeping the desired theme. After all the modder hopefully gives reasons why he thinks it should get remapped. From there everything can only get better.
xxdeathx

Loctav wrote:

  1. Unless the concept behind a beatmap is fundamentally flawed from the start, modding should aim to improve the map in it’s its current design - not force your own style upon it.
Topic Starter
Loctav
Well, doesn't seem like we gathered much this time. Thanks everybody anyways! We are locking this for now while we review and try to address the last issue people mentioned in this set of rules before moving onwards to amending this CoC to the Ranking Criteria.
JBHyperion
Fixed the typo pointed out!

After discussing the remaining concerns, we decided that the current wording is sufficient. Expanding on it further would open loopholes by attempting to cover a plethora of edge cases which would defeat the purpose of a clear and concise guide. I'm confident we can push this forward in its current state, so we'll give this a final two weeks to see if anything else comes up.

New Deadline: Thursday 11th August 2016

Thanks for your help and suggestions everyone!
Battle
"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."

Shouldn't including a timestamp be something that's necessary rather than a huge help? Even if the problem is re-occurring typically adding one example of the pattern/rhythm/whatever in question helps a lot more than "the pattern with the triangle plays bad, fix it for all those patterns".
those
Except it's not always necessary, since oftentimes it is more useful in the long run to make more general statements than it is to point out individual mistakes or inaccuracies. Sometimes a map might not even be at such a level where pointing out individual things would actually be a good change (for example, if the majority of the map should be remapped, etc.). On top of that, if someone is able to point out and fix their own mistakes, they're less prone to make those mistakes in future maps.
Battle
Fair enough, but I'm kinda saying that there should at least be one example given in that case. I am well aware that when modding a newer mapper's map, it's a lot easier to point out things such as sliders with ends on downbeats (something which is absolutely okay to give without a timestamp). However I do feel like timestamps are necessary so at least the beginner knows what exactly to look out for, beginner's may not know what exactly about what you point out is wrong for a certain pattern or rhythm, so giving one timestamp at the very least for a point can be tremendously helpful as they have a clear example of where it happens so they can try to understand why it is wrong.
Wafu
I still think the same about the language, but nobody discussed that at all, so I don't see why it is the same.

ALL BNs speak English and are obligate to check if any mods aren't missing a kudosu. It's good if you use a language that makes more sense to the mapper, but one of them should make a conclusion about what was changed and what wasn't changed in English - maybe something important was ignored and maybe we aren't even aware if that mod warrants a kudosu. I think it's quite quality-killer if you want to qualify/bubble a map that has all mods of a language you don't understand. Sometimes I'm surprised what mapper ignored and could improve the map a lot, but nobody will point it out in this case.

@Battle For beginners, I think they need only one timestamp to fix everything of that issue if it's 100% obvious what the issue is. In other case when they might not be really sure when it's an issue and when it isn't, all timestamps wouldn't hurt.
J1NX1337
Great summary of things to take into account!
Should help a lot of people in their approach to modding and/or applying mods.

I think one thing that helps with the modder's approach when writing mods is to properly organize the mod structure, with for example lists and perhaps some square brackets for headers or bold/colored text for highlighting. It helps make the mods more comprehensible and more enjoyable to read for the mapper and everyone involved. It's not exactly essential of course but to my experience, it does convey a better feeling of the mod in general. It seems more proper, nice and less lazy because of the extra bit of effort put into it, I suppose. It doesn't of course mean that everyone who doesn't bother with aforementioned things or cleanliness made a bad mod though, definitely up to the modder. :P

Wafu wrote:

I still think the same about the language, but nobody discussed that at all, so I don't see why it is the same.

ALL BNs speak English and are obligate to check if any mods aren't missing a kudosu. It's good if you use a language that makes more sense to the mapper, but one of them should make a conclusion about what was changed and what wasn't changed in English - maybe something important was ignored and maybe we aren't even aware if that mod warrants a kudosu. I think it's quite quality-killer if you want to qualify/bubble a map that has all mods of a language you don't understand. Sometimes I'm surprised what mapper ignored and could improve the map a lot, but nobody will point it out in this case.
Agreed. I think, if the modder is capable of writing English, but for example chooses to mod in their foreign native language instead, they should write a short summary of core parts of the mod, and the mapper should do it as well when replying to the mod in that same native language to give a short summary on what was changed. This is especially important on the modder's part when an IRC mod is in question, since it's really hard to tell what is conveyed in those messages if they're of foreign language, and sometimes it can be quite important information to see what was already discussed and what the mapper's opinion on that is.
AzureDoctor
I'm not too good with words, so please bear with me here.

When I was looking through the mod queues, I noticed quite a few modding queues saying that they will only mod certain genres and/or songs that they like. I got rejected many times trying to get mods for my first map becuse the modders "didn't like my song".

While I understand that every person has their own preferences, I feel that modders should be able to step out of their comfort zone and be open to all genres of music presented to them by the mappers.

If the modder doesn't know how to mod a certain genre, that's okay. But rejecting a map just because they don't like the song is not something I think is acceptable, especially if the modder doesn't take into account the quality of the map presented to them.

Though I'm still new to mapping and modding, I feel that having modders be open to all genres of music would help mappers get more mods, and the modders would gain even more valuable knowledge on modding.

What do you guys think?
JBHyperion

Wafu wrote:

I still think the same about the language, but nobody discussed that at all, so I don't see why it is the same.

ALL BNs speak English and are obligate to check if any mods aren't missing a kudosu. It's good if you use a language that makes more sense to the mapper, but one of them should make a conclusion about what was changed and what wasn't changed in English - maybe something important was ignored and maybe we aren't even aware if that mod warrants a kudosu. I think it's quite quality-killer if you want to qualify/bubble a map that has all mods of a language you don't understand. Sometimes I'm surprised what mapper ignored and could improve the map a lot, but nobody will point it out in this case.
All BNs are competent in English, but you can't reasonably expect every mapper/modder in the entire community to be so. I could include an additional request to "provide a summary of main points upon request", but I feel the onus is as much on the BN to seek out that information if they desire it, as well as the mapper/modder. As with any aspect of mapping, you are encouraged to seek help from someone with experience if there are parts of the beatmap thread you don't understand or want more information on - either from the mapper/modder or another team member who is competent.

Added a sentence to the language-specific point encouraging mappers/modders to provide an English summary if at all possible to ease understanding.

J1NX1337 wrote:

I think one thing that helps with the modder's approach when writing mods is to properly organize the mod structure, with for example lists and perhaps some square brackets for headers or bold/colored text for highlighting. It helps make the mods more comprehensible and more enjoyable to read for the mapper and everyone involved. It's not exactly essential of course but to my experience, it does convey a better feeling of the mod in general. It seems more proper, nice and less lazy because of the extra bit of effort put into it, I suppose. It doesn't of course mean that everyone who doesn't bother with aforementioned things or cleanliness made a bad mod though, definitely up to the modder. :P
I did consider adding this, but felt it would be too difficult to work in in a simple way (i.e. without covering several hundred possibilities) that fit the idea of this guide. Once the foundation of [Problem > Explanation > Suggestion] is understood, clarity via formatting will develop over time. The theme of "give to others what you would like to receive" should encourage people to put effort into making their mod posts understandable and accessible.

Discussed this with Loctav, we decided to provide a bit more representation after the "4-stages to a mod post" sub-section encouraging a lean towards simplicity for the sake of easier understanding.

Annika Flina wrote:

I'm not too good with words, so please bear with me here.

When I was looking through the mod queues, I noticed quite a few modding queues saying that they will only mod certain genres and/or songs that they like. I got rejected many times trying to get mods for my first map becuse the modders "didn't like my song".

While I understand that every person has their own preferences, I feel that modders should be able to step out of their comfort zone and be open to all genres of music presented to them by the mappers.

If the modder doesn't know how to mod a certain genre, that's okay. But rejecting a map just because they don't like the song is not something I think is acceptable, especially if the modder doesn't take into account the quality of the map presented to them.

Though I'm still new to mapping and modding, I feel that having modders be open to all genres of music would help mappers get more mods, and the modders would gain even more valuable knowledge on modding.

What do you guys think?
Everyone feels this way at times, but you have to remember that modding is a voluntary activity, often with little "reward". People are far more likely to mod what they like, for whom they like, when they like; either because they find it more enjoyable, or they can be more sure of what to expect and hence, what to look for, making the process easier. Some people don't like to leave their comfort zone, and that's fine - they can still make a positive contribution from there, and may yet open up in time. osu! is a diverse community, so the chances of you not being able to find anyone who shares the same preferences as you are slim. Keep mapping/modding/discussing/etc. and you'll meet new people, make friends and be able to gain experience and improve together!

The above still stands as it's all down to personal preference in the end, I'm just commenting here for the sake of completeness

Thanks everyone for your suggestions, these should be the final amendments so expect to see this incorporated into the Ranking Criteria very soon - stay tuned!
Topic Starter
Loctav
Amending finally.

This Code of Conduct is in effect immediately. It is now a sub-section of the official Ranking Criteria (see https://osu.ppy.sh/wiki/Ranking_Criteria at the header) and can be found at https://osu.ppy.sh/wiki/Code_of_Conduct ... nd_Mapping.

Any future amendments and changes regarding this Code of Conduct will be handled just like any other Ranking Criteria changes. The CoC will remain an extension of the osu! community rules and therefore be a warrant of issuing penalties for severe infringements of such.

Most of the rules should be common sense already anyways and just explicitely apply the community rules to the modding and mapping environment.
Please sign in to reply.

New reply