Group whole chapter with partial chapters.

[Quarnozian]

If you take a look at the chapter list for:
An Exiled Blacksmith Uses His Cheat Skills to Forge Legends

Spoiler: Chapter List

You'll notice that there's a Chapter 2, followed by Ch 2.1, Ch2.2, and Ch2.3... which means you get to read the entirety of chapter 2, then read the first third again with more credit pages. Then the second third, with more credit pages. And the last third, with more credit pages.

And this pattern repeats for chapters 3, 4, 5, 6, and 7.

---

Proposed Solution:

Group chapters by the number before the decimal place. When changing chapters, treat the whole # equally with the #.1 partial chapters, and have the reader try to advance to the upload by the same group. When ending partial chapters, continue as normal. When ending a whole # chapter, skip all remaining partial chapters.

However, we'll need a new checkbox to specify "This is a Bonus Chapter" so the whole chapters only skip the pieces of the main chapter, but don't skip the bonus chapters.

Unfortunately this change would skip all existing bonus chapters where the normal chapter doesn't have a decimal number attached to it.

 

[panzerkampfwagyu]

Maybe the initial application should have something like "Exclude if .5", as that is the common way to classify bonus chapters.

 

[OisE]

Or ban all the groups who split the chapters only to put their advertisment more often.

 

[SLeM9999]

Or ban all the groups who split the chapters only to put their advertisment more often.

How can you tell the difference between such groups, and groups that simply prefer
to chunk their translations into smaller groups? For example a longer chapter might
take a group an entire month to work on, so they might prefer a workflow that
releases part after 2 weeks and then weekly after that. Such workflows get
partial releases to the public faster, which sustains interest in the work, and
makes it more apparent that the group is actually active.

 

[SLeM9999]

I have been bit by this before, and it is definitely a nuisance. I second the call
for a way to group chapter chunks at a sub-level from chapters.

In one particular case, there were uploads of the entire chapter at once,
and there were uploads of pieces of the chapter, and there were also
uploads of pieces of the chapter broken at a different point than
the other pieces of the chapter. (For example imagine if the chapter was
6 pages, and someone uploaded all 6 pages, and someone else uploaded
in two 3-page chunks, and a third party uploaded in three 2-page chunks.)

 

[Bartolumiu]

If you take a look at the chapter list for:
An Exiled Blacksmith Uses His Cheat Skills to Forge Legends

Spoiler: Chapter List

You'll notice that there's a Chapter 2, followed by Ch 2.1, Ch2.2, and Ch2.3... which means you get to read the entirety of chapter 2, then read the first third again with more credit pages. Then the second third, with more credit pages. And the last third, with more credit pages.

And this pattern repeats for chapters 3, 4, 5, 6, and 7.

---

Proposed Solution:

Group chapters by the number before the decimal place. When changing chapters, treat the whole # equally with the #.1 partial chapters, and have the reader try to advance to the upload by the same group. When ending partial chapters, continue as normal. When ending a whole # chapter, skip all remaining partial chapters.

However, we'll need a new checkbox to specify "This is a Bonus Chapter" so the whole chapters only skip the pieces of the main chapter, but don't skip the bonus chapters.

Unfortunately this change would skip all existing bonus chapters where the normal chapter doesn't have a decimal number attached to it.

Although it's an interesting idea, it's impossible to make the reader reliably know if a chapter is an extra without any API changes, and even if we changed it, there'd be nothing stopping users from marking all their uploads as extra chapters only for them to be seen (yes, those kinds of users sadly exist).
Also, we'd need to apply this retroactively to all chapters on the website (over 1.9M according to the API, or over 2.6M if we include all unavailable chapters, making it a pretty unreasonable task for a 12 person team).

 

[Quarnozian]

Or ban all the groups who split the chapters only to put their advertisment more often.

That's already part of the community guidelines, so I don't see any reason why they couldn't do that already.

The problem with the example manga in the original post is that the publisher is the one splitting chapters into pieces. Per MD guidelines, if it's been published in pieces, then it can be uploaded in pieces. This allows TL teams to translate & upload the new release immediately.

If both teams released it split apart in the way the publisher has presented it, then there wouldn't be any problems with the user's reading experience. But since one team decided to combine the partial chapters into whole chapters, now the chapter releases don't mesh with the other group, so the reader makes you read the same chapters twice.

---

Although it's an interesting idea, it's impossible to make the reader reliably know if a chapter is an extra without any API changes, and even if we changed it, there'd be nothing stopping users from marking all their uploads as extra chapters only for them to be seen (yes, those kinds of users sadly exist).
Also, we'd need to apply this retroactively to all chapters on the website (over 1.9M according to the API, or over 2.6M if we include all unavailable chapters, making it a pretty unreasonable task for a 12 person team).

in my head, I was picturing just a checkbox similar to the "This is a Oneshot"... but labeled, "This is a Bonus/Omake" above the field for the chapter number.

I don't know how the site stores these data fields, so I was hoping it could simply be a new entry appended only to chapters when the checkbox is activated. That way all existing chapters wouldn't need any changes at all.

The concern about "those kinds of users" is also valid. unfortunately I think the only way to discourage them would be increasing penalties each time they're caught doing it... eventually up to:

• banning their account from uploading anything.
• removing every chapter the user has ever uploaded to the site.
• placing a 1mo block from uploads on the scanlation team they were doing the uploads for.

but unless you found a way to automate it, that would mean the MD 12 person team would have to manually police for users abusing this... which is unfeasible.

Guess we'll be living with this problem unless someone else can come up with a proper solution.

 

[Bartolumiu]

In my head, I was picturing just a checkbox similar to the "This is a Oneshot"... but labeled, "This is a Bonus/Omake" above the field for the chapter number.

I don't know how the site stores these data fields, so I was hoping it could simply be a new entry appended only to chapters when the checkbox is activated. That way all existing chapters wouldn't need any changes at all.

What that checkbox does is just that it sends null values for both the chapter and volume numbers, since oneshots are stored like that on the backend (everything is handled on the client side, so we don't need to change the API causing third party apps to break).

The concern about "those kinds of users" is also valid. unfortunately I think the only way to discourage them would be increasing penalties each time they're caught doing it... eventually up to:

• banning their account from uploading anything.
• removing every chapter the user has ever uploaded to the site.
• placing a 1mo block from uploads on the scanlation team they were doing the uploads for.

but unless you found a way to automate it, that would mean the MD 12 person team would have to manually police for users abusing this... which is unfeasible.

We currently ban around 5-10 users daily for fake uploads, so I don't want to imagine what the amount would be if we did that...

Guess we'll be living with this problem unless someone else can come up with a proper solution.

Sadly that'll be the case...
If only we already had the contributor queue I requested almost a year ago to offload stuff to contributors, we wouldn't have over 2k open reports rn

 

[Quarnozian]

If only we already had the contributor queue I requested almost a year ago to offload stuff to contributors, we wouldn't have over 2k open reports rn

You mean the Chapter & Title reports? ... Like this? ->

I thought those were mostly sent to only the contributor that uploaded the chapter/added the title. (except maybe certain reasons in the drop down menu, like "troll entry") I didn't know the MD staff was dealing with ALL of those. Holy cow.

If it were up to me, I would:

• Only send reports to the contributor & group (if a group was selected), unless the report reason was something that specifically needs MD Team attention.
• If a contributor with 5+ unresolved reports tries to upload a chapter, they are redirected to their Open Reports page.
• If a group with 20+ unresolved reports is selected, they are redirected to the Group's Open Reports page.
• If a contributor has any unresolved reports that are over 2 months old, redirect the entire site to their Open Reports page.
  
  
• Make unresolved contributor reports available to MD staff in a separate queue from the staff-specific reports.
  Reduces stress, because you have a list of "my problems" (staff list), and a list of "someone else's problem" that can basically be ignored unless you have so much time on your hands you just need SOMETHING to do.

 

[Bartolumiu]

You mean the Chapter & Title reports? ... Like this? ->

Yep, exactly those~♪

I thought those were mostly sent to only the contributor that uploaded the chapter/added the title. (except maybe certain reasons in the drop down menu, like "troll entry") I didn't know the MD staff was dealing with ALL of those. Holy cow.

Now you can probably guess why we always say there's a kinda big backlog.
As a little extra, the oldest open report currently in the queue is from 2022 (until a couple of hours ago, it was the second oldest, but I spent ~4h merging chapters just to finally nuke the previous oldest).
On the other hand, on a normal day we can probably get around 100-150 reports (of which ~15-20 are just users complaining about dumb stuff we can't control or just saying they didn't like something they read, among other things), 5-10 title draft submissions (of which usually ~20% of them are missing important data such as native/romaji titles and/or official/tracker/retail links, and sometimes spam bots trying to advertise weird drugs) and 20-30 chapter approval submissions (of which some are TikTok screenshots, official rips or completelyautomatedtranslationsfrom Google Lens).

If it were up to me, I would:

• Only send reports to the contributor & group (if a group was selected), unless the report reason was something that specifically needs MD Team attention.
• If a contributor with 5+ unresolved reports tries to upload a chapter, they are redirected to their Open Reports page.
• If a group with 20+ unresolved reports is selected, they are redirected to the Group's Open Reports page.
• If a contributor has any unresolved reports that are over 2 months old, redirect the entire site to their Open Reports page.
  
  
• Make unresolved contributor reports available to MD staff in a separate queue from the staff-specific reports.
  Reduces stress, because you have a list of "my problems" (staff list), and a list of "someone else's problem" that can basically be ignored unless you have so much time on your hands you just need SOMETHING to do.

There's a pending mass internal restructuring for all user roles on the website, one of them being the removal of title editing privileges from Group Leaders and Power Uploaders, given their usual tendency for participating in title edit wars instead of reporting the entries so they get locked, and the ability for contributors to edit chapter metadata directly to help with volume renumbering and split chapter merging. On the other hand, there'd be a queue accessible to any user with contributor role so we can offload metadata related reports to them (there are about 4-5 times more active contributors than site moderators, and ~10x if we also count inactive contributors which will get their contributor role removed in the future, since we plan to add stricter requirements for the role). And finally, users would be able to submit change suggestions directly on the title edit page instead of it being through a report, making approvals be just clicking the accept or reject button instead of trying to decypher poorly written ESLese.

 

[Manko-sensei]

There's a pending mass internal restructuring for all user roles on the website, one of them being the removal of title editing privileges from Group Leaders and Power Uploaders, given their usual tendency for participating in title edit wars instead of reporting the entries so they get locked, and the ability for contributors to edit chapter metadata directly to help with volume renumbering and split chapter merging. On the other hand, there'd be a queue accessible to any user with contributor role so we can offload metadata related reports to them (there are about 4-5 times more active contributors than site moderators, and ~10x if we also count inactive contributors which will get their contributor role removed in the future, since we plan to add stricter requirements for the role). And finally, users would be able to submit change suggestions directly on the title edit page instead of it being through a report, making approvals be just clicking the accept or reject button instead of trying to decypher poorly written ESLese.

If it becomes more structurated and serious I may help out actively again, in any case you're going to coordinate that on Discord, the forum or elsewhere? If it's the former, the feature to link your Discord account (so you don't need to report your profile and wait for a mod to give you privileges) is still pending.

 

[OisE]

inactive contributors which will get their contributor role removed in the future, since we plan to add stricter requirements for the role

Oh no, not me me, I swear I will become a good kid again, just now I don't have much of free time, I beg you.

Joke aside, I consider myself a contributor and it helps me a lot in adding titles of historical importance without delay so I can edit the freshly newly added title like 4 times in 3 minutes because I am never happy at what I've done. But, is my frequency of contribution high enough to keep my role or not?

Also, I don't use discord at all for mangadex, and don't want to link it with MD...

 

[Bartolumiu]

If it becomes more structurated and serious I may help out actively again, in any case you're going to coordinate that on Discord, the forum or elsewhere? If it's the former, the feature to link your Discord account (so you don't need to report your profile and wait for a mod to give you privileges) is still pending.

tbh, that'd be really helpful, since we plan to offload part of the report queue for contributors to handle (mainly to get rid of those reports from 2022-2023 once and for all). As for the coordination part, there's still no details, since there are still some tasks we need to finish on both the management and development sides, but yes, the MD to Discord link will eventually come (not sure what's blocking the development of that, or if it's just that they're handling other stuff instead).

Oh no, not me me, I swear I will become a good kid again, just now I don't have much of free time, I beg you.

Joke aside, I consider myself a contributor and it helps me a lot in adding titles of historical importance without delay so I can edit the freshly newly added title like 4 times in 3 minutes because I am never happy at what I've done. But, is my frequency of contribution high enough to keep my role or not?

Yeah, I'd say it is (I recall seeing your username quite frequently on the report queue).
P.S. I'll try to check the 7 reports you still have pending tomorrow

 

[OisE]

I don't know how it works for the reports, but it would be nice to have a notification or an entry showing there are reports pending when you are on a title page, so you can quickly check them.
At the same time it would help to go through a batch of reports because you are already checking the title.

 

[ediefalcopuppyalt]

Good idea but it is pretty annoying scrolling through a long list, especially on lower end devices so maybe group the lists into a folder like menu in the list?