Flutter Community Submission Guidelines
By: Scott Stoll
Tags: Guidelines, Writing

Greetings!

We want you to write great articles, and we know you want to write great articles.

To that end, we’d like to offer a few tips to help make sure you write the kind of great articles we can publish here at Flutter Community.

Submission

If you would like to have your article featured, please feel free to email or reach out to our Editors on Twitter to let us know. Please do not email us the article. Just let us know that you would like to be added as a writer so that Medium will give you the option to submit the article to the Flutter Community publication.

Note: When submitting articles, please do so in draft mode.

Email: community@flutter.zone

Twitter:

Nash — (@Nash0x7E2)

Simon — (@devangelslondon)

Scott — (@scottstoll2017)

Do’s:

Be informative. People are reading your article because they think you have something to tell them they don’t already know.

Make it a reasonable length. A technical article really should be at least four minutes. Anything shorter than four minutes isn’t really telling people very much and is probably too light in content for us to publish. In the other direction, anything over a nine-minute read tends to make the brain itch. If you’re getting close to nine, see if there’s a place you can break it into parts.

Use a header image in at the top of your article. It may not seem necessary when you’re on your article’s page but when it’s listed with other articles in a list, not having an image is going to make a bad impression. The image isn’t necessarily for those reading your article, it’s for people who are browsing the list on the front page.

Provide a place to pause. When an article is just a wall of text then people don’t absorb it very well. This is why experienced writers break an article up into chunks and have a header for each chunk, like the word “Do’s” over this chunk. It’s not just easier to read, it also provides a place for the reader to stop if they need to talk to someone else, chase their child or save the robot vacuum from the cat.

Add some humor. Make it fun. Toss in a gif of a cat… on a robot vacuum.

Even if you’re not being funny, use images… but make sure they make sense in the context of your article.

If you’re writing a new article that you want to publish in Flutter Community, please submit it to F.C. as a draft and don’t publish it to your own page until we publish it here. For one thing, we catch a ton of errors and you don’t want to put your article out there without first having someone go over it carefully. Second, it really does create some strange problems for us on the backend if you publish first and then submit it. Of course, if you’re submitting an article you published a long time ago, ignore all of this.

Are you talking about code? Then use a gist. Medium doesn’t work with the embed link but you can paste the HTML link from you gist in here and it’ll work just fine.

Be different. If you submit an article about how to parse JSON then we’re probably just going to send you to the links to all the other articles we’ve published about parsing JSON, like this awesome one by Pooja that already has over 3500 claps.

USE THE FREE VERSION OF GRAMMARLY. Unless you’re someone with poor English skills who is writing a fantastic technical article that takes on a topic in a great way, we’re not going to rewrite it for you. If an article is technically outstanding and written by someone who is trying their best to write in English, then we will invest three to five hours to rewrite it for them. We have a number of incredible Arab writers for whom English is not easy and, in the past, we’ve sometimes spent an entire day reworking the English in their articles because the articles were so great, they were worth it.

But if English is clearly your first language and you have spelling errors or can’t get “they’re”, “there” and “their” straight; your submission is going to get bounced back to you.

The last is something that applies to me, personally. I go back and reread every one of my articles about an hour after I publish, again two days after I publish and then again a week after I publish. Every single time I end up in a panic, yelling “WTF WAS I THINKING?!?!” while I frantically try to fix five or six embarrassing errors before anyone else might read the article.

You laugh… try it sometime.

Don’ts

Don’t send in “empty articles”. This means don’t send us pieces that tell the reader nothing they didn’t already know. Don’t send in an article that is just your opinion from start to finish, or that doesn’t contain anything the reader can use.

Don’t write three paragraphs about how you’re going to explain something and then copy the doc comments from the source code and try to pass it off as an article. It’s been tried. It won’t get published.

Don’t put installation instructions for a plugin or package in an article. People reading your article aren’t installing it; they’re reading your article because they’re trying to figure out if they want to install it. Besides, the installation instructions are right there in the Readme, we don’t need another copy of them here.

Don’t send us advertisements disguised as articles. “This is the greatest package ever! It’s so awesome, it’s the most awesomest awesome in the history of awesome!” Then we click on the link and see the article was written by the person who made the package.

Let me try to act shocked and surprised… … … … Nope, can’t do it.

Don’t thank your own repo for being so awesome. Yes, it actually happened…

Don’t spam us with a bunch of tiny articles that are all two to three minutes each, or even less, and don’t have much information in them. Especially when it’s nothing but a link to some package and a cut/paste of the Readme about how to install it. It’s pretty obvious when someone is spamming low-quality articles just because they want to be able to say they’ve written a bunch of published articles.

Don’t send us an article if we’ve already published a bunch of good articles on that topic unless the SDK has changed and you’re writing to tell people how to handle the new version, including how it differs from the way things were done before.

If a change in the SDK results in any existing article being wrong, then please let us know. We’ll pull the old one and start actively looking for a replacement. That’s going to happen quite a bit over the next couple of years; so if you’re looking for an opportunity to break into writing, then keep your eyes open. There will be plenty.

In Summary

We want you to write great stuff that we can post. The more great content people can find at Flutter Community, the better it is for everyone. But, at the same time, we can’t just fill up space with things that will leave people feeling like being here was a waste of time, or like they were being spammed with ads disguised as articles.

So remember… Be different, be informative, use Grammarly, don’t advertise and for goodness sake, don’t forget the most important thing:

Cat gifs get claps.