Is there something we can help with with my knowledge? Proposal for the forum

Well to know who is using and how you can just make a post on the news feed for a link to a simple questionere.

I would venture the biggest reason people ask for things that are in another program is because they came from that program and rather then trying the Krita way first and seeing what truly does work better. That doesn’t mean that features can’t be added that are in other programs, there just has to be more than just “make it like the other program”. To give a recent one I remember, with the eraser stuff where someone wanted the dedicated eraser tool because they were used to it that way. But Krita has far more control over erasing than many other programs as pretty much most tools can act as an eraser. It also adds yet more bloat to the toolbox. This would be an example of simply asking for a feature from another program without knowing the workflow of Krita. Now if a user is familiar with Krita and other tools, a more better request would to have the ability to add/remove tools from the toolbox, and preconfigure presets. This way, someone can have their eraser tool, while those who don’t want it don’t have it fill their toolbox, but also can benefit for preconfiguring other tools.

The devs my guess just want to be sure that you are thinking what is best way to integrate something, not simply because it is integrated that way by other software on a completely different workflow. It’s like painting, if you were to take all famous painting and put them all into 1 painting, it would look more like Frankenstein than another masterpiece.

Of course I understand that isn’t what you were asking for, just pointing out that a lot of requests are like that.

I understand that, taking a quick look at that post the devs did respond to it. Though it sounds like a specific issue with specific hardware correct? And to debug something like that, a dev needs access to the hardware. Developing blindly takes 100x more effort then developing something that a dev can replicate. You providing these details does give devs a better idea of what the issue might be and work on general fixes that may end up fixing your issue. But unless something is replicatable, they can only guess. Krita has added features to the tablet settings for better compatibility, 5.1 has new settings for max brush speed and brush smoothing for tablet settings to overall improve experience.

The response for that wasn’t “‘yeah that sucks’ and then sat dormant because only professional artists would notice this stuff.”, the response looking at the thread is that they are redoing it piece by piece. And considering the timing, I’d imagine getting 5.0 resource rewrite held priority. I would open a bug report for it. Or simply follow up with the dev who responded in the thread.

Do note, the official way to report issues or bugs is through bugzilla. If you post it on the forum, there is no guarantee a dev will see it. Now generally, the forum acts as a great way to fix issues for average users or get people talking about fleshing out features before requesting it officially. but in your case, it seems like you are tech savvy enough, so in case of issue you should make a bugzilla report. Or put it on both the reports and on the forum. If you know who the dev was who worked on the feature, you can even @ them on the forum I guess. Otherwise, not responding doesn’t mean you were ignored, it simply may have been missed.

In general, regressions would probably have higher priority, because nothing is worse than things breaking that used to work

It is, I don’t disagree. But do you know why the loud minority often get more say than the silent majority? Developers as mentioned have limited staff and funding. Which means the more people participate in the process, the more things that can get done.

Maybe that would be the answer to @Whikebain , somebody who gets opinions of people and brings them forward during technical discussions and makes sure old features or bugs are not forgotten, retesting old bugzilla requests to see if they are still valid or should be closed.

That is one of the beauty of open source :slight_smile:

Krita’s focus is artists, things like photo editing or memes are things that are not the focus and low priority. Krita has never claimed to be “everyone”. As for features being added, as mentioned, that not all features are added by the dev team. There are features added by volunteers as well. There is also some features that get added via sponsorship or the like.

Not to mention sometimes a dev can get caught up in something due to inspiration. That often yields better productivity. (Do you know how hard it is to program X when Y is eating up all your though process)

PS That said, I want to clarify that I am not a dev (only contributed a little), so I am not speaking for the devs or on behalf of Krita. It is simply my own take based on my experience as a programmer and general take I’ve seen of Krita.

I can’t talk for others but in my case, I was hired those, what, three? Four? years ago, for bug fixing (hence my official™ job title Chief Bug Wrangler :stuck_out_tongue: ), and for many months I was focused on just fixing bugs. But later I was tasked with Resource Managment, and it took most of later years. Last year I got very badly burned out in general, working on Resource Management, which of course at the end mostly consisted of fixing “the same” bugs over and over, which was terrible for my motivation, so now I’m trying to do some more enjoyable things to kinda build up the energy I lost at the end of working on RM. Hence I’m working more on some new things. I did work on fixing Coverity issues, which is kinda like bugs, but not found by users but by a static code analysis (so, it’s not very visible to users, most of the time, but it’s good for maintenance and makes creating new bugs less likely).

That burnout was kinda the reason for me not interacting as much on KA as I did once upon a time, too.

But your post, and some others, motivated me to actually make a good public document for the assistants work, so people can see how much cool stuff will be there (besides some niche technical things that I unfortunately have to do alongside the fun stuff).

Do you maybe have some suggestions on how to be more communicative on what’s being worked on? “Krita Weekly” kinda failed, I think, because (1) it was difficult to keep it up, (2) sometimes weeks were kinda empty, maybe it was too often? Or, maybe someone should write about their own work? I can usually write about those things just fine, but I wouldn’t want to be responsible for writing about things other people did, that sounds a bit exhausting to make sure you catch up with everyone.

I keep hoping that the transformation tool docker stops looking like a sandwich :stuck_out_tongue:


I understand the frustration of many because it really seems that the suggestions are not taken into account but I think that maybe it is more than anything lack of time and other things, the developers can not do everything.

What we could do is make a list of all the suggestions that have been made here on the forum :thinking:


Wasn’t weekly mostly focused on merge commits, not the actual details that were happening behind the scenes. I think summarizing the weekly meetings would have people more informed. Though maybe making it monthly makes more time to show stuff. That said, while I think keeping people more informed is a great thing, I think the concern people are having is the process to them seems mostly 1 way where devs inform but no feedback loop? Maybe like there is a Q&A with artists, one where people ask the devs questions? Albeit we probably don’t want to waste the devs time too much either :/, but maybe it would help with motivation showing community is behind?

If the goal is simply to move some buttons or adjust margins, that can be done without any programming by just taking the qml .ui file and loading it up in Qt Designer. As long as one isn’t adding any elements or removing them.

1 Like

I wonder if it helped if devs would give some clear feedback that would state, for example, this:

  • priority of the feature
    • high - we want this asap - usually means most artists would appreciate it and it happens in some often used tool/feature/etc. (must be in Krita’s goal)
    • medium - will need to be done at some point (needs to be in Krita’s goal)
    • volunteer - meaning if a volunteer comes up with good implementation, it will be merged, most probably
    • low - for things outside of Krita’s goal, possibly even if a volunteer implements it, it might not be merged (I doubt there would be many examples, but it’s good to have)
  • time and difficulty (low/short, medium, high/long; two separate assessments since there are things that are difficult but short, or easy but time-consuming)
  • readiness
    • ready - developer can just jump straight in and develop it (for example a new, very clear option in some tool, or it has good mockups and looks very sensible - all problems must be only technical)
    • not ready yet
      • either it’s not clear how to implement it (needs design, mockups, etc.)
      • or the feature/change is a bit controversial, or needs more discussion with artists

Would that help in communication?

I personally think it might, because for example, sometimes features are very good, sensible, probably even mentioned multiple times already, it’s just that no one worked on it yet. Or, other times, it’s clear people want the feature, but it’s not exactly clear to me how it should be implemented (eraser icon anyone? :wink: ). So, a dev account with this kind of summary would, potentially, give the idea what’s next: should there be more discussion, or maybe you need to just wait until it happens, or the idea probably won’t be entertained for some reason. And it might gives an idea how long it will take until it’s implemented: short, easy tasks might be implemented asap if some developer notices it when they have some time, while long, difficult tasks might take longer.

On the other hand, I’m a bit worried that clearly stating “nah, this is low priority, sorry” even with a reason might not be met positively. On the other-other hand, if right now some people feel like devs are “shutting down” ideas by not confirming them or promising to work on them soon, then that’s a bad situation as well… Clarity might still be preferable. What do you think?

Using the threads you mentioned as examples: (click to unroll)
  • What makes Krita's canvas operations feel so "wrong"? - that is definitely difficult (all input-related tasks are, in my personal opinion :wink: ), medium-length, ready, with medium priority.
  • Krita's higher bit depth color handling is unusable, and it affects you even if you don't use it. - this is more tricky, it has three parts:
    • one is already done (gradients work the way you wanted, at least they seem to in my tests)
    • second one (filter layers) is difficult, medium-sized, high priority, but kinda unready because it would change the internal design of Krita, so there should be a discussion with Dmitry present, and possibly it needs another solution than what you suggested (so the discussion should be with artists and not just among developers, so it’s not only a technical issue), so I wouldn’t consider it a task ready to implement
    • last one (export) is medium difficulty, medium time, medium or high priority, and ready.
    • I added a comment there since I had more things to say but there is no point in writing them here instead of in its ow topic.
  • Add more axis to the 'fish eye' perspective ruler. - easy, medium or small-sized, medium priority (only medium and not high because fish-eye is a bit niche), ready. And the reason you got no reply from developers is probably because they/we missed it. Or someone looked, saw that it’s a valid request, but they can’t implement it right away, and didn’t comment because they couldn’t promise anything.
  • QOL request: Have translation transformations act the same as the move tool - #10 by tiar was a recent regression, if I understand correctly, so it has the highest priority. It was also difficult (all transform tool related things are, for me), short and ready.

Also good thing you mentioned the fisheye axis request, I am working on assistants right now and I went through feature requests on the forum to make my TODO list, and this task didn’t appear simply because it lacked “assistant” word. I will add it now (though, interestingly, I already got a request to make fish eye axis in different colors).

(Which also shows how old feature requests might still show up later when someone starts to work on a specific topic).


What we could do is make a list of all the suggestions that have been made here on the forum

FYI, I just coincidentally came across this featureupvote thing. Its free for open source project if krita developers are interested. ( I was trying to find something similar but opensource so that I can host on my own for my personal project but found this.)
A list of all suggestions where people can vote is definitely more useful.


Well there have been Kickstarter campaigns in the past. But according to Halla, the whole crowdfunding hype is just over, hardly anyone cares, since too many projects simply didn’t go anywhere.

And concerning “estimated development cost”, I think you can still make a lot of money if you can make just halfway decent predictions…in a lot of engineering fields you can make good estimates (if you want to, I guess everyone knows the result is often what potential customers want to hear, not what the real costs are), but software engineering is not one of them.

bugzilla technically already has the ability to upvote stuff. That said, one downside with things like this is that if what people ask for is something that involves a lot of developer time such as rewriting everything? It would be quite a disappointment if the thing that wins the vote takes years to implement. Not to mention I’d venture the big things are quite well known about. And like any vote on a thing easy to access can be manipulated.

It might work out though for things that don’t take up a lot of developer’s time though.

How about instead of crowdfunding, just give sponsors “votes”. And let them vote once a month on features that would take a dev small amount of time to implement. And once a year for things that would be medium to implement. So sponsors feel like they have some say while at same time not being completely in control of direction.

Though probably not to discourage people, make it like what can be implemented in a week. So if #1 is finished in 2 days, rest 3 days can go into #2 and if it is finished earlier into #3.


Wow, there was a lot of feedback since last time I was able to answer here! I will not reply every single point in each post because it would take forever, and some of the points were taken by other users, so I’m glad to know my original opinion is not only my point of view and the suggestions here are not for saying how to do things in the correct way, because I think Krita is really a wonderful thing built with pure effort and talent; my point is that at this point, if development follows a path with a parallel communication strategy, their work will not be only reflected in software features, it would also be reflected in the growth of the community, the user experience and the increase of resources to work even more in Krita in the future.

My main point is that we could create huge hype while developing minor features that gives great value for specific work flows to create social media communication, showing each new update as a whole new product for each market segment, but in the end, it’s Krita we already use with a focus in every user type in each release, and that may involve must have features, improved UI thinking in the final user, a premade workspace for each (texturing, pixel art, digital painting, sprites, etc), shortcuts they already know in their workflows, etc. Those are things that may not have a heavy impact in developers work in all the cases (of course, there are some that will be more work intensive), but mostly is what will make the difference in the guy who only use their software for an specific task and suddenly opens Krita and has to start configuring it to make it really comfortable for him. It’s not my preference, I must say I enjoy the software like it is at the moment, but I don’t think in myself like the standard Krita user (some people make that mistake, and that blinds themselves to the capabilities of improvement), and I really think that a simple thing like asking the new user during setup process which will be his main use for Krita would make a huge difference when seeing the program open for the first time and can find the elements they are looking for and start to draw/work in a natural way.

As I said, all this sort of ideas are just examples, and those can only be taken after some research in artist community with some polls, investigation and interviews through this forum and social media. This information could be organized and documented for developers as an additional tool for them to improve their results and they also could decide if they use it or they prefer to focus in a different thing or specific task. This sort of research open oportunities like different crowdfunding campaigns, patreons or direct donations, and also makes Krita visible for possible sponsors. Reaching new public means a lot of new oportunities.

Edit: Sorry if im not answering every mention, Im writing on mobile otside home for this weekend.


bugzilla technically already has the ability to upvote stuff.

By its look, bugzilla is more for programmer to track bug. It is over complicated for regular user who just want to vote on a feature.

one downside with things like this is that if what people ask for is something that involves a lot of developer time such as rewriting everything?

If this is really what most the user want, I guess developer should consider to chop it into smaller tasks and deliver it even it if take years. Of course it doesn’t mean putting everyone to work on that particular big suggestion. My question is, should developer ignore what users actually want and develop only what they want program? The answer is not a simple yes or no. A balance is needed to keep things going. We cannot force them to program what they are not interested and they also need to care about what user want if their objective is to make Krita successful.

It would be quite a disappointment if the thing that wins the vote takes years to implement.

I would rather hear developers say no to a suggestion clearly so that I know I won’t get it in the future. I can just stop waiting blindly and move on to other tools. I like it from a user perspective.


Oh shoot, sorry @tiar, I was still talking about Affinity. They went a bit too quiet for my taste. Could have been more clear, I thought keeping every software in it’s own paragraph was enough to make this clear. I would never criticise your efforts because I see how much is going on for you Krita developers on the Gitlab branch, here in the forums, social media etc.

Simply put: you are doing a GREAT job. :heart_eyes:

I have no clue what is the easiest way to communicate for you, but in general I would advise anyone interested to look here for new information what is currently being worked on. Doesn’t need to be weekly for me. Maybe a collected forum post with bulletpoints of the main areas of development, areas of struggle (where the community might help with ideas or whatever) every once in a while. Whatever is easiest to do for everyone involved.

@Nick_Mok There’s a great system the Blender foundation uses for feature asking/voting, it’s made by two members of the Blender foundation and open source.
It’s got multiple options to organize by category, development status etc. See it in action here.


The problem there is you would pretty much return to square one. People would ask for big feature A, feature B to Z get neglect.

There has already been a vote on what features people want back in the kickstarter days:

It isn’t like it is a big mystery, and the stuff people want are being worked on but the problem that has been noted is the small stuff that fall through the cracks.

People may feel like their concerns are listened to if more small stuff they want are done. I know from experience that one can spend a whole year working on the backend with little appreciation, but then you add 1 push button and they act like you did a ton of work that earns your keep.

From a user standpoint, there is no difference between big things and small things. All that matters is getting what the user wants/needs. If the top small features users want are implemented quickly, users would feel more appreciation that their voice matters. And same time, less small things would fall through the cracks. In the meantime, big things can be worked on, piece by piece or large things at once whichever is necessary.

Edit: It would also give encourage people to donate, cause if a person wants feature X every month but it is a big thing, they may just feel like their vote isn’t worth much cause it is same big thing that goes for ages. But little things encourage people to keep coming back to vote on those little things that will be done quickly


Good example. As someone who used a dedicated eraser tool for 5 years, and Krita’s eraser toggle for 3, I can say that the way Krita handles erasers is worse for general drawing. It is more versatile, I enjoy that it is a toggle that can be used on pretty much every tool. It does have that advantage and I wouldn’t give that up. My problem is that I constantly forget which mode I’m on.

A solution I would give for that wouldn’t be a whole new tool, it would be to allow me to assign one keyboard shortcut for ‘eraser on’ and one for ‘eraser off’ so that I can quit forgetting which one I’m on constantly. yes I’m aware the icon is visible when activated, but when drawing very quickly, glancing at whether it’s on or not is detrimental and costs time.

The fisheye assistant is working fine in that thread, so it wouldn’t be a bugfix that belonged on the main bug site. (To which I’ve posted multiple dozens of bugs, those seem to get a reasonable amount of attention and resolution) The thread you respnded to was a suggestion to allow the fisheye tool to draw in fisheye perspective because right now it just draws ellipses.

I 100% agree. I moved to Krita just for that reason, as my previous program had a bug that was entirely and completely incompatible with my workflow (using a 4k screen), and the only support I got was a “We don’t know when we’ll support 4k screens”. Like, ok? Are you just going to ignore the entire new lineup of 4k Cintiqs that just came out? They supported 4k screens a month or two later because I guess too many of their big ticket supporters realized their new drawing hardware wasn’t supported and complained. By then I had already gotten used to Krita. At least here I have a small semblance of being able to direct where it goes, even if it’s only ever by brute forcing it with funding and completely bypassing the forums.

Oh absolutely, like I said I support all additions to Krita from anyone for any reason. Especially if they had the inspiration to code it entirely themselves. I see all sorts of ideas in the artist feedback forum that makes me think ‘why on earth are you adding that’, but I’d absolutely never object to them being able to do it or working on it, let along suggest they do something else I’d benefit from. Just cause it isn’t useful in my workflow doesn’t mean it’s not useful in others.

This is probably the best idea I’ve ever heard on this board, I would absolutely love something like this. A page dedicated to 2 things: Fleshing out the extent and requirements for an idea, and securing the funding for said idea. Like a bulletin board of feature request bounties that are crowd funded.

Once the idea, the plan to implement it code-wise, the extent of the initial features, the amount of funding needed to implement the idea, etc are all determined, then people can donate money to the Krita foundation for that idea. I support taking those donations ahead of time, obviously. Because the idea itself and the current funding amount is public, any programmer or group of programmers in the community can suddenly decide to implement the idea and claim the bounty. You can wait for the bounty to get higher, but you risk someone else claiming it first.

This accomplishes several things:

  1. It removes the vague feeling of your money going ‘toward nothing’ when donating to the program that some people report feeling.
  2. It will likely increase total donations overall to the project
  3. It is a direct and provable way to show interest in a specific idea, where people put their money where their mouth is.
  4. It allows the inclusion of the group of programmers that may be more of a commission-type rather than the for-fun type like the ‘passionate feature makers’ or long term contract type like the ‘core devs’.

But, this has some disadvantages:

  1. Taking money up-front means there has to be some sort of treasurer that will ensure the money for these bounties are not prematurely spent or handed out. So that when someone claims the bounty, they can receive their funds. This can be bad because significant wads of money in lesser-desired features can sit unused and unclaimed for a long time, leaving the donator with less money and no feature.
  2. Similarly, if you take money after the fact, you’re trusting the public to hold their word and actually forward the money for the work done on the feature. Lol

I honestly have no idea. It feels as though the project currently is so… ‘haphazardly’ structured? That makes it sound bad. I mean it seems messy from the outside, like it’s an amorphous blob making its way through the development process. I don’t know how most open source projects manage this sort of thing, but just some more transparency in general and some more hands-on from actual artists in the direction of the project would go a long way. Like some sort of board of artists from all walks of life and styles and workflows and hardware that can be trusted to give decent opinions on upcoming things.

The project feels like ‘an art program made by programmers who try their best to know what artists want’. I know that sounds dumb or doesn’t make sense, but I think that’s noticeably different than ‘an art program made for artists, by programmers’. An example would be GIMP, which I would classify as ‘a photoediting program made by programmers, who try their best to know what photo editors want’. Comparing Krita to GIMP is probably the closest analogy I can come up with. It’s an impressive program, it has impressive features, it has great devs, but somewhere in its development cycle it forgot to ask what its users wanted.

An organized, non-programmer-focused, artist-accessible voting and sorting functionality for features would be amazing. There are features I’ve seen go under the radar that I know would be amazing, that got shot down because the original suggester was a big dumdum with how they explained it or asked for it.

All the more reason for a more organized idea board :stuck_out_tongue:

Nearly everything involved in the entire process of developing Krita is hostile to artists. Other than this forum. Bugzilla, IRC, Element/Matrix chats, Phabricator.

This is a hard one. Sometimes I feel as though the devs say no to things that really, really, should be looked further into. And all it does it makes me even less likely to want to support the project.

Yeah @tiar you’ve been doing a great job from all the interactions I’ve had with you here and there over the years. No complaints here.

Edit: right after posting this I stumbled on a thread that I think sums up my frustration with Krita. The discussion wasn’t about Krita but it still hold true:


From a user standpoint, there is no difference between big things and small things. All that matters is getting what the user wants/needs. If the top small features users want are implemented quickly, users would feel more appreciation that their voice matters. And same time, less small things would fall through the cracks. In the meantime, big things can be worked on, piece by piece or large things at once whichever is necessary.

Agree. That’s why I mention the developers would not put all resources on heavy tasks. For example, put only 1/3 of the resource for big request and still fulfill small ones with the rest of the manpower.
For another example, if there are 3 developers, instead of allocating 3 of them to do one task for 1 month, they can only put 1 staff to work on that task for 3 month. Well, if funding is raised enough for that particular task, the team can of course pay for additional programmers to accelerate that task but not affect other part of the development.


Well, Krita 5.1 has added the ability to change the color of the cursor when in erase mode and an eraser icon on the mouse. If that still doesn’t fit your needs, your request is pretty much 5 minutes work. Can be done even with a simple python script too. But that may still not please others who do want a dedicated eraser tool.

Bugzilla also takes feature requests by setting severity to wishlist. And yes, I am aware bugzilla is annoying to use, not just for artists but for programmers too.

The bug bounty board can have other disadvantages as well when talking about adding programmers who aren’t simply interested in the product but simply the money. Especially if the items aren’t first confirmed with the Krita staff first.

For example, imagine you put up a bounty and someone takes it, codes it, but it isn’t something Krita wants to merge? Be it due to the method they went about it, or the feature itself is a problem. If something like this is done, it has to be first ran by a dev before anything is started. Which means someone has to take responsibility for the bounty.

Another issue is that it might lead to less donations as people prefer to fund bounties for features rather than the team. It’s one thing to do individual bounties, but another thing to promote it officially.

If we look at previous kickstarters they made 20k, 30k and 40k euros. That isn’t much from a developer standpoint. So I can see why interest in it was lost. That isn’t enough for paying for additional programmers.

It also isn’t as simple as 1/3rd goes into big requests and rest small ones. You still gotta fix bugs, refactor code, R&D, and not all attempts at coding lead to success(sometimes the approach was a fail and you gotta rethink your way of doing things, especially when you are targeting multiple operating systems and some things can just work weird on 1 platform or the other)

Not to mention, if this is done, that also means devs would have to set aside time to manage all this. Which again eats into development time.

Ideally, you probably don’t want to rework the entire development dynamic. Complete changes lead to things going down the drain. I think how resources should be divided should be up to the devs. What the community should focus on is how to make the process of communications best between the community and the devs without taking up too much of their time. And help with how to encourage funding for the devs with more effort from the community rather than the devs.

In that regard, I think the community organizing all the feature requests and cleaning up old bugs that may not be relevant anymore and etc would probably make things easier for devs. And as mentioned maybe a process where devs keep people more in the loop of the plans. It doesn’t require a programmer to summarize the weekly meetings for example.

With things organized, things can probably move to the next step of back and forth communications such as maybe voting. For big/medium features, since those don’t change much, once a year. For the little ones that devs can do quickly can be done monthly to encourage donations.

But again, how resources should be divided amongst the devs should be up to the devs to decide, not us.(Though my guess was that wasn’t your intention to make, but just pointing it out so it isn’t misunderstood)

Side note, for those interested in what features devs are planning currently:

If you want, I can make a suggestion thread detailing what I’d like to see in the perspective assistants. I’ve been known in my group for doing some rather crazy perspectives, and I regularly use 3, 4, 5, or even more point perspectives in my backgrounds.
I’d love to show how I think krita could implement those and just how helpful they’d be for people wanting more dynamic camera angles in their drawings.

1 Like

I kept using Krita because it felt that this is actually not the case. I used everything from Photoshop to SAI and Krita was the only one that made me feel like this software was made with actuall artists in mind. Some things are clunky, I agree but I suffered more when working in other software. I also don’t think that the project moves unreasonable slow for it’s size, the number of people working on it and the funds at hand.

1 Like

I have seen similar things, such as Mypaint’s “infinite canvas”, which developers say is almost difficult to implement. And an idea I mentioned was told that it had been rejected before.

But for more things, there is just no time to realize it. The official can’t give a definite commitment, but maybe some contributors will do it well soon. This is all uncertain.

Please be on topic. The original thread was about marketing Krita and helping Krita with non dev knowledge. And we are slowly going on to project management and developer-user communication side of things. Which is also important but not about marketing Krita.

I also see so many assumptions being made. For more transparency you can join the mailing list, join the forum here and also talk directly with the developers on IRC. There is a weekly meeting on every Monday. The meeting notes give a general sense of which developer is doing what. There is no closed door meeting or talk here in Krita everything is open but nobody will spoon feed the information to you.

Often times non developers have many suggestions and advice but they need work to be actually done by others. What Free Software project needs really are the people who do things not just talk. So nobody is stopping anyone from stepping up and forming a team or joining the discussion and make your voice heard by core team. Do take into consideration that if you are new in to the team you might need to spend a little time until your voice has some weight behind it. It doesn’t mean it will be ignored but it is good to stay around fo a while rather than just jumping in and directing things.

1 Like