While they probably should still do so for *very* minor issues, it's not the moderator's job to fix the issues that are cause for rejection.
Also telling the submitter what to fix and having them fix it themselves helps them improve (assuming any issues were done on accident, especially concerning optimization) and is overall better for the section.
It does speak to a larger issue, and it's something anonimzwx has already made a thread about.
I think there's a case for fixing minor issues when resources have been sitting in the section for a very long time and the creator may no longer be interested in going back and fixing it. But normally, no they shouldn't. This is not an issue when resources are being moderated promptly.
But I imagine asm moderation takes some time, and not all of the mods can always set aside that time to immediately moderate a resubmitted file.
Which is why he said it wouldn't hurt to pm or dm the user. When I moderate music, if there's minor things, I fix them and leave it in the feedback such as people forgetting #default or #optimization, forgetting $f4 $02 toggles if the song has no intro, etc. But if it's few small things, I'd rather DM or PM the person and have them do a quick update/resubmit while I still have the song claimed rather than rejecting it and having to come up and write a log, make a back up of the spc, archive it, ftp it, and link it. That's strenuous and more time consuming bc of the the steps needed. Especially if it's constantly.
I had read some asm resources removed for only little code optimization problems, why asm mods donít fix that optimization problems that they found d and resubmit the file, instead to reject it?
I think it depends heavily on the mod, but if it's not a heavy issue normally the moderators accept it and then comment in the submission that the code could be optimized. Other mods would correct those little errors, but I don't think they shold be entitled to, specially if it implies a major rewrite . I didn't found any rejection only based on code optimization unless it's pretty big (LDA #$00 STA instead of STZ, unnecessary branching and copy-pasted redundant code all mixed together, for example...), so I think you can rest assured that minor optimization problems will not lead to rejection anonimzwx
Well, I'll talk by my perspective of being a new ASM Moderator.
My basic rule of thumb is: whenever a bug appears, the first thing I do is determine if its minor enough to warrant a simple fix, then approve the whole thing after; of course, anything worse than that I always consider to remove.
Second: I do prefer to moderate things I've already moderated (mainly removed), as the user was acquainted with my analysis before. There's instances of me rejecting the same thing 2, 3 times in a row, all because I already had the experience moderating them once, thus knowing exactly what to test after. This could be a good thing for all the ASM Mods imo.
About the time which we moderate stuff: it varies, really. In my case, due to me having a busy life, my moderations have the possibility to be set aside for days. Of course, with simpler resources and my test suite, I can determine, sometimes, if a resource is compatible or not in a matter of minutes. So, it's pretty relative actually.
About code optimizations: If there's one or two issues, just correct them and go ahead. I don't even try to change LDA #$00 STA !RAM because of one thing: you can define !RAM as a long address, thus making your code totally not work due to assembly errors. The same thing with INC !RAM and LDA !RAM : CLC : ADC #$01 : STA !RAM or similar; these cases, in my opinion, can be overlooked.
LadiesMan is a ladies' man,
Eevee is cute;
Noivern can shatter eardrums,
and beware, Major Flare blinds you.