WordPress.org

Making WordPress.org

Opened 3 years ago

Last modified 17 months ago

#1560 reopened enhancement

Add "Delete this plugin" button on Admin page

Reported by: Ipstenu Owned by:
Milestone: Priority: normal
Component: Plugin Directory Keywords: 2nd-opinion
Cc:

Description

Example: https://wordpress.org/plugins/akismet/admin/

On that page, below committers have a button only the PRIMARY admin can see that emails plugins@ with a deletion request.

Optionally anyone with commit access, though in some cases that strikes me as ... iffy?

Change History (10)

#1 in reply to: ↑ description ; follow-up: @DrewAPicture
3 years ago

Replying to Ipstenu:

Example: https://wordpress.org/plugins/akismet/admin/

On that page, below committers have a button only the PRIMARY admin can see that emails plugins@ with a deletion request.

Optionally anyone with commit access, though in some cases that strikes me as ... iffy?

Good idea!

I agree on only giving the primary admin the button. Often times collaborating committers are just that, I don't think I'd want every committer to have the option to delete a group plugin.

#2 in reply to: ↑ 1 @Ipstenu
3 years ago

The only real change it makes to us as plugin repo mods is that there's a hidden 'primary owner' value we can see that they can't, and we'll need to remember to change it when a plugin's handed over. Small price to pay for easier abandons.

#3 @coffee2code
3 years ago

I don't see a problem with giving the ability to close a plugin to any plugin committer. After all, each committer could delete all plugin files and pretty much do whatever is allowed by plugin owners if they wanted. Closing isn't any more dangerous of a capability for committers.

Also, as @Ipstenu notes, the primary owner of the plugin is not an actively maintained field and may not accurately reflect the current owner (or even a committer). Singling out a sole owner runs counter to our desire to promote a more collaborative development culture around plugins. And it adds some unnecessary support for Plugin Directory admins in having to update and manage the primary owner field, answering why certain committers can't close the plugin, etc.

In practice, yeah, it can be a little iffy because we don't currently have a functional role for plugins between no role and committers. Such an in-between role would accommodate those who have elevated privileges but not commit (as would be used to grant support forums privs for the plugin). See #1413. So some plugins do currently give commit access to their support forum staff. But that's never been an approach we've advocated, and what I propose below (and definitely if in conjunction with #1413, if we're too worried it'd be too easy to close a plugin) would address this use case.

Here's what I'd suggest:

  • Add 'Close this plugin' button to the admin page as proposed ('Delete this plugin' is a bit misleading since we don't actually delete anything).
  • Above the button, add a descriptive paragraph/list explaining what happens when they click the button. (What "closing" a plugin means, reasons to close (and not to), the process involved for un-closing a plugin.)
  • When clicked:
    • Email all committers to let them know the plugin was closed by X user. (That way, like commits, they would get notified.)
    • Email plugins@ with a message indicating the plugin was closed by X user.
    • Directly close the plugin rather than it being a request submission. If we have adequate prefatory text, the author will just have to deal with any ramifications of doing so (e.g. having to submit a request to re-open with an explanation of why they want to have it re-opened, having to wait for a full review of the plugin, etc). And it saves Plugin Directory admins some effort.
  • For plugins that are already closed, replace the 'Close this plugin' button and text with an explanation about the plugin being closed and information about how to request re-opening the plugin (even if it's largely a link to plugin developers handbook).
  • (Possibly:) Provide a textarea for the user to supply a reason for closing the plugin. This would be included in the emails to all plugin committers, plugins@, and possibly logged as part of the plugin.

Just to be clear, other than the button label change and allowing the use of the button by any committer, this list only differs from @Ipstenu's request in that the plugin would get immediately closed without needing Plugin Directory admin intervention. The other tasks outlined are simply laying out the implied and sensible requisite components of the request.

#4 @Ipstenu
3 years ago

I like this. I like this a lot!

For plugins that are already closed, replace the 'Close this plugin' button and text with an explanation about the plugin being closed and information about how to request re-opening the plugin (even if it's largely a link to plugin developers handbook).

Only problem there is that we may have closed it for some reason or another. Security, attitude, etc.

If plugin was closed by admin: This plugin is closed. if you don't know why, please contact...

Else: This plugin was closed by X...

We could change the red alert bar to reflect that instead, so they don't have to trawl for it?

#5 follow-up: @coffee2code
3 years ago

We can add some sort of flag or cue to differentiate between user-invoked plugin closure and admin-invoked and then act accordingly in various places where that difference may matter.

We could change the red alert bar to reflect that instead, so they don't have to trawl for it?

Agreed, the alert notice could be amended with an additional message that says something to the effect of This plugin was closed by one of its committers. Please see the <a href="%s">plugin handbook</a> if you wish to request that it be reopened. The alert notice is already displayed prominently on every page of a closed plugin (which is only accessible to the plugin's committers) and foregoes the need to do anything more than removing/disabling the "Close this plugin" button on the admin tab.


We could also consider allowing committers to reopen a user-initiated plugin closure. Since they weren't closed by an admin for any reason we have concern about (security, guideline violation, etc) there's no real need for a review or admin intervention.


We should also be certain to allow admins to change a user-initiated closure to an admin-initiated closure, for cases where a user-closed plugin needs to stay closed and not reopened without a review.

#6 in reply to: ↑ 5 @Ipstenu
3 years ago

I'm on the fence about letting them close and reopen. It's usually a reason for one of us to step in and ask them WHY they keep closing and reopening. I can only imagine the system abuse since doesn't reopening rebuild the zips?

#7 @Ipstenu
2 years ago

After a lot of thought, I'm fine with people being able to close their own plugins, but not reopening. If they want to reopen, I want the review team to re-review and make sure they're up to today's security standards. This is for the safety of users.

A 'reopen' button should just be an email link (or feedback?) to the plugins team and prompt them to explain why they closed it and why they're reopening it. This will also let us have a talk with people who want to press fun buttons.

That does mean any close button should be clear that it's a one-way street. "Warning: Closing your plugin is intended to be a permanent action. You will not be able to reopen it without contacting the plugin team."

#8 @tellyworth
19 months ago

  • Keywords 2nd-opinion added
  • Resolution set to invalid
  • Status changed from new to closed

#9 @tellyworth
19 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

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


17 months ago

Note: See TracTickets for help on using tickets.