| Interesting bit to me is the communication problems, not so much the technical ones, we live with tradeoffs. The thing is communicating takes time and busy people are entitled to prioritise "doing" over "talking". As a community, Clojure is defined by the promises made and the processes established. I think "Brand Clojure" is defined by some truly wonderful attributes but it could be improved. Perhaps this could this be fixed with process? For example * Document architectural decisions [1] [2] * Close tickets WONTFIX with a link to the relevant architectural decisions Make that a process/promise so that it becomes a consistently applied approach and it would give the community confidence they are being treated well, heard and respected. "Brand Clojure" becomes more lovable. But these processes also take time and we don't want to burden Clojure core devs. (More realistically, I doubt they'd allow us to impose on their precious time.) So, can this happen without adding overhead for the core developers? I don't know. It's an interesting question though. Can we learn from others online communities on this topic? Are those who do this well based on dev leads who are naturally inclined to communicate? Are any using community funded positions to deliver on communication" outcomes? Sounds like a community advocate/support role: * Triaging tickets ensures inbound communication is effective and helpful. That helps by saving core dev effort. That helps avoid confusion on both sides. * Generate architectural decision docs which can be linked from tickets * Ensure WONTFIX doesn't feel like a dead end. Link to ADs, blog topical workarounds. * Keep architectural decision docs fresh as consequences become more apparent over time. Few ideas in there. Just a thought exercise. -- [1] See Documenting Architecture Decisions http://thinkrelevance.com/blog/2011/11/15/documenting-archit... [2] Is the 'garbage in/garbage out' architectural decision documented? |