Interesting to read, how Az proves MA to show wrong data fields, because he´s absolutely right. I was too late.
Interesting to learn, half a day too late might probably be considered as "tremendous difference".
Well, if so the creation year 2016 (mine) vs. 2021 (accepted entry) speaks for its own.
However, I´m happy
Fearance finally made it to the Archives. Matter settled for me.
I´m not here to waste my time reading I´m a disgruntled user (which meanwhile is certainly true).
I´m here to contribute. Not only information in form of entering data, but contribute by showing a possible solution to fix many of the beforehead mentioned problems.
If this is the wrong place to post - feel free to move it to another thread or topic.
---------------------------------------------------------------------------------------------------------------------------------
► Description of problemsPaganiusI wrote:
There simply are too many bands being submitted to double-check everything with the appeals forum, sadly. [...]
I'll ask HB about a coded solution for this. Maybe an orange warning box mods see in the queue that tells us a band was appealed recently.
Pag´s idea is definitely good, but when I see this through the eyes of a database engineer, it´s not practicable.
I´m sure MA (the Encyclopedia) and the Forum are two standalone database systems, hardly connected to each other. (Likely for user names, probably not even band entries.)
So Pag´s suggestion to cross-checks submission names with Appeals thread titles is a too big effort to implement. Matching unstructured data (thread titles) with structured data fields is a tricky task.
Likely the reason for it´s not implemented yet.
However, I´d like to draw your attention to another, a
more serious issue, namely
DATA LOSS - the fright of all database developers.
Cause that is what we get everytime when a certain user doing a
successful band appeal is
not the initial submitter.
Keep in mind: Any band someone´s doing a band appeal for is a band that was rejected in the past. (or "disabled", which I will come back to lateron)
That likely means someone else already submitted good (structured) data for this band (like location, genre, discography, members and all those) at some point.
As for rejection this means the entry is jailed into the original submitter´s drafts.
So if another user comes up with a
successful band appeal, he will enter the band anew and all previous data is buried (i.e. lost for MA) and has to be re-collected (if even possible) and re-entered again.
For me this is the worst case scenario: DATA LOSS plus blurred historical data re-collection plus potentially buggy re-entering plus a disgruntled initial submittor.
Not to forget the annoying issue of 'Users snipe bands from the appeals forum' as TheGrimWombat described.
► A possible SOLUTION - the RE-USE of DATA.What if I point out a solution to solve all these problems (and many more you don´t even think of yet) in one single strike.
My idea is not only easy to understand but also comparatively easy to implement (from the point of a database developer) - just follow my thoughts:
•
Adding a new band - the duplicate checkWhenever a new band is added, the system checks for duplicate by the data couple of <Band name, Country> and eventually returns a warning like that:
Very cool background check - just too restrictive in my thinking. This is where my solution approach steps in.
1. Just expand the search to ALL ever REJECTED bands, sleeping in some user´s draft bands.If found, the system could tell
MA wrote:
This band {description} was rejected on Sep 21, 2018 for the following reason: {reason for rejection}
If you are sure to provide new data (like a new album that is Metal) then press 'transfer' to inherit the initial submission of user X.
After this you´ll find this band as a draft in your band submissions
2. Expand the search to ALL DISABLED bands sleeping in the database.What is
disabled? - Database engineers tend to never ever really
delete laborious collected data unless it´s completely trash.
Valuable data (e.g. band plus huge discography) of a once approved band that was just victim of a "cleansing the archives" task is a perfect example for a disabled band.
Once valid, maybe hard collected data, just not fitting for M-A - however too good to throw it away. So what we do in such cases is to flag it "invisible" (or call it "deleted"), e.g. to disable the band´s recordset. - This means it´s not visible or accessable to anyone but the db admin and it appears to be deleted to everyone but actually isn´t.
Those bands should also be considered by system´s background search. So if any new decision basis shows up on a disabled band, their whole data can be restored into the user´s draft.
By changing just one marker. A simple sql-statement will do the trick.
3. Also search in recent submissions and prevent duplicates from the outset.That´s pretty much it. A simple concept, easy implementation - and even better:
No exception handling. Everything goes the proper way, following the same rules and policies as always.
When it´s not allowed to resubmit a band without revising the submission for the initial submitter, it´s still not allowed for someone who inherits the band entry.
Furthermore this would guarantee
maximum transparency to anyone concerned why and when a band was rejected. Take over the recordset plus responsibilty and see yourself.
Without any person doing anything manually - just an automated system task. Imagine the huge impact to the Band Appeals forum - it would (almost) become obsolete!
No Moderator activity necessary to look up why a band was rejected, no waste of time to hear a band´s new album to judge whitelisted (or not) including the need to re-hear it again whenever the band is finally resubmitted again.
Everything just goes the regular way: A band´s new album is out (assume: Metal this time), so any user can request and take over the band´s dataset, seeing every bit of data ever entered.
A solid decision basis, not only for the user to decide wheter to resubmit the band for the new album, but even more for the moderators who only have to re-judge the band based on the
new album cause they´ll see any decision and internal notes made earlier. - This kind of
Incremental valuation could save a lot of time for moderators.
Remember: Data that once was lost (or hardly accessable) by concept.
► EffectsSo let´s analyze the effects, run through some scenarios (normal and exceptional ones) and evaluate the pros and cons.
- No changes when a new band is submitted. Business as usual.
- The system catches a submission of a once rejected OR disabled band:
The submitter is being made aware of this and takes over all band data.
+ Full transparency as one can see immediately(!) why and when the band was rejected so far.
+ All data fields, the whole discography entered so far, members, links - just everything ever entered shows up.
+ No waste of users´ time to create a Bands Appeal post, giving reasons for this and that.
+ No bothering of Moderators to look up the reason for rejection.
+ No waste of Moderators´ time to judge if the band could be whitelisted.
+ No waiting for possible whitelisting.
+ Instant availability of band data avoids "stealing" of (meanwhile) whitelisted bands by other users.
+ This would solve both Dembo´s and TheGrimWombat´s claimed issues on that matter.
+ Perfect immediate decision making for the user wheter the intended album/ep addition was already judged or not and wether the revision is worth a re-submit or not.
+ This would´ve solved my own issue (mentioned above), since Fearancy is sleeping in my drafts since rejection in 2016. The other (faster) user would take over my draft, add the new album and submit it. - Perfect collaboration, both happy.
- Let´s assume the user decides to re-submit the band with the addition of the new album thinking it´s worth a re-judgment.
+ A one-time revaluation of the last added album to be made by moderators. A time-consuming task that previously the mere whitelisting would have required.
+ No cross-check with band appeals necessary.
+ Just one single judgment and in case the band is rejected again the band data will 'sleep' until another user maybe decides to resubmit for the next album.
+ However, this type of incremental valuation reduces the overhead for moderators to a minimum. Old, restored rejection notes plus hearing one new album is a solid basis and little effort to decide, compared to what it is now.
+ Perfect division of working points in case the band is accepted as of now. Every single contributor will get the points he deserves as the system now knows about anyone´s modification.
+ No exception handling: Counting modification lines for summing up user points will work as on any other submission.
+ The withholding of old releases (whether knowingly or unknowingly) would not be possible. - Imagine: A band was rejected for its 20 albums, genre Ambient, not acceptable.
The user only knows the band by album #21 being clearly Black Metal, which makes them whitelisted. Will he add those 20 albums before? Guess not. Not a serious example, but just imagine Uruk-Hai (Aut).
- Assume the user decides upon the transferred data not to re-submit the band.
± Nothing bad with it. The only unpleasant thing happened is the transfer from one to another user´s draft.
- Ok, the initial user might wonder where his draft is gone. A notification message could inform about this.
- Assume the user decides upon the transferred data not to re-submit the band AND deletes the draft.
+ Not bad either. The system marks it as "deleted" and the data will remain unassigned (or assigned to a special dummy user) until the next one claims it.
- Assume someone is adding a completely new band for let´s say a digital single (or two). - Not enough to submit it right now, but they already announced a full-length.
++ This is where the reuse of data unfolds its full power. The first user to add the new full-length will take over all band data, inherit the digital single(s) and do the final submission.
+ Still a win/win situation for both contributors. Both will get their points, the later one wins the sub. No cause for anyone to complain.
+ No matter whatever reason prevented the first user from submission, his data will be considered as the second one cannot add a band that´s already added to the database, no matter where it sleeps or hides.
+ Isn´t that a nice imagination? The system collects data from maybe various users (let´s assume 2 digital singles) and automatically adds it to the recent full-length.
Almost magically, without any manual interevention. That´s data reuse at its best.
To sum it up in one sentence:If MA could avoid band duplicates not only for approved but for all ever entered bands, this could solve many problems and make the band appeals (almost) obsolete.
Or in other words: Let´s not only share/work together at approved bands but also for bands drafts.
I´d like to hear your own (or HB´s) assessment to this. Any wrong assumptions in my treatise?