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

[TacoVerdo]

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.

[TacoVerdo]

Example for the support role in the forums

[zoonini]

I think this is an excellent idea!

[DanielSantoro]

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.

[jeffstieler]

This would be great!

[shaunkuschel]

Love this!!

[Rynald0s]

YES!

[Ipstenu]

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.

[joostdevalk]

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

[TacoVerdo]

@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.

[fernashes]

Yes, please!

[jessepearson]

Amazing idea, two thumbs up from this guy.

[anonymized_7658014]

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.

[piratepenpen]

Yes please! would be so helpful!

[Ipstenu]

#2735 was marked as a duplicate.

[kraftbj]

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.

[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!

[mindywoo]

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

[kraftbj]

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 :)

[iMazed]

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

[LRehbein]

+1 here!

[Luminus]

+1 I'd love to see this shipped.

[davor.altman]

+1 definitely!

[wfasa]

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.

[Otto42]

Working on a proof of concept for this now.

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

[SergeyBiryukov]

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.

[SergeyBiryukov]

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.

[SergeyBiryukov]

In 5868:

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

See #2699.

[SergeyBiryukov]

In 5869:

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

See #2699.

[SergeyBiryukov]

In 5870:

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

See #2699.

[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.

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.

[SergeyBiryukov]

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.

[Ipstenu]

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

[SergeyBiryukov]

In 5904:

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

See #2699.

[dipakcg]

+1. It's really nice to have such feature.

[jobthomas]

@SergeyBiryukov are there plans to add this for theme support reps as well? As per https://meta.trac.wordpress.org/attachment/ticket/2699/2699.patch

// Themes do not have support reps right now. 
if ( $this->compat() == 'theme' ) { 
            $support_reps = array(); 
            return $support_reps; 
}

[dd32]

Replying to jobthomas:

@SergeyBiryukov are there plans to add this for theme support reps as well?

We currently have no way for themes to define such things - as we have no themes admin, nor plugins-readme.txt-style location we can pull the information from.

So for now, no.

[obenland]

@SergeyBiryukov What's left to do here?

[SergeyBiryukov]

Replying to obenland:

What's left to do here?

Theme directory needs some kind of UI for theme authors to manage theme reps.

Perhaps other tickets that currently suggest adding a readme.txt file (#45, #215, #969, #1358, #3718) could instead manage that data (changelogs, screenshots, requirements etc.) via that UI as well.

That way themes won't have to make updates just to change that file.

[Clorith]

Just nothing that the final step here would be to add support for support reps to themes as well, but this is currently blocked by the new theme directory rewrite.

I could not find a ticket for that, so I can't add any reference unfortunately, but as there is no management interface for themes, there's also no good way to manage support representatives there yet, but this is a high priority from a support point of view in getting them this functionality as well.

[SergeyBiryukov]

Replying to Clorith:

I could not find a ticket for that, so I can't add any reference unfortunately, but as there is no management interface for themes, there's also no good way to manage support representatives there yet

Created #5635 for the UI parts specifically, which should hopefully unblock this ticket :)

[courane01]

I'd like to see this included in the Plugin Handbook, not just a [P2 post from a few years back]​https://make.wordpress.org/plugins/2017/09/04/plugin-support-reps/. This looks the most relevant place: ​https://developer.wordpress.org/plugins/wordpress-org/planning-submitting-and-maintaining-plugins/. Who can direct me to where to add that? GitHub repo for a PR?