WordPress.org

Making WordPress.org

Opened 6 months ago

Last modified 2 weeks ago

#2699 accepted enhancement

Add a new role to the forums: plugin/theme support

Reported by: TacoVerdo Owned by: Otto42
Milestone: Priority: normal
Component: Support Forums Keywords: has-patch
Cc:

Description (last modified by SergeyBiryukov)

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

Problem description
However, some of the larger plugin/theme shops have a support team to help out on their own support forums. I think it would be useful to be able to recognize those people in the support forums, like we’re able to recognize authors.

Proposal
So what I would like to propose is adding a new role: Plugin/Theme Support. Everyone with this role should have rights to mark topics within their own support forum as resolved, and should not be affected by posting speed limitations for their own support forum. This role should also show in the forums as ‘Support’, similar to author.

The reason why I propose a new role, instead of adding the capability to the contributor role is because, in my opinion, they serve a different purpose. Let me explain.

A contributor is someone who helped your open source project forward. This can be by providing feedback, writing code, creating images, doing marketing or being a friend of the project, for example.

Someone working on support does contribute his/her (paid) time to your project and is in that way a contributor. However, I think there are more than enough valid use cases where you don’t want someone who contributed code (for example) once to be able to close support request on behalf of the author.

That’s why I think having a separate support role would be viable. It would show the community that this person is vetted and answering on behalf of the plugin/theme author.

Related ticket
This proposal is related to ticket #2598.

Managing support role
Of course, it should be possible for plugin authors to manage the list of support people. I see two reasonable ways to do so, which should be mutually exclusive.

One way is by adding the usernames to the readme.txt file, the same way contributors are currently added. The other way would be to add users the same way committers are currently added, on the Advanced View of the plugin.

Showing support staff
To be transparent about this, we’d probably also need a place to list people in the support role. This could be the Advanced View page, or even the plugin page itself.

Attachments (2)

Example_Support_Role_Forums.png (115.8 KB) - added by TacoVerdo 6 months ago.
Example for the support role in the forums
2699.patch (8.9 KB) - added by SergeyBiryukov 7 weeks ago.

Download all attachments as: .zip

Change History (42)

@TacoVerdo
6 months ago

Example for the support role in the forums

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


6 months ago

#2 @zoonini
6 months ago

I think this is an excellent idea!

#3 @DanielSantoro
6 months ago

Seconded! It'd be great to have this for something like WooCommerce, where we've got a ton of support agents. Even small plugins like I've developed in collaboration with other people would be handy.

#4 @jeffstieler
6 months ago

This would be great!

#5 @shaunkuschel
6 months ago

Love this!!

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


6 months ago

#8 @Ipstenu
6 months ago

How often do you rotate support staff in and out? Determining where this is best 'stored' (plugin like committers, or readme like authors) depends on how much you're switching etc :D

Also WHO should have access to do it. Right now, committers can add/remove any other committers. So if you keep it in the readme, that remains the same for supporters.

#9 @joostdevalk
6 months ago

These teams can get quite large. I'd give committers access to this list, and manage them through .org, not through the readme...

#10 @TacoVerdo
6 months ago

@Ipstenu As teams grow larger, it's more likely they change more often. Keeping that in mind, I think managing them on .org in the Advanced View makes the most sense (especially if we're not trying to do that in the sidebar too).

And I agree with @joostdevalk that this should only be manageable by committers. I don't see why contributors should be able to add/remove support staff, or why support staff should be able to add/remove each other. Appointing someone in a support role really is endorsing them as spokesperson of the plugin. And that should, in my opinion, be done by a committer/owner of the project.

#11 @fernashes
6 months ago

Yes, please!

#12 @jessepearson
6 months ago

Amazing idea, two thumbs up from this guy.

#13 @glueckpress
6 months ago

I think this can even be useful for smaller teams or single plugin authors. Support isn’t everyone’s greatest strength, so “outsourcing” it to a friend, a teammate, or a service provider even would likely become easier with a dedicated supporter role.

#14 @piratepenpen
6 months ago

Yes please! would be so helpful!

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


6 months ago

#16 @Ipstenu
5 months ago

#2735 was marked as a duplicate.

#17 @kraftbj
5 months ago

I like this and would like to see something outside of readme.txt. One issue I've ran into with our current way of marking support staff as committers is w.org seems to only care if it is in the stable version readme (same for updated version). If a new support person comes on board, to immediately give them powers, I need to either ship a new version or add them as a committer until the next stable release ships.

Under @TacoVerdo's vision of "Contributor", that's fine for the readme, but a support person, it would be nice not to tie their abilities to a release cycle.

#18 follow-up: @Ipstenu
5 months ago

@kraftbj You don't have to release a new version to do that. You can just push an update to the readmes. Though that may cause versioning issues in some cases.

We have no prohibitions against you updating the stable tag's readme :) Heck, if you have an egregious typo we encourage it!

#19 @mindywoo
5 months ago

Big +1 to this! Would be great to have :)

#20 in reply to: ↑ 18 @kraftbj
5 months ago

Replying to Ipstenu:

@kraftbj You don't have to release a new version to do that. You can just push an update to the readmes. Though that may cause versioning issues in some cases.

We have no prohibitions against you updating the stable tag's readme :) Heck, if you have an egregious typo we encourage it!

@Ipstenu, In Jetpack, we always get a bump of folks using WordFence who alerts folks that their local version of a plugin changed because it no longer matches the w.org variant, so we've avoided updating the stable tag's readme except in pressing circumstances (and usually only immediately following release). Even if a false-positive, don't want folks to hear that their Jetpack was hacked :)

#21 @iMazed
5 months ago

Another +1 from me. This is something I think a lot of (growing) plugin devs/companies need.

#22 @LRehbein
5 months ago

+1 here!

#23 @Luminus
5 months ago

+1 I'd love to see this shipped.

#24 @davor.altman
5 months ago

+1 definitely!

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


4 months ago

#26 @wfasa
4 months ago

I wanted to pitch in here and argue for the exact same thing but for a different reason. While I agree with all of the above, I think adding a support role could also increase security. If an account with commit privileges was compromised it could cause a lot of trouble for the plugin authors, plugin users and potentially also for wordpress.org staff (helping authors clean up the mess). Users who only work the forums providing support do not need commit privileges. So for security reasons, it makes sense to limit commit privileges to only those who actually need it. I'm therefore very much in favor of a separate support role that

  1. Allows thread resolve but not code commit
  2. Is not subject to spam filtering/rate limiting
  3. Shows up with a "support" tag in the forums

Thanks to @ocean90 for showing me this thread. And re:@kraftbj comment above, in Wordfence 6.3.5 we made a slight modification so readme.txt files will now only be flagged in scan if "High sensitivity" scan option is enabled. You may still see those warnings, but it shouldn't be as often.

#27 @Otto42
3 months ago

  • Owner set to Otto42
  • Status changed from new to accepted

Working on a proof of concept for this now.

Live test, not final: https://meta.trac.wordpress.org/changeset/5563

Last edited 3 months ago by Otto42 (previous) (diff)

#28 @SergeyBiryukov
2 months ago

  • Description modified (diff)

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


2 months ago

@SergeyBiryukov
7 weeks ago

#30 in reply to: ↑ description @SergeyBiryukov
7 weeks ago

  • Keywords has-patch added

Replying to TacoVerdo:

Of course, it should be possible for plugin authors to manage the list of support people.

Created #3029 for that.

2699.patch handles integration with the Plugin Directory (depends on the patch in #3029 being committed first) and adds the Plugin Support badge.

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


6 weeks ago

#32 @SergeyBiryukov
3 weeks ago

In 5867:

Plugin Directory: Introduce UI for managing plugin support reps.

Support representatives can mark forum topics as resolved or sticky (same as plugin authors and contributors), but don't have commit access to the plugin.

See #3029, #2699.

#33 @SergeyBiryukov
3 weeks ago

In 5868:

Support Forums: Introduce Directory_Compat::get_support_reps() method to retrieve users assigned as the plugin/theme support reps.

See #2699.

#34 @SergeyBiryukov
3 weeks ago

In 5869:

Support Forums, User Badges: Add "Plugin Support" badge for users assigned as the plugin support reps.

See #2699.

#35 @SergeyBiryukov
3 weeks ago

In 5870:

Support Theme: Add styles for "Plugin Support" badge.

See #2699.

#36 follow-up: @danieltj
3 weeks ago

Should support reps also get profile badges as well? I think with their being such an emphasis on having an actual badge within the forums, there should also be a profile badge that the user can obtain as well.

Although this raises the question as to what icon it should have. Personally, if they're are identifiable within the forums, identifying them outside the forums is also a good idea.

#37 in reply to: ↑ 36 @SergeyBiryukov
3 weeks ago

Replying to danieltj:

Should support reps also get profile badges as well? I think with their being such an emphasis on having an actual badge within the forums, there should also be a profile badge that the user can obtain as well.

If they're actively contributing to the forums, they should get a Support profile badge once #2214 is implemented.

#38 @Ipstenu
3 weeks ago

And if it were a special badge (like for plugin dev) that would be a separate ticket :)

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


3 weeks ago

#40 @SergeyBiryukov
2 weeks ago

In 5904:

Support Theme: Add styles for "Plugin Support" badge in moderator views, search results, and user's Replies Created view.

See #2699.

Note: See TracTickets for help on using tickets.