After we started pushing back on the auto-reply stuff, a couple plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party devs said that they used their support accounts (like support@example.com) as their committer so that they could get email updates from the forums.
This is a terrible idea. It’s insecure and rather dangerous.
That means the support account is the one with write access to your plugin. And that means anyone with access to your group email (or your support tool) can click on reset password, get the password, change it, and blow up your plugin. Obviously that’s a major security issue. The only people who should have write access to your plugin should be people who know how to code and are responsible and reliable and trustworthy. And remember, people can go nutters in a company of any size and seek out revenge in weird ways. Limiting the damage they can do is your responsibility.
This also means that when we send you an email about your plugin, you may be accidentally sharing privileged information with people who have no business knowing these things. With a support account for a company of four people, it may be okay for everyone to know your plugin was pulled from the repository for a security hole. When you have a company of 300 and you use a system like ZenDesk (not to pick on them, but they are popular), now everyone knows. This may not seem like a big deal, but if one person tweets “OMG! Plugin FOO has a security hole!” then there’s a major risk that you’ve opened up the floodgates of potential hacks. Limiting the risks you put on your users is important.
Only allow your developer account(s) to have commit access to your plugin.
If you want one joint email-alias (wp-plugin-dev@example.com) that forwards to everyone, that’s okay, but not great. Remember, if everyone has their OWN user account, then you can easily track who pushed what change to a system. If you’re only using SVN Short for "SubVersioN", it's the code management system used to maintain the plugins hosted on WordPress.org. It's similar to git. as your version control, it’s a good idea to make sure you know who did what. If you’re using Git Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. or Mercurial or your own SVN to track the changes, then make sure that only responsible, reliable, people have access to that dev account. Again, remember that we’re talking about access to push code to (say) a million users.
Remember: Anyone listed as a developer has the ability to remove anyone else as a committer. So you really want to limit those users.
Make a separate account to handle support
Make a separate account (wp-plugin-support@example.com) that does whatever it needs to do. Then you can sign up for email alerts. Go to https://wordpress.org/support/plugin/YOUR-PLUGIN and scroll to the bottom where it says “Subscribe to Emails for this Plugin”:
Click “Subscribe to Emails for this Plugin” when logged in.
Click the link and baboom, that account gets email alerts. You can do the same for reviews at https://wordpress.org/support/view/plugin-reviews/YOUR-PLUGIN if you want to catch the inevitable ‘this review should have been a support post’ threads.
Remember: If you sign a support account up for getting those emails, you should still disable auto-replies. Otherwise you’ll be generating a lot of unnecessary email every time someone replies to your threads and you may get caught as a spammer.
Add your support accounts as Contributors
Contributors are the people you list under the ‘Authors’ field on your readme. They do not have any commit access to a plugin. They can’t edit the code.
Example: “Automattic” has an account for Jetpack. That account can be a placeholder account. It can be a support account if you want to use it in the forums. It can be marked as a Contributor in the plugin’s readme.txt in order to get special markings in the forums for replies from that account for that plugin.
The other accounts should be individual accounts, belonging to the devs, and preferably using their company email addresses. This way, if the organization changes, an individual leaves, etc, the email address still goes to the company and the plugin can be recovered, if necessary.
Back on Jetpack, there are over 70 people listed as ‘authors.’ They all get that happy plugin author green lozenge in their forum replies and they can officially help people without you worrying they’ll miss a semi-colon and take down 20 thousand users with a bad push of code.
Remember: Anyone listed as an author is going to get that green lozenge. If you don’t want people representing you, credit them in the readme but remove them as an author.
#reminder, #security
