Quoting Luis Villa (l...@lu.is): > The next step in the long run should be to figure out how to create > authoritative summaries of license proposal discussions, so that newcomers > and non-experts can reasonably and transparently understand OSI and OSD.
Along those lines, the occasional summaries lately posted have impressed me with how good they are, for whatever that's worth, so my thanks to those responsible. Further improvements would of course be great. And yes, good idea, studying and learning from RFC models. > This need not involve moving away from mailing lists altogether[3] but it > definitely means that they should be replaced as the long-term repository > of institutional knowledge. You may recall that I strongly agree, but I'll elaborate further. (I'd been intending to reply to your posting specifically in order to do so, but waited until I felt I could do a good job, and not risk contributing to this forum's noise load.) Attempting to use mailing lists as a repository for institutional knowledge is a communication antipattern that I've seen play out, over and over, for about 30 years. The attempt is always a grievous failure. Over at Silicon Valley Linux User Group (SVLUG), for long years I kept being wasked over and over on the internal-process Volunteers mailing list to explain technical process: There was always a request to explain again, explain some more, and it became obvious that 'explain again; give more detail' was a dysfunctional reflex, that greater conciseness was in order and _not_ further flogging the mailing list deceased-equine. These repeated incidents inspired my Moen's Law of Documentation, http://linuxmafia.com/~rick/lexicon.html#moenslaw-documentation : Moen's Law of Documentation "The more you write, the less they read." Although any piece of writing can be improved, even the best examples, especially of technical writing, no matter how excellent, will garner requests for _more detail_ -- far past the point of reason. Why? Because, most often, a questioner's immediate reaction (to not instantly understanding) is to claim that insufficient information was provided, whether such is true or not. The longer and more detailed any subsequent, further explanations are, the more difficulty target readers will have in finding what they need, and the more they'll demand an _even thicker_ forest of explanations to get lost in. Thus, greater conciseness often does _much more good_ than do longer & more detailed explanations. [...] Of course, the spinal instinct to demand re-explanations and more yet detail is just the beginning of the problem of relying on mailing lists as a repository for collective knowledge: After about incident #2 of 'Rick, please explain [thing I explained the prior week], I shifted tactics and cited the specific Web-archive URL of the earlier explanation, something a bit less hopeless than just saying 'read the archives', which of course is impractical and nobody does it. But that gets us to the larger point, which is that mailing lists are just the wrong tool. They're a successful medium for discussion. The're dreadful as wikis; that's why wiki software exists. They're dreadful as issue trackers; that's why issue tracking software exists. SVLUG persisted in trying to use a hammer to drive screws because (at first) nobody could bother getting a screwdriver. I ended the inane screw-pounding by putting the most-need process information on a Web page, and some more-sensitive process information for volunteers into a site-documentation directory internal to SVLUG's server. That finally put an end to people trying to do ineffective things with the wrong tool. By the way, Luis, has OSI ever _really_ advised newcomers to 'read the archives'? Certainly, speaking for myself, *I'd* never so recommend, for multiple reasons including that just never working. > [3] Though, as I just posted on l-d, I'm increasingly convinced that's a > good idea if we want OSI to be the locus of a thriving, healthy community. I'm increasingly convinced that moving core discussion to a continuous-scrolling, flat-model Web forum will impel most or all technical contributors to quietly drop out, because we've tried those and found them lacking, and have been hearing from people to that effect, so it's not just me. But hey, do what is believed beneficial for the organisation, of course. By the way #2: While of course it's generous of Civilized Discourse Construction Kit, Inc. to offer to host an instance of the Discourse Web forum for OSI, it's worth considering the message that would be sent by OSI thus outsourcing its Internet operations. Currently, OSI self-hosts and self-administers, as has been the practice of those of us who like to make the point that running autonomous Internet hosting is one of the things open source is best at. Speaking for myself, if I were to outsource, especially to a third-party-hosted Ember.js, Javascript, and Ruby on Rails application so complex that I couldn't administer it anyway, I'd feel I had weakened the open source message quite a bit. -- Cheers, "On the Internet, no one knows you're a dog -- Rick Moen unless you type 'woof, woof, woof'." r...@linuxmafia.com -- pyellman McQ! (4x80) _______________________________________________ License-discuss mailing list License-discuss@lists.opensource.org http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
