Making WordPress.org

Opened 7 years ago

Closed 6 years ago

Last modified 4 years ago

#2598 closed enhancement (wontfix)

Extend Close and Archive to Plugin and Theme Authors and Contributors

Reported by: macmanx's profile macmanx Owned by:
Milestone: Priority: normal
Component: Support Forums Keywords:
Cc:

Description

Plugin and Theme authors currently have the power to mark threads as resolved and pin sticky topics within their own support forum, which is great.

We have also been receiving requests to allow them to Archive topics (for duplicates, mostly) and Close topics (for when things get out of hand), and the Support Team feels that these sound like fair requests.

Overall, this will give Plugin and Theme authors more control over their own support forum, should contribute to user happiness by way of a less "messy" support experience, and lower the modlook load for the Support Team.

Change History (27)

This ticket was mentioned in Slack in #forums by macmanx. View the logs.


7 years ago

#2 @SergeyBiryukov
7 years ago

#2520 was marked as a duplicate.

#3 @SergeyBiryukov
7 years ago

Just to clarify, I guess this should apply to plugin and theme contributors too (not just authors), as the people doing support are not necessarily the same people that have commit access.

#4 @macmanx
7 years ago

Yes, contributors too, please. :)

#5 @macmanx
7 years ago

  • Summary changed from Extend Close and Archive to Plugin and Theme Authors to Extend Close and Archive to Plugin and Theme Authors and Contributors

#6 @Otto42
7 years ago

I'm generally against this idea, as I feel it would lead to abuse.

However, as long as there is a way for special knowledge being passed along to said authors that *any* instance of abuse of these powers, in any way, would lead to their permanent removal from WordPress.org, up to and including removing their themes/plugins from the directories, permanently, then I'd be okay with it.

Basically, if they abuse it, they're out. Just so that is clearly communicated to them, somehow.

#7 follow-ups: @macmanx
7 years ago

I'm fine with that.

Maybe as an announcement on Make/Plugins and Make/Themes that covers all the special capabilities they have in their own forums, along with a warning against abusing that power?

The nice thing about the new Archive system is we can always see what they delete, and restore it if necessary.

#8 in reply to: ↑ 7 ; follow-up: @netweb
7 years ago

Replying to macmanx:

The nice thing about the new Archive system is we can always see what they delete, and restore it if necessary.

I'm thinking we should record the timestamp for closed and archive (if not all) notices

This way a _timeline_ of events and by whom can be reconstructed if necessary

This post has been closed/archived by macmanx dd/mm/yyyy

#9 in reply to: ↑ 8 @SergeyBiryukov
7 years ago

Replying to netweb:

I'm thinking we should record the timestamp for closed and archive (if not all) notices

Yep, see #2537.

#10 in reply to: ↑ 7 ; follow-ups: @Otto42
7 years ago

Replying to macmanx:

Maybe as an announcement on ...

No. Not enough. This needs to be much more of an in your face thing. You're proposing giving archive/close (and, by extension, the ability to see archives and unarchive/unclose threads) to tens of thousands of people. Multiple tens of thousands.

So, yeah, tracking actions: great idea. But sticking a "hey, consequences exist" in your face needs to be much stronger than a post on a site that most of them don't see. Just saying.

#11 in reply to: ↑ 10 @macmanx
7 years ago

Replying to Otto42:

sticking a "hey, consequences exist" in your face needs to be much stronger than a post on a site that most of them don't see.

Sure, what did you have in mind?

#12 in reply to: ↑ 10 ; follow-up: @SergeyBiryukov
7 years ago

Replying to Otto42:

You're proposing giving archive/close (and, by extension, the ability to see archives and unarchive/unclose threads) to tens of thousands of people.

Note: The latter part (the ability to see archives and unarchive) is out of scope for this ticket, as per-forum or per-project moderators wouldn't have access to any archived messages (for now, at least). Quoting my comment from #2590:

The latter two points seem worth fixing at some point, but the first one should remain as it is, unless those views can be filtered to only include posts from the forums the user can moderate.

To summarize: In this ticket plugin and theme authors won't get access to any posts they don't normally have access to. They would only be able to Archive, Close, and Reopen topics in their own forums.

#13 in reply to: ↑ 12 @macmanx
7 years ago

Replying to SergeyBiryukov:

per-forum or per-project moderators wouldn't have access to any archived messages (for now, at least).

That's perfectly fine, we only need that for global moderators so we can track potential abuse of the Archive functionality if necessary.

#14 follow-up: @Otto42
7 years ago

So, you're suggesting that they can disappear things that they then cannot see themselves or undo? That doesn't make a whole heck of a lot of sense. Seems like a recipe for more work for the forum mods, because people will click things randomly and not have any recourse afterwards.

#15 in reply to: ↑ 14 @SergeyBiryukov
7 years ago

Replying to Otto42:

So, you're suggesting that they can disappear things that they then cannot see themselves or undo?

Yeah, that's not ideal. I guess we should fix the latter two points from comment:12 as a part of this ticket then. That way per-forum moderators could see archived posts (maybe spam and pending too?) when they click the (+X hidden) link in a topic, and undo erroneous actions.

Global Spam/Pending/Archived views for per-forum moderators (with posts from the forums they can moderate) would still be a future enhancement.

Last edited 7 years ago by SergeyBiryukov (previous) (diff)

#16 @macmanx
7 years ago

That makes sense, thanks! :)

#17 @SergeyBiryukov
7 years ago

#2834 was marked as a duplicate.

This ticket was mentioned in Slack in #forums by sergey. View the logs.


7 years ago

#19 follow-up: @jimtrue
7 years ago

Would this also apply to reviews?

If it's possible (like the editing a reply), is there a mechanism to apply a reason that must be entered before archiving?

#20 in reply to: ↑ 19 ; follow-up: @SergeyBiryukov
7 years ago

Replying to jimtrue:

If it's possible (like the editing a reply), is there a mechanism to apply a reason that must be entered before archiving?

I think it's worth considering as a separate enhancement. Could you submit a new ticket for that? Thanks!

#21 in reply to: ↑ 20 @jimtrue
7 years ago

Done #2930

Replying to SergeyBiryukov:

Replying to jimtrue:

If it's possible (like the editing a reply), is there a mechanism to apply a reason that must be entered before archiving?

I think it's worth considering as a separate enhancement. Could you submit a new ticket for that? Thanks!

Last edited 7 years ago by SergeyBiryukov (previous) (diff)

This ticket was mentioned in Slack in #meta by sergey. View the logs.


7 years ago

#23 @danieltj
7 years ago

Replying to jimtrue:

Would this also apply to reviews?

If it's possible (like the editing a reply), is there a mechanism to apply a reason that must be entered before archiving?

I'd straight up say that reviews cannot be apart of this. The amount of people asking to remove reviews because they're at least somewhat negative clearly shows this would be abused. I don't seem the point in having reviews if they can be removed or hidden away.

I'd suggest a button to flag topics to moderators quickly so the support team can check them out rather than having plugin and theme developers manage sections themselves, it doesn't seem wise to open up these capabilities that are normally reserved for forum mods.

This ticket was mentioned in Slack in #forums by clorith. View the logs.


6 years ago

#25 @Clorith
6 years ago

I'm not a big fan of this, unfortunately we know it will be abused, and no proper plan for educating them on consequences exist at this time.

Such a plan should be a pre-requisite of any further planning.

#26 @Otto42
6 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Wontfix until we have a better idea. Not closed permanently, just until we come up with something that makes more sense.

#27 @Clorith
4 years ago

Related #2930 (so we don't forget it if we ever find an approach that works here)

Note: See TracTickets for help on using tickets.