Need a Bulk Edit option about adventurelookup HOT 18 CLOSED

I think we can close this issue then. No bulk edit screen is necessary, given the new model. Agreed?

from adventurelookup.

Do you mean you'd like a default for each field so users only have to change things that differ from the defaults? For example, System could default to "5th Edition" - if your adventure is 5th Edition you don't have to touch that field.

from adventurelookup.

I'm addressing this tonight in the new UX (last screen set too do. woooooooo!).

Current plan is to have a "Select All" option, which is the default. Assumption would be the moderator will quickly scan the submission, and approve the changes all at once. Specific problematic data can be unselected.

Still not 100% sure how to handle multiple edits, where multiple conflicts exist, in a way that would be quick to sort through.

I can group them all on one screen, merge matched data, and highlight conflicts only, or force an administrator to approve each edit in successive passes, filtering out data between edits which match up.

If anyone has thoughts, that'd be super, super helpful.

from adventurelookup.

Alternate approach would be to actually maintain a history for fields, allowing contributors' changes to "go live" without approval. In this way you would be able to review the history of an adventure and/or remove a users' contributor status in cases where there were malicious changes.

from adventurelookup.

History should probably be maintained anyway, since a Curator could make a mistake.

If the community doesn't get a lot of people actively interested in acting as Editors, short-cutting the approval process might be the way to go.

from adventurelookup.

@MattColville I've added a take on a review and approval screen to #21.

A direct link is available here:
https://projects.invisionapp.com/share/D7CI37UFC#/screens/244186284

Would love to get your thoughts on it.

from adventurelookup.

History should probably be maintained anyway, since a Curator could make a mistake.

A history is already being maintained inside the ext_log_entries table.

from adventurelookup.

Ah, sorry @etchalon but I don't know what I'm looking at in the image you provided, I can't make sense of it.

Currently I see a page for each adventure with each field and its list of entities and I have to click each one individually and approve them. This is tedious and will mean much less work gets done.

I need each field on that page to have a checkbox, and another checkbox for "select all" and then the approve button approves everything checked.

This way I can approve the stuff I know is correct/legal, and leave the rest for future research.

from adventurelookup.

I just realized, it's not clear to me what the Approve functionality is for. I apologize for any denseness on my part.

I see a lot of adventures that need approval, but does that mean no one but the admins can see the adventure until it's approved?

That would surprise me, in which case does that mean everyone can see the unapproved adventure? In which case what does approval do?

I think, rather than needing to Approve submissions, we just let users Flag submissions as problematic.

Users could pick a reason for flagging like, Incorrect Data (please specify), Spam, Duplicate, Not Relevant to AL.Com.

Then the admins would get these reports and could sort them out.

from adventurelookup.

I just realized, it's not clear to me what the Approve functionality is for. I apologize for any denseness on my part.

I see a lot of adventures that need approval, but does that mean no one but the admins can see the adventure until it's approved?

That would surprise me, in which case does that mean everyone can see the unapproved adventure? In which case what does approval do?

I must admit the approved status is pretty confusing at the moment. Here's why: The approval state of adventures and fields can be set by anyone and is not used anywhere at the moment. "Approving" a field only sets its status to approved - that's it, just a visual change.

I think, rather than needing to Approve submissions, we just let users Flag submissions as problematic.

Users could pick a reason for flagging like, Incorrect Data (please specify), Spam, Duplicate, Not Relevant to AL.Com.

Then the admins would get these reports and could sort them out.

This is exactly the plan 👍 The approved fields go away and instead users flag problems admins and the person who entered the adventure can review.

-> Ignore the approved tags. They'll be gone within the next few days.

from adventurelookup.

This ticket is changing a lot of assumed functionality in a few words, so I think it makes sense to take a moment and confirm on what the flow for each step of the adventure submission should be.

Based on @MattColville's latest comment, it appears that:

1. Adventures may be submitted, and will immediately display on the web site, by any registered user.
2. Adventures, once submitted, may only be edited / added to by the original submitter, or a Curator/Admin.
3. Any other user may request an edit by "Flagging" the adventure as containing incorrect data.
4. A user will specify what data in a given adventure is incorrect and submit a report.
5. Reports will be reviewed by a curator / administrator and appropriate action taken including: a. editing of the adventure to correct incorrect data or b. deleting the adventure if it is deemed in-appropriate for the site.

Is all of the above how you want the site to function @MattColville ?

from adventurelookup.

Note the proposed permissions in #57 @etchalon, which @MattColville 👍ed as well. The only difference to your summary I can see is that the user who entered the adventure can also edit and delete the adventure he added to the site.

from adventurelookup.

I've updated my comment to reflect this.

I have a lot of concerns over original authors being the only ones who can edit / add to an adventure once submitted, beyond the curator, though I am unsure of how the usage of the site will evolve over time.

If adventures, once submitted, are relatively complete, then there's no issue. The need to edit / perfect an adventure will likely only be a problem immediately, or not at all.

If people start submitting garbage, we'll quickly approach a point where a curator / administrator has way too much work to do.

If the community standards evolve over time, we'll quickly approach a point where a curator / administrator has way too much work to do, due to "orphaned" adventures who's original creator is no longer actively engaging with the site.

The new model is a good deal simpler, and will lighten the work of the curator / administrator role initially, but I think it fails to solve the "community resource" problem well.

If we're going to trust people not to submit garbage, and to generally behave, I believe a "any registered user can edit" permission model (with a full history, for quick reversion) would be better. It seems like we have that history, through the recent features added in commits, so exposing it in the UX would make sense.

I don't see why we'd trust people to submit good records, but not to make good edits to other's work.

If we have the report functionality (already in my UX), I don't see why you couldn't use that same functionality to "report for revert", lessening the job of the curator / admin role, while solving the orphaned adventure issue.

But again, as in all things, I defer to @MattColville.

from adventurelookup.

We don't have that many users right now, compared to where we'll be once I make a video. And I already see some users I consider good submitters, and some I consider poor submitters.

I want to encourage the good submitters and empower them, and limit the damage the poor submitters can do.

Making them all equal is problematic because the poor submitters can undo the work of the good ones.

from adventurelookup.

Shouldn't we empower good submitters to easily fix the work of the bad ones then?

from adventurelookup.

Shouldn't we empower good submitters to easily fix the work of the bad ones then?

This is what we are doing, by marking the good submitters as curators which allows them to edit bad submissions.

from adventurelookup.

Correct. I'd rather spend my time making the submissions better than unfucking fueds between different submitters because we let everyone submit and edit everything.

from adventurelookup.

Ah. Got it.

from adventurelookup.