OP here. We're happy to endure a three-day review process, but if it's going to take that long, then there needs to be a way to schedule an app release.

Today, Google has a "timed publishing" system for app updates, allowing you to submit an app update today and schedule it to go live on a future date (after successful review). We need the same system for new app releases.

Apple, which also has a multi-day review process for new apps, allows you to submit an app for approval and then hold it for manual release. After approval, you push the button on release day, and the app goes live immediately.

Also: surprising us with this on release day is really unprofessional of them. The "we'll take more time" warning banner doesn't show up until after you submit the app. There was no way to know we had to submit early until it was already too late to act.

Your post would benefit from focusing on the two real problems here

* Lack of timed publishing feature

* Lack of messaging about review until after submission

The message isn't clear and people seem to be reacting to the three day process (not the problem) instead of the messaging and features around it.

I thought the post was pretty clear on both of these things. I'm surprised that all the top-level comments here (at the time I write) are addressing only the longer review time - it seems clear enough that the real problem is that it's impossible to schedule a release properly.

So many people comment--on everything, not this post specifically--without reading anything more than the title of the HN post. They basically treat the title as a "topic suggestion" instead of reading the article itself.

It's a pretty annoying behavior because it means that discussions often end up wildly off-topic or with a lot of comments missing the point, or just re-stating the exact same things that the article already said (often because people ask questions that the article answered, but they didn't read it).

Unfortunately there's not really any good way to fix it. We had a big discussion about this same issue on Tildes recently too: https://tild.es/gjb

I consider this a feature more than a bug. I don't come here for the links. They're the same links that get posted to all the other link aggregators. Often the content is disappointingly thin, poorly written, or just a ranting opinion. Usually the content is packaged with an inane amount of bandwidth-hogging privacy-invading tracking scripts and malware. I make a point of not clicking the link unless something in the comments leads me to believe it will be compelling.

I come to hacker news to find out what the hacker news userbase thinks. I get a lot more value learning about a topic from the questions and answers smart people are posing to each other on a domain that isn't trying to cram garbage down my throat, even if they do end up rehashing one of the scant details or traipsing off-topic from the original submission.

You're talking about reading the comments before the post. That doesn't cause problems. The issue is for people making comments, and specifically comments about the article, without having read it.

I totally get it. I'm just saying those comments don't bother me. Oftentimes they lead to a correction and more interesting conversation that, again, saves me from having to click the actual link.

Of course I live for the comments where someone who has read the article posts a concise summary.

>Usually the content is packaged with an inane amount of bandwidth-hogging privacy-invading tracking scripts and malware.

And paywalls. Probably 1/4 of the time when I open a link "You've viewed your allotted 1 article this decade, please pay us $39.95 a month for access to our articles"

It seems like we're seeing the limitations of headline-only link submissions. Another symptom is focusing too much on getting headlines exactly right.

I'm wondering if adding a Tweet-length summary or pull quote to some posts would help?

Like Slashdot does? It certainly has merit, but that requires that someone actually write the summary, which is more work and injects (more) subjectivity.

You're absolutely right. I want less editorializing, not more.

How about using a title that points to the real problem?

"Google needs scheduled new app releases". Seems like a pretty good way to "fix" this, but I guess it wouldn't drive much traffic.

That doesn't fix anything, it just changes the problem. I guarantee a popular post with a title like that would get comments saying "it already has them" from people that didn't read the article and don't know about the new review process and mandatory wait.

Situations simply can't be covered well in a single sentence. That's a big part of why Twitter is such a terrible platform for discussing anything of substance, there's no room for context.

"Google increases app review time and removes timed releases [insert opinion]"

You could make a quiz for articles using machine learning and allow commenters to optionally complete quiz questions before commenting to earn a flag that says they've read the article.

It's not easy, but nothing worth doing is. And on the plus side, the question-answer problem already has a lot of contributed work [1]. And if you have a meager SE salary's worth to contribute I'm game to have a go at it =)

[1] https://aclweb.org/aclwiki/Question_Answering_(State_of_the_...

It makes it clear if you're really paying attention, familiar with this sort of thing to a degree, and thinking actively about what is going on.

However if you are skimming the article, reading the title, aren't particularly familiar with the topic (esp. non HN audience) it is easy to get the wrong impression. There's nothing wrong with not giving your full attention to a piece of writing, there is a lot of it out there and time is short, maximizing the value per time you get means lots of things get only a little attention.

A good article means a good title and a thesis that comes out and slaps you in the face right away. The title should be a short abstract of the whole (not bait but substance) preferably including the conclusion. The real meat of the title should be at the beginning of the title, not the end. The first paragraph should lead with a high level view of the content and the path the rest of the article is going to take.

The title and beginning of the piece should both contain the entire point and conclusion of the article and sell the reader on finishing the whole with expanded reasoning, details, and conclusions.

I believe the post makes it very clear, and the title, which some may consider misleading regarding your actual issues with the new policy, is appropriate because 1) that's the feature as presented by Google, and 2) is clearly just the tip of the iceberg when you notice the post is quite long.

It's clear after reading the article, but imho the news title gives different impression.

I made some subtle changes, mentioning that we're OK with planning ahead, and emphasizing that the lack of scheduled publishing is an even bigger problem.

I guess I could change the title? But I don't know what I'd change it to.

Release Scheduling is Impossible with Google's New Approval Process

Or something like that. Your current title doesn't indicate the problem. The first two words in mine contain the main topic and set the tone. This isn't about an extended release process, it's about scheduling the release.

Expecting to flip a switch for an app rollout is an anti-pattern. There's going to be a pretty slow propagation no matter what the policy is.

But at least you can have a “not before” policy, which is something you can work with in your marketing plan.

Very true. Even Apple's manual release can take 24 hours to be searchable in the app store. They do make this clear during the release process.

Started dipping my feet in app development recently. To get an app onto an Internal track for testing purposes..you still need to get 'reviewed'. literally a hello world app needs human review that takes 3 days. That blows my brain. Not open to the web. just testers. 3 days. painful. and imo. broken.

Luckily, you only need to get internal track approval the first time. After that, you can deploy changes to your own team with fast, automated review.

But, as my conversation with support showed, even after getting internal track approval, you'll need to wait another three days when you want to go live for production approval. ("It should be slightly quicker, but again we recommend three days just to be safe")

There’s still a review process for the “internal” track even for an established app, and sometimes it gets held up. I think “internal” is a misnomer, it doesn’t seem to be handled any differently from a closed alpha channel.

how can they know? any app published on play store should have to be reviewed. if you just want internal testing, not open to the web, sideload it.

A 3-day review period isn't going to change anything here. You'll still have rushed, rapidly-updating and poorly-reviewed games.

This shouldn't make things harder for marketing. Have plans drafted and set dates after approval.

As a marketer these 'launch the day the product is ready' goals don't usually get the best results. Often you burn power unnecessarily as you set activities up and then last minute delays are needed. This can loose money, goodwill with external parties and enthusiasm from the launch team. Or generally force to do things faster than you should properly plan and organise.

I always found this fast launch a bit illogical. You get one launch. Teams sometimes spend years developing a product but don't want to wait a couple weeks/months for a better launch once a product is ready.

What if there is a security update? I mean it sounds like this only applies to new apps, but if this gets extended to updates, you could have vulnerabilities out in the wild pending review.

Exactly. Hit this issue this week. I pushed out a change that had a bug, and the fix took 3 days... spent those days learning how to to do out of band updates from our own server in case hot fixes are needed.