Opened 8 years 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: | high | |
Component: | Support Forums | Keywords: | has-patch |
Cc: |
Description (last modified by )
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)
Change History (56)
This ticket was mentioned in Slack in #forums by tacoverdo. View the logs.
8 years ago
#3
@
8 years 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.
This ticket was mentioned in Slack in #meta by joostdevalk. View the logs.
8 years ago
#8
@
8 years 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
@
8 years 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
@
8 years 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.
#13
@
8 years 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.
This ticket was mentioned in Slack in #meta by tacoverdo. View the logs.
8 years ago
#17
@
8 years 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:
↓ 20
@
8 years 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!
#20
in reply to:
↑ 18
@
8 years 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
@
8 years ago
Another +1 from me. This is something I think a lot of (growing) plugin devs/companies need.
This ticket was mentioned in Slack in #meta by ocean90. View the logs.
8 years ago
#26
@
8 years 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
- Allows thread resolve but not code commit
- Is not subject to spam filtering/rate limiting
- 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
@
8 years 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
This ticket was mentioned in Slack in #forums by sergey. View the logs.
7 years ago
#30
in reply to:
↑ description
@
7 years 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.
7 years ago
#36
follow-up:
↓ 37
@
7 years 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
@
7 years 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
@
7 years 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.
7 years ago
This ticket was mentioned in Slack in #forums by zoonini. View the logs.
7 years ago
#43
follow-up:
↓ 44
@
7 years ago
@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; }
#44
in reply to:
↑ 43
@
7 years ago
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.
This ticket was mentioned in Slack in #meta by sergey. View the logs.
7 years ago
This ticket was mentioned in Slack in #meta by sergey. View the logs.
6 years ago
#48
in reply to:
↑ 46
@
6 years ago
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.
This ticket was mentioned in Slack in #forums by clorith. View the logs.
4 years ago
#50
follow-up:
↓ 52
@
4 years ago
- Priority changed from normal to high
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.
This ticket was mentioned in Slack in #meta by tellyworth. View the logs.
4 years ago
#52
in reply to:
↑ 50
@
4 years ago
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 :)
This ticket was mentioned in Slack in #forums by zoonini. View the logs.
19 months ago
#54
@
2 weeks ago
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?
Example for the support role in the forums