Concept: A Developer Dashboard

One of the ideas that came from WCEU was a centralized dashboard for plugin developers. A place they could go to see all their plugins, and the current status on these plugins. What follows is concept art of what that kind of dashboard may look like.

This is something I dreamed up in Nacin’s talk about the government. This idea has no code backing behind it.

So why am I posting it? I’d like to hear people’s thoughts on this. What do you think would work or won’t work? Too much automation or not enough? Do you actually already HAVE this code written and want to share? Here is a zip of the Balsamiq Mockup: WP-Developer-Dashboard.bmpr_.zip – You know the drill. Edits welcome!

Concept Art

Goals

  • Make a centralized location for developers to manage their plugins

That’s really it. Making this public means a question of moving the ‘advanced’ tab to this page, and would it be duplicating data unnecessarily? In a way, it would move the developer page here as well, leaving only that which is controlled by the readme left on the readme. But then again, jumping between urls could be a mess. I don’t know. That’s why it’s a concept.

Also it should be easier for a developer to contact the plugin team when they have issues. And yes, the communication would be public, unless a comment is flagged as ‘security.’ Again, no code at all exists to make this a reality.

What’s Missing

There’s no contact form for a closed plugin. There should be. But this is really just concept art and starting to get an idea of what may work.

There’s also a dearth of data on the main dashboard page. That could lift from plugins like WP Dev Dashboard or WP Developers Homepage to fill in data. That’s the same general concept of what we’d want on the Support page (which you’ll notice is also left missing).

Misc. Thoughts

One of the stated goals we have is to allow everyone to leave a review on a plugin, with regards to the reviews before approval. In doing so, those reviews and all discussions about a plugin would need to be public. This is not necessarily a bad thing, though it will lead to some developers thinking long and hard about how they address issues in public. My concerns are that people who continually make the same error or neglect to fix something will be publicly embarrassed, but also that a free-for-all with reviews would lead to developers not wanting to host code here due to public backlash.

However, it’s been pointed out to me that coddling developers as much as we do may be causing them more harm in the long run. We do spend an inordinate amount of time hand-holding people who don’t want to take the time to read and think through a debugging process. Certainly we don’t mind helping out people who are brand new, or who aren’t native English speakers. But they’re vastly the minority of people who act the goat in our emails. And generally, they’re very respectful and nice.

Right now, my gut feeling is that there should still be a private way to talk about security issues.

But behavioural ones? They can be handled in public. It may stop people from some of the name-calling.

One At A Time

As of last week, plugin uploads are restricted to one at a time.

That means if you have a plugin in the queue, be it submitted for review, in review, or pending your reply, you may not submit a second plugin. You have to finish your first one (or ask us to reject it) before you can move on.

This is not for the same reason that Themes does it. To whit, you’re not restricted to keep the queue low (ours is usually only a 3 to 7 day backlog anyway). You’re all being restricted because people aren’t finishing reviews, and it’s become a drain on resources.

We have over 700 reviews waiting on the developer to get back to us.

Now some of those are cases where people lost the email, or missed it somehow. Other people get the email and don’t know what to do or decide it’s too much work to fix all the things. And worse, some people decided that they’d get the review and never use the directory. In order to prevent this sort of abuse, and the disrespect to everyone else who actually finishes a review and uses the hosting we provide, everyone’s being restricted.

This should not be onerous. We have a tiny backlog. To the point that some people get rather rude when they don’t get a reply in 36 hours. And yes, that’s exactly as annoying as you think it is.

One review at a time. One plugin at a time. Please give us at least 5 business days to reply to emails.

By the way. If you’ve submitted a plugin within the last 7 days and haven’t gotten a reply, check your spam because I promise, we ended Friday with an empty queue.

Reminder: Research Before You Sell Out

Are you thinking of selling your plugin? Did someone offer you money to put a link to their sites in your readme or wp-admin settings page?

STOP. THINK. BE CAUTIOUS.

I’m sure most of you are aware of the recent bad behaviour that’s gone on with regards to unscrupulous people purchasing plugins and using them to leverage malware, spam, and backdoors. While we would never tell you that it’s wrong to sell the plugins (they’re yours after all), we do want to help you recognize the warning signs of a bad-faith purchase.

Above all, if anything in the process makes you nervous and feel like something is wrong, call the deal off. You can email us at plugins@wordpress.org and we can help vet the buyer for you.

But remember this: The primary reason people want to buy ‘popular’ plugins is to use it to spam.

Signs To Watch Out For

Here are some basic red-flags:

  • You get an unsolicited email that reads like a generic form
  • The offer includes different prices based on how many people use the plugin (i.e. $500 for every 1000 users)
  • The amount offered seems to be rather high ($50,000 USD for a plugin)
  • The offer comes from a company who claims to be purchasing a ‘suite’ or ‘collection’ of plugins
  • They want you to sign an NDA, and not talk about the purchase
  • They don’t offer to show you an improvement of the code right away
  • They have (or plan to have) a special domain and user account just for this plugin
  • They have a brand new (less than a year old) account on WordPress.org with no other plugins
  • They have no visible, active participation in the WordPress community (forums, plugins, themes, WordCamps, etc)

Do Your Homework

When people come to us asking to adopt plugins, we vet them. We look at the code first. If there’s no new version of the code, with fixes, we don’t even consider it. If the prospective buyer of your plugin can’t show you how they’ll update it, don’t do it. Period.

No matter what you must do the work to vet these people. Ask them serious questions. How do they plan to handle support and reviews? How familiar are they with the directory guidelines? Do they already know how to use SVN? How will they take care of your existing users?

Review their code. Sit down and look over every single line of code and make sure it’s safe and well written. If you see base64 and it’s not for images, tell them no. If you see them phoning home, tell them no. If you see them doing things in an insecure way, tell them no.

At the end of the day, what they do is going to reflect on YOU, and your reputation could suffer.

Many times, good developers find their names dragged through the mud when a plugin they own is purchased by people who do horrible things with their code. Make absolutely certain, beyond shadow of a doubt, that they understand what owning the plugin means, and that they must abide by all the plugin and forum guidelines.

Worst Case Scenario

If we find out you sold your plugin to someone who does evil with it, the odds are you won’t get that plugin back. Among other reasons, you sold it. To have you take someone’s money for the access, and then give it back to you, would be tantamount to theft. At the very least, it would be a bad-faith action on our part. Once you sell a plugin, accept the money, and your access is removed, that’s it. You’ve indicated you’re done with it, and we will enforce that.

This means if evil is done and we need to fix the plugin, we’ll roll it back to a safe version, remove everyone’s access, and disable the plugin permanently. That will it will push a final update, but no one new can install it. We feel that once a plugin has been sold and used like that, it’s near impossible to recover any reputation, and it’s better for the community to walk away.

Should You Sell Your Plugins?

The directory was never intended to be a sales marketplace, and it’s unlikely it will ever be one. If your deepest wish is to make a super popular plugin and sell it for gobs of money, this is probably not the place for you. Selling your plugin is a chancy business, and it’s hard to make money legitimately on a free plugin. After all, they can legally just fork it and make a new one.

You certainly can sell your plugins, but sell it smartly. At the end of the day, it may be better to retire a plugin than sell it or give it away to someone you’re not sure will do good.

#notice, #warning

SWFUpload To Be Removed From Core

Removing SWFUpload

If your plugin is using SWFUpload, please remove it and switch to Plupload. If you’re a security plugin scanning for it, you’re fine. If your plugin is using it, or including your own, it’s time to upgrade.

#announcement

x-post: Community Conduct Project Kick-off Meeting

Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017

#announcement

2017 Community Summit Notes

The Plugin team is small but mighty. We had a very productive summit and contributor day this year, pushing forward some of the changes we’ve been working on for a while. The following notes are the product of the sessions as well as some hallway chats over red wine, gin, and cheese.

Notes:

  • Security issues in the new directory have to be corrected before new users can be added
  • We intend to open reviews by everyone (yes, everyone) with a .org account
  • Plugin Closures will be documented and then reported on
  • Plugin Check code revisited – What can we catch as a ‘before a human reviews’
  • Similar but not identical plugins will continue to be accepted
  • We need to allow frameworks in, but we have to do so safely to protect developers from hate-reviews when someone deletes a required framework

To Do:

  • Design a ‘dashboard’ for people to check the status of their plugins (and themes)
  • Add more stats to the plugin page (or possibly move to the future dashboard…)
  • Replace SupportPress (our email client) with something that works (possibly Support Flow?)
  • Code out a way to publicly track why a plugin was closed (see Meta 2860 and 2627)
  • Determine if we want to backfill why 6500-ish plugins are currently closed (owwwww)
  • Determine the best way to track ‘dependancies’ (in lieu of 22316 ever getting traction …) so frameworks and add-on plugins can be clearly indicated and reduce errors
  • Incorporate theme review features such as a11y and i18n ready flags
  • Make sure the VVV repo for the meta environment is sufficient for more people to contribute (see Meta Env)
  • Hold ‘open office’ hours to discuss topics like developer tools, what stats are needed, frameworks etc

Most of that to-do is on me to at least get the tickets started, but if these are things you’re interested in, then I encourage you to come to the open office hours! I’m hoping to have the first in August, as I have July Vacations 🙂 Sorry, family first!

I’ll post more about what I plan to do with the open office hours soon, including topics and schedules.

#community-summit, #contributor-day

Test With Gutenberg Please!

Call for testing: Gutenberg

This is especially important if your plugin adds meta boxes or otherwise makes changes to the editor. PLEASE test early and often.

Search Issues

UPDATE (@dd32): All issues should be resolved as of 2:15AM UTC. The root cause was a change in the behaviour of Jetpack Search which we rely upon causing queries to fail. A network outage had caused issues for some queries earlier in the day, but was completely unrelated.

You may have noticed that search is acting up. Per @dd32:

w.org is experiencing a few network issues at present in the datacenter, it’s likely that connectivity between the API and wp.com’s elastic search is up-and-down, and when it’s down, search will be offline.

Yes, that means search for plugins too.

There’s nothing to do but wait at this point. It may be up and down while the connectivity is being sorted.

X-posting Proposal: WordPress Community Conduct Project

Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

New Directory Status

As everyone knows, the first phase of opening up the directory to more reviewers was getting on the new system. We’re not quite there yet, however a great deal of progress has been made!

So far, we’ve run into a few weird flow issues that are blocking us from being able to invite new people. The biggest issue is that if you know the old system, it’s easy to move tickets through the new one. But it’s set up in a way that is very very easy to make mistakes and put tickets in unrecoverable states. So we need to mitigate that as much as possible before we let new people in. Basically we don’t want to break things for users because we didn’t think about use-cases.

Okay, fine, you say. What can you do to help?

I’m glad you asked!

We have 100 tickets open in Meta Trac. You can install the meta-environment in VVV and help us out with patches. Sadly, the meta env isn’t complete. It’s missing data, so you’ll end up having to add in plugins in order to mess with the state flow.

But if you can’t patch, and I do understand that, remember to come to the Plugin Directory revamp meetings on Wednesday at 2200 UTC in #meta on Slack. And please, test test test everything! The more we break the directory, the better it is 🙂