I think that is magical thinking — new content will not “naturally” emerge, someone has to do the work. Discussions like this always arrive at this point; a long list of things that “should” be happening, and a much shorter list of people willing to do it.
Which is why the people deciding how Julia’s development process works should be the actual developers. If they want more structure, or centralization, or something else, they will figure it out, otherwise, from a practical perspective, there is no way anyone will impose it on them.
The process is already transparent — if you follow Github issues and pull requests, you get an almost complete picture of where things are going, what the remaining roadblocks are, etc. For the rest, if some details is not clear, people usually respond if you ask. What you want is not transparency, but some kind of managerial oversight.
A major complaint seems to be about “planning”. But planning is pretty vacuous without someone who will enforce those plans, and that kind of authority or mechanism is antithetical to Julia’s governance model, and FOSS in general. Companies implement plans by having managers monitor and direct people, and even then, planning software development is inherently difficult.
I actually admire Julia’s development and governance model and think it is perfect for the job. I would describe it as having two related key concepts: consensus and getting it right. Some features mature for years, because instead of a quick fix, Julia’s authors try to come up with a good solution that allows growing the language further, so that they avoid technical debt.
A recent example is redefining structs, which took 8 years to fix. Several workarounds and hacks were proposed and explored in the meantime, and were dismissed as inadequate. The issue was the most grating to my workflow, but in retrospect I am glad that they took their time to arrive at the right solution.
Similarly, while deploying small binaries would be nice in some contexts, I would not want any kind of pressure on the developers, because I am convinced that they are already doing their best, and any intervention would result in inadequate solutions, developer burnout, and smart people leaving the project, which is the last thing we want.