The cool thing about open source is that you can add features yourself, and even communicate directly with the developers about needs for new features. However, for us as developers it's sometimes really difficult to read feature requests, and we have a really big to-do list. So, having a well written feature proposal is very helpful for us and will lodge the idea better into our conscious.

Now, writing proposals is a bit of an art form in itself, and pretty difficult to do right.

So instead, what we primarily would like to know is HOW you intent to use the feature. This is the most important part. All Krita features are carefully considered in terms of the workflows they affect, and we will not start working on any feature unless we know why it is useful and how it is exactly used. Even better, once we know how it's used, we as developers can start thinking about what else we can do to make the workflow even more fluid!

Good examples of this approach can be found in the pop-up palette using tags, the layer docker redesign of 3.0, the onion skin docker and the time-line dockers, the assistants.

Other things that help:

• It is worth investigating first if the feature in question has similar functionality in Krita that might need to be extended to solve the problem. We in fact kind of expect that you have used Krita for a while before making feature requests. Check docs.krita.org for this.
• If your English is not very good or you have difficulty finding the right words, make pictures. If you need a drawing program, I heard Krita is pretty good.
• In fact, mock-ups are super useful! And why wouldn't you make them? Krita is a drawing program made for artists, and a lot of us developers are artists ourselves. Furthermore, this gets past that nasty problem called 'communication problems'. (Note: If you are trying to post images from photobucket, pasteboard or imgur, it is best to do so with [thumb=][/thumb]. The forum is pretty strict about image size, but thumb gets around this)
• The longer your request, the more formatting is appreciated. We're all pretty good at reading long incomprehensible texts, but if you format and organize your request we'll read it much faster and will be able to spent more time on giving feedback on the exact content. The more difficult the text is to read, the more likely we'll skip over the vital bits of the request. This also helps other users to understand you and give detailed feedback, which makes the proposal even more useful to us!
• It is actually preferred if you read and reply on other people's requests than to start from scratch yourself. For animation we've had the request for importing frames, instancing frames, adding audio support, from tons of different people, sometimes even in the same thread. We'd rather you reply to someone else's post(you can even reply to old posts) than to list it amongst other newer requests, as it makes it very difficult to tell those other requests appart, and it turns us into bookkeepers when we could have been programming.

Things that will not help.

There's certain things that people do to make their feature request sound important but are in-fact really unhelpful and even somewhat rude:

• Application X has this, thus Krita should implement it.
  We honestly don't care if application X has whatever feature, especially as long as you do not specify how it's used. This is especially nasty, because it cuts conversation short for us. Instead of thinking 'what can we do to make the best solution for this problem', it gets replaced with 'oh god, now I have to find a copy of application X, and then test it for a whole night to figure out every single feature... I have no time for this'.
• Professionals in the industry use this.
  Which professionals? What industry? We cater to digital illustrators, matte painters, comic book artists, texture artists, animators... These guys don't share an industry. This one is peculiar because it is often applied to features that professionals never actually use. We suspect it is done because people feel insecure about the request and want to make themselves seem more important. So this doesn't help your case at all.
• People need this.
  For the exact same reason as above. Why do they need it, and who are these 'people'?
• Krita will never be taken seriously/is DOOOMED if it doesn't have XXX.
  Sadly enough for these users, Krita is already taken very seriously by people we care about, so whenever that shows up in a feature request, it is the equivalent of the user lying to your face to get you upset enough to work on code. Think about how that must feel.
• This should be easy to implement.
  Well, the code is open and we have excellent build guides, why doesn't the user do it then? The issue with this statement is that very often, depending on the architecture of a program, something is not actually all that easy. What is worse is when people use this to pretend they know how programs work, but instead of making things easier this makes things more difficult as we as devs first need to identify what the user is actually trying to say, and where they are just plain using terms incorrectly. When you do know what you are talking about, you can do so, just bear in mind that if you aren't we will instantly get confused.
  
  A good example of this is the idea that because Krita has an OpenGL accelerated canvas, it is easy to have the filters be done on the GPU. It isn't: The GPU accelerated canvas is currently pretty one-way, and filters would be a two-way process. Getting that two way process right is very difficult and also the difference between GPU filters being faster than regular filters or them being unusable. And that problem is only the tip of the iceberg.

Other:

• It is actually possible to get your needed features into Krita outside of the Kickstarter sprints by funding it directly via the Krita foundation, you can mail the official email linked on krita.org for that.
• Sometimes developers have already had the feature in question on their radar for a very long time. You will then sometimes receive feedback like 'we first need to get this done', or they'll post an incomprehensible technical paragraph. This is a developer being in dep thought while they write. It is not meant to be dismissive, and you can just ask for clarification if the feedback contains too much technobabble.

You just wrote the manifest of proper feature request writing

It is the same problem in every softwares community,
I even drew some comic-strip (no, not in Krita ^^) about that (for REAPER audio editing software):

• ReaComics - ReaComics - 004 People will always find good...
• ReaComics - ReaComics - 001/002/003 For all people who posted...

When I write proper feature request, I often split the post into sections like :

• Context (in order to let the dev see what it is all about)
• Problem (why I didn't succeed to do what I wanted to do)
• Expected Behavior (what I would have expect, what I want in the optimum way from my point of view)
• Actual workaround (if I found any, to let the dev evaluate the priority)

and for that, formatting is very important.

Anyway, you article was good reading,

Congrats !

This topic should be "sticky'd" at the top of the forums.