Ask HN: How to say no?
6 comments
As a developer I don't write anything I submit anywhere, but I have had some experience with rejection letters when trying to publish my comics. Most publishers have a standard polite rejection that says the comic doesn't fit in any of their collections. But my favorite rejection letter was actually a checklist. It was a pretty devastating list of everything that could go wrong in a comic, but only one item was checked. It was a relief to see that while I didn't meet their criterias I still had most things right.
This was a relatively small publisher at the time and I suppose that they had started by writing a letter for every rejection, then found that many of these letters fell into similar categories, which allowed them to rationalize the process when they started getting more propositions.
This was a relatively small publisher at the time and I suppose that they had started by writing a letter for every rejection, then found that many of these letters fell into similar categories, which allowed them to rationalize the process when they started getting more propositions.
If you provide a check-list or other criteria, be prepared for a world of pain. There will be people who claim they qualify, and they won't let go. They really, really won't let go.
They will harrass and harrangue you, they will call you liar, cheats, thieves and worse in public, and they will question your parentage and, what's worse, your ethics and morality.
And they won't stop.
I speak from experience.
You may choose to publish somewhere a list of things you consider, but say it's incomplete and for guidance purposes only. You may choose to provide a form response to those who you choose not to accept/list/whatever, and you may say that while it's no doubt worthy in it's own right you've decided it's not a good fit for your service.
Just don't be specific.
They will harrass and harrangue you, they will call you liar, cheats, thieves and worse in public, and they will question your parentage and, what's worse, your ethics and morality.
And they won't stop.
I speak from experience.
You may choose to publish somewhere a list of things you consider, but say it's incomplete and for guidance purposes only. You may choose to provide a form response to those who you choose not to accept/list/whatever, and you may say that while it's no doubt worthy in it's own right you've decided it's not a good fit for your service.
Just don't be specific.
This is exactly the same reason why people who are hiring and decide not to give you a job offer usually won't say why they passed. There is a large percentage of people who can't take rejection.
I guess that explains Apple's app store policy.
I feel like you all are about to open a huge can of worms.
Maybe you guys can have a two tier system? Games and apps you've tested and vetted and those you haven't yet or won't? Users of you system could go into your curated list or sift the unchecked section to find some unknown gems.
Maybe you guys can have a two tier system? Games and apps you've tested and vetted and those you haven't yet or won't? Users of you system could go into your curated list or sift the unchecked section to find some unknown gems.
Yeah. That's how it's been done for ages, at least as far back as Tucows.
1) List everything you can find.
2) Rate and show the ones you have reviewed first.
1) List everything you can find.
2) Rate and show the ones you have reviewed first.
Yes. But I would say innovate a little, and perhaps drop games that don't get any ratings after a certain time (e.g., 6 months) and/or games that consistently get rated poorly by users.
Usability innovation at that level will have to be accompanied with tests. But for now, it's a good idea to be very liberal in what you accept, at least so you can have a big enough catalog that you can refine at leisure later.
Why not just tell them if there is something specific, but failing that just repeat what you just said: you want to focus on keeping the catalogue small, which means that some applications that are otherwise appropriate will be omitted. Invite them to email you back if and when they release and update to their project and promise to reassess it at that time.
The Flash industry suffers the same curse. I can and do remove games and even entire accounts from my distribution feed. One thing I did do to mitigate it is to let individual people have their own personal listings so people can still get their games if they're explicitly looking for them.
Ultimately you have to just man up, ignore the details and don't even bother telling them why they're rejected - that sucks for the developer but it'll sap your resources and you'll get stuck arguing about it. Just send a nice, generic, neutral message:
"Your game has been declined because it does not meet our quality standards. Please review them at x and remember to polish your game until it shines."
If you want to be extra nice link to them some resources on the importance of polish.
Ultimately you have to just man up, ignore the details and don't even bother telling them why they're rejected - that sucks for the developer but it'll sap your resources and you'll get stuck arguing about it. Just send a nice, generic, neutral message:
"Your game has been declined because it does not meet our quality standards. Please review them at x and remember to polish your game until it shines."
If you want to be extra nice link to them some resources on the importance of polish.
Indeed, there is such a low barrier of entry to creating games these days with kits and drag / drop interfaces available. It is great for the developers starting out, but generally speaking content made in this manner lacks the polish that is required to stand out.
What if you tell them one specific thing to work on (whatever their major downfall was), and then be vague about the rest? Then, even if they insist that that one problem area was actually good, you can point to the part that vaguely says something like "Though your game is not a suitable match to our site for a few reasons, [we suggest you work on blah blah blah]..."
I don't have any experience with rejecting people in this situation, but I know it would be nice as a developer to have something to try to improve after a failure/rejection.
I don't have any experience with rejecting people in this situation, but I know it would be nice as a developer to have something to try to improve after a failure/rejection.
One of our aims to differentiate our product is to create an open platform which lists free games and mods as well as commercial games and indies. This doesn’t however mean that we want to list absolutely everything as I believe this degrades the user experience and draws attention away from developers that go above and beyond to polish their work.
For example the iPhone app store: I find it crazy that they brag about having hundreds and thousands of apps and yet only 50 apps in the top charts get any coverage. As a developer who spent ages working on perfecting an app - i'd find it annoying to have my app drowned in a sea of duplicates. As a user I find it frustrating that when I want an app that does X there are hundreds of matches, the majority of which are quickly built. I know there is a good app in there, but finding it is a real challenge. Many times now i've brought an app with great reviews and description only to discover it isn't as good as another app a friend recommends a week later. It isn't a user experience I enjoy.
The challenge is that no one wants to be told their game or mod doesn't qualify - so most digital distribution services simply ignore the majority of applications and only respond to those they are interested in. While that would be easy to do, we view that as a cheap cop-out (is there anything more infuriating than having your email ignored?) so instead we want to tell developers the areas they don't qualify. But that is equally challenging because there is no easy way to say no and not everyone will agree with our reasoning so we want to come up with a basic checklist which we can give to teams. This way everyone is graded by the same criteria, and if teams want us to explain beyond the checklist we can.
Obviously being bug free, legal and owning full rights is a must. After that we hit the grey area of criteria such as: not unique, polished, suitable or deep enough. What information should we provide in this checklist? As a developer how would you like to be responded to, good or bad?