Greetings! 
This is the transcript from the workshop on providing developer input from the Juju community.
The complete resulting PDF is published here 2022-april - Community input for Juju developers.pdf (74.0 KB) - email addresses removed.
We had participation from EU+US timezones, independent and Canonical project leads. Massive thanx also to those that could add content from the US timezones prior to the event. We talked about those items aswell @heitor @jamesbeedy etc.
The workshop started with collecting new items from the participants and then walked through all items together producing this list. There was alot of discussions, feedback and comments and we also had some social time.
I hope participants wan’t to keep commenting about it in this thread.
Here is the list in no specific order or priority.
===============================
Desire: Actions with access-control
What: I would like to be able to restrict access to certain juju actions such that I can allow or not allow certain users to be able to run, let’s say security related actions or that perhaps reveals secrets. It could be more ways to achieve this.
Why: Juju actions is very powerful tool but anyone with “write” permissions can run all actions. For operations-staff, some actions - like “juju run-action get-admin-password –wait” is way too scary to let “anyone” have access to with simple write permissions. Its very much “all or nothing” here, which makes it problematic if I have many charms where some should not have this kind of access, where some other charms would be OK.
===============================
2. Desire: Deploy juju controller via helm chart
What: I would like to provision a juju controller by means of helm chart.
Why: It is difficult to integrate juju to k8s infrastructure. Aka you need to run “juju bootstrap” from somewhere.
===============================
3. Desire: Operating system agnostic instance provisioning
What: I would like to provision linux based operating systems other than ubuntu or centos using juju.
Why: Oftentimes software systems do not support ubuntu and the disconnection from juju and the other operating systems prevents juju from being used in many scenarios. @jose-phillips expanded about series vs bases which would allow future work towards this.
===============================
4. Desire: Juju ecosystem installable via package manager
What: I would like to use apt/yum/dnf/pacman to install juju and charmcraft.
Why: We need to control our infrastructure and follow an enterprise way for software provisioning: well defined calendar for updates, production systems should never change before staging (this includes the juju client), ability to downgrade software in case the new version contains regressions, and so on. This all makes snaps unsuited for distributing software. We need proper packages (rpm, deb, etc) for the Juju ecosystem (Juju, LXD, charmcraft).
===============================
5. Desire: Versioned docs
What: I would like documentation to be versioned to each juju version
Why: Juju is complex and changing fast. We need to find information about the version we have in our controllers, but the forum posts are not tied to specific versions.
===============================
6. Desire: license-aware systems
What: I would like the Juju ecosystem to show the licenses of the charms: Charmhub showing the licenses in the Charm’s page and juju info showing the licenses in the output.
Why: In enterprise environments, we have to follow specific rules on what licenses to use. Not having this information excludes juju from providing solutions to enterprise clients. @mcjaeger suggested a dedicated workshop for discussing publishing guidelines
===============================
7. Desire: All documentation in the charm for charmhub
What: I would like to have the documentation (README.md?) go into the charm itself instead of having to mess with the discourse. Also, the README.md format would be better off be forced to have some specific chapters to improve the quality of charms in the charmhub.
Why: Its very difficult to contribute and add to documentation and get it all look good in charmhub.
===============================
8. Desire: A more demystified and monitorable controller
What: I would like controller (cluster) health to be easily monitored and generally more means and best practices to maintain the controller’s health over its lifetime, both in terms of scripts/utilities and documentation.
Why: The controller is an extremely critical component used to control almost our entire infrastructure, without it we are blind. It is stable, but after years of operation, dozens of upgrades and hundreds of units running it sometimes misbehaves (slow and resource demanding) and the cluster may even be out of sync without us knowing about it.
===============================
9. Desire: More config option classes/types
What: *I would like to have a richer set of config options with “early sanity checks”. * So lets say “items” like “apple, pear, orange” would be the only allowed options.
Why: This would “prevent” missconfigurations early which would also help developers not having to do alot of coding to cover for wierd input etc. … also passwords/secrets option could have a great use.
===============================
10. Desire: I would like a more streamlined CLI command structure.
Why: It would improve user experience.
Why: Not obvious whether it’s better to have commands that are verbose but clear vs. short but ambiguous. Verbose also helps discovery through grep. Maybe we should make continuous efforts to translate between the bottom-up, developer perspective and the top-down, user perspective.