A message from the CEO of There.com regarding the Developer Program’s Peer Review System.

All,

I want to take some time to talk about the Developer Program’s Peer Review System.

When we resurrected There we needed to build a leaner organization, which meant, for example, we did things like moving our infrastructure to the Cloud.

One of our biggest innovations was the invention of the Peer Review System, which not only saved money, but involved the community directly in the submissions approval process. And, for the most part, it has worked well, with Peer Reviewers fulfilling the role of dedicated company staff.

Submissions need to be reviewed for multiple reasons:

– To get Developer content approved and available in-world as expeditiously as possible. Peer Review lets the approval process run independently of company hours and headcount restraints.

– To make sure Developer content adheres to our guidelines, like the “fig leaf” rule.

– To protect our Developers’ intellectual property (IP). That means if you take the time to create something, you can count on your Peer Reviewers to make sure someone else doesn’t use — a.k.a. “steal” — it.

– And, finally, to protect our Developers from accidentally or deliberately using IP which belongs to other companies or individuals, who might not only object to their content appearing in There, but might take legal action against us.

We all realize that these guidelines can be broken accidentally, or because someone didn’t understand the rules, or didn’t even know there was a rule. But the opposite is also true: some people deliberately break the rules or try to get around them.

Even worse, since it’s a Peer Review system, some people will try and influence, or even bully, other Developers into approving submissions which break the rules. By “bullying” we mean putting pressure on reviewers to approve items, or, even worse, to reverse item rejections. When bullying succeeds, items can get into the system which break the rules, which is not fair to There, other Developers, and/or outside organizations or individuals whose IP was stolen.

This causes other Developers to stop participating in the Peer Review System, or to blindly approve items which break the rules.

And then, when they’re discovered, There’s (small) staff has to spend time analyzing the items, contacting the Developers, and, if necessary, getting the item out of the world and out of people’s inventories. In many cases, other members may have bought the items, so we have to yank them from their inventory, which doesn’t make anyone happy.

You can see what a tangle this has become. We (Makena, and with the input of the Developers) built this excellent Peer Review System so we could keep There alive while still preserving our standards of IP integrity, and, for lack of a better word, “decency.”

The result is lots of staff time spent investigating, educating, warning, and remediating violating items, and worst of all, folks not even using the system.

So here’s what we’re going to do:

– Bullying will no longer be tolerated. If someone bullies another member into approving a submission, or for disapproving a submission, the penalties will be severe and will quickly result in permanent bans behavior for repeat offenders. Not bans from the Developer Program. Permanent bans from There.

– Much stronger penalties for IP violations and false claims of IP violations. These take an enormous amount of time to investigate and resolve, so it’s important people are incentivized not to do it. This includes IP violations of other members’ content.

– We will stop the informal practice of giving Designers a 24-hour grace period to cancel questionable items. This is because it often resulted in two things: Approvers would go in and reverse their positions from “approve” to “disapprove” to avoid losing points for approving a rejected item, and designers going ahead and listing the item anyway, which is an even bigger hassle. TLDR; “This is why we can’t have nice things”.

– We currently have a tiered system in place but it clearly hasn’t been as effective as we’d all like. As hinted above, we’re going to strengthen the penalties for blatant IP violations, and most certainly for bullying, which we will have zero tolerance for.

We completely understand that mistakes happen. Not everyone knows who the Coneheads are. Derivative works are genuinely confusing. Licensing fine print is a minefield. We will keep working with people on all of that. Deliberate abuse is a different thing and we are going to treat it that way.

With these measures, we hope to get people to participate more actively in the Peer Review System and reduce the number of violations we have to chase down and remediate.

We will post the rule revisions on the There Blog, and with revisions to the Developer Guidelines.

We’ll also reinforce where and how to report bullying behavior – feedback@thereinc.com – so we can address it quickly without a lot of back and forth trying to figure out what happened.

If this doesn’t work, we have a fallback: we’ll hire someone to do submission reviews (just like the old days) and raise prices to cover the costs. We don’t like this idea any more than you do.

It won’t come to that. We know that you know how important a healthy Developer ecosystem is and will work with us to keep it going.

Ok! Let’s go!

Michael Wilson
CEO, There.com

While our team works on revising the Developer Guidelines, we’d like to take this opportunity to gather valuable feedback from our Developer and Peer Review community.  Please take a moment to fill out the Peer Review Feedback Form.