I think, we once again have to point out, that openHAB ist not structured in such a way.
We do not have respective dev teams, everything developed is community work.
What we do have is some “specialised” mainainter groups (core, add-ons, web-ui, etc), but it is not their job to develop what users or the community demands. They sometimes do, but this is out of personal interest.
I know, that’s all spare time activities and that’s great! I appreciate every single one of them!
I know not much about internal structures, but what I see is, that most devs don’t do all the parts and bits at once, but specialise in some kind of work. That’s what i mean with “team”. There’s some kind of communication going on (on github I guess), to coordinate work, which I don’t follow…
If that’s OK for all the contributors and maintainers - I’m A OK with throwing all into one pot. Just saying it’ll be a bit of work to pick the work packages out of one long thread! 
No, there are no work packages. Every contributor works on what he/she likes to work on. Same applies to the maintainers. They review the code they are interested in. There is nobody with powers to tell anybody to do something.
I think it’s best to throw it all in one pot. You get more eyeballs on it and hope that one of the devs thinks its something they would like to work on.
I just added it to the wishlist as it seemed to be getting a lot of views. I am not even sure if it is possible to do in FCM or given that myOpenHAB cloud is free so it may only work if you host your own openHAB Cloud like IFTTT.
Also happy to be told it’s not possible or it’s not of interest because the devs choices on what to develop seems to be working good for us all as we are still here 
That’s why I said way up in post 27 I recommended having some sort of strategy to organize the wishes.
But beyond that, unless individuals are filing issues on github to go with these wishes, or developers/maintainers are reading this thread for ideas and general awareness that’s as far as it goes. No one is going to package this all up and deliver them to the proper repo and shepherd them through development. No one is going to prioritize this or direct someone to work on a specific idea. Those ideas that a dev/maintainer sees they think they are willing to work on will get picked up, the rest no so much.
I wish the java 17 requirement will not be enforced on the addons so they can be used in the 3.4 stable release at least until there is a stable 4.0 (unless the J17 functionality is required for that addon). Using zwave as an example, there are many beginning and intermediate users (usually on Rpi’s) that go from stable release to stable release. However, the Zwave DB of devices (and thus the binding) is updated weekly with new and modified devices. From a support perspective I would not like to advise that the only way to get your brand new shiny zwave device working is to a) wait 6 months for a stable release or b) upgrade your Pi O/S to bullseye, upgrade to J17 and then upgrade to an OH snapshot (unstable). Although I haven’t tried (just back from holiday), I believe the latest Zwave binding DB update is working in a 4.0 snapshot and will still work in 3.4 stable.
Rethink the massive .kar file approach, I’m thinking along the lines of the Apple/Google/Microsoft store During an OH upgrade my Rpi3 (on wifi) struggles with a 370 meg file of almost 350 bindings of which I use 4. Multiplying this extra burden by every OH upgrade and hundreds of users makes me question the German stereotype of efficiency and engineering I’d add that with about the half of the items in this wishlist the kar file will be 500 megs by the end of the year.
The ultimate would be that only the bindings that changed would be upgraded (like how the apt update works), but I see the kar files are distributed to tmp and that is cleared every upgrade. Anyhow redownloading 4 jars is far better than 350. I also think this would help reduce the “Kar loading 15 sec message” and the activity related messages at startup when installing a new OH version.
By default, the add-ons are installed on demand. Only if you install openhab-addons via apt or download the kar file manually and drop it into openhab’s add-ons folder are all the add-ons downloaded and installed. In all other cases, the add-ons are downloaded on demand.
The zipped up manual package that includes OH core only is just under 100 MB.
I’ve not seen any suggestions this far that would increase the size of openhab-core in any appreciable way. Between OH 3.3 and 3.4 there were over 100k new/modified lines of code. The size difference is negligable.
Maybe I have been doing this wrong. I was using apt update/upgrade and the full kar file was downloaded into the addons folder. I guess I’ll have to read how not to do that. Thanks My wish is granted 
Since the first version of OH I have been using only text configuration for rules, things, items, etc.
The backup is straight forward and hassle free.
My Xmas wish is that TEXTUAL CONFIGURATION will be always mainteined and enhanced including every single part of the system (i.e. addons like it was in OH2).
Another Xmas wish is to enhance the sitemap capabilities to enable more features (i.e. dialog boxes, push (momentary) buttons, etc.).
Since we all can add wishes, no matter how realistic they are, here is my wish: openHAB completely drops textual configuration and makes DSL rules an add-on. That way we can rid of Xtext/Xtend in core. There is absolutely no need to make it more complicated than necessary and the need to retro-fit everything to DSL and textual configuration makes introducing new features a PITA.
Well as you probably guess I’ll have a wish, too:
I’d wish textual configuration will get a proper parser which can model metadata properly.
And I’d wish the fight about the preferred configuration method will finally cease and both methods can coexist.
Also I’d wish for
What‘s the issue with HABApp not being included in the distribution?
Nothing - HABApp should not be included in the distribution.
It’s a separate project which has to be installed separately.
I’d wish for a perception shift.
I’m under the impression that sometimes HABApp is being viewed being as more or less annoying attachment to openHAB.
I’d like it to be viewed as a chance to make openHAB a better experience for people that want to create rules in python.
To clarify:
This is not an attempt to blame anyone. Especially not you @J-N-K . Even though we disagree on some issues you have been nothing but kind and helping me out tirelessly. 
This is already possible with Docker. It might be possible to port that approach to be more generally applicable. It works by looking to see if certain files exist in userdata and if not backs up what’s there and creates a brand new userdata folder in the script that runs to kick off openHAB inside the container.
I am missing a csv export at least for the most important entities like things and items including all their “attributes” like name of channel, tags, state descriptions, semantics, groups, etc (for items). An export for rules would also be nice.
This will make housekeeping much easier.
For example if you want to do mass updates on your item’s label or want to double check if you have added consistently the correct tags to your items, it was easier to do it outside of openHAB, e.g. in Excel and upload the xls file for updating your items.
Given the hierarchical structure of the data, I can’t imagine how it could be exported as csv.
But you do already have a way to export everything as JSON which is a much better format anyway given:
fairly easy: if you have 1:n related information to an item (like groupsNames, tags) simply insert a delimiter seperated string into one cell or add as many columns as required.
I have seen that my previous post was somehow cut off. I have added the rest which makes my wish clearer.
I would very much like a simple „Export everything and download as .zip“.
As an office worker, I agree with this motion export to zip or xls lol