Here and there I get sentences from Mod members saying that a feature will be rethinked, will be in next OS/GUI update, will not be before 2.0, will never be implemented, will be discussed with the team.
When I open http://wiki.moddevices.com/wiki/Releases , there are only the past and current releases.
Where is the next releases milestones list with features to be implemented as I am expecting as a user from an Open Source project ?
…Not speaking of current issues/bug list …
we dont have a public list, but also not trying to hide current plans.
very often we just say what they are when asked.
we basically have 1.10.2 for short term, bugfix release
v1.11 will bring:
it will be dwarf only, at least initially. from those features above all are already working except the last one which is still WIP
for v1.12 we don’t have a strict plan, we will definitely go for “pedalboard blocks” which is a way to setup pedalboard all from the device screen.
other things in v1.12 will come as extra. we will try to push for a way to customize list-parameter addressings (pick which items from a list to map to hardware) which will also finally allow to map filenames too.
testing and experimentation will continue for usb audio, both gadget/peripheral and host mode.
As Falk said, we aren’t trying to hide it. We have been planning a way to keep users up to date with an easily accesible page with details about progress but this also takes time to set up and right now we are spending that time developing and shipping devices instead. It will come though
Thanks for answers, may I suggest that you include this in a Milestones paragraph inside the MOD Releases page.
It could take 30 minutes inserting the text from @falkTX and could have a higher priority than other tasks to give people like me a better view on futur of Dwarf.
I won’t do that.
The list of stuff to do and work on varies week by week. We have a general overview of what we need and want to do, but depending on user feedback and other factors we change the plans.
Placing such features on the wiki could make the impression that we are for sure bringing a certain feature for next release, and that is not always true.
We had plans to do the MOD Labs part of the store in v1.10 for example, but plans had to be changed and realistically I am not seeing it happen this year anymore.
As another example, the MIDI loopback feature was never in our direct plans. When investigating something else, we found a good way to doing this feature without it consuming too much of our time, so we just went ahead with it.
I have in the wiki the release notes for v1.10.2 which for sure is happening.
The v1.11 features are mostly done, but we never know what challenges we suddenly have to face and might have to cut features (or replace them with something else).
This is all to say, we know where we want to go and things to do, but there are too many external variables so it almost never ends up exactly where we planned.
So, in my opinion, it is best to not lead into false promises.
Everybody would understand that due to some urgency you had to postpone some of the lines.
That’s what is done in many projects.
Milestones are never carved into stone, they are forecast and their role is just informative.
They help.
i am really happy how communication/developemt goes forward so far 
Just adding my 2 cents: maybe sharing a list of to do things with the community would be convenient for all in a way that you (MOD Devices) work on stuff that is really useful for us (the community). It would be a waste of energy to work on features that are unnecessary for majority of users.
It could be built like a doodle: how many users are interested in feature A? how many in feature B? And so on. A community driven approach.
Moreover, when necessary, it could be setup a crowdfunding campaign (or patreon subscription?) to develop new features while it could be too expensive to develop for MOD Devices but still very needed for the community.
That measurement is exactly what we do. When we go over the requests list we can listen to how many times X or Y was requested.
For example: on the next firmware release there’s the internal MIDI loopback that came out of a suggestion. Another example is the current behaviour of the Menu button on the Dwarf (yes, that already changed based on community feedback).
The problem is that it would be impossible to do it based on votes. Some features are fairly easy to implement and make a lot of sense. On these features sometimes the dev team even builds them in their free time (out of MOD time). Some others, make a lot of sense but are fairly complex to develop.
So the prioritization balance needs to be well set.
Besides this, we are talking about a really versatile platform. The usage of it is quite broad. So what is super necessary for the synth guys, may not be that much for the guitar guys and vice-versa.
Last but not least, unfortunately, we are not a big team and resources are scarce to cover all of this.