On 25 Jul 2000, Russ Allbery wrote: > Is closed subscription really necessary on any Perl development list? The Module List folks ran their list closed and I think it was a terrible decision. Their theory was that it wasn't really closed because anyone could read the web archive. But in practice nobody did really read the web archive regularly because it was too inconvenient to do that. Last week I sent a long list of complaints to Jon Orwant about how the module list had been run. I believe many of the problems would have been corrected a long time ago if the discussion process had been more open. The module list folks would make some half-baked namespace decision about someone's module, and then they would win the subsequent argument about it because there were five of them against only one module author. Then the following week they would make the same half-baked decision about a different module and again they would win the argument because it was still five against one. If the mailing list had been open, it might eventually have become clear to the subscribers that the same problems were recurring. When the module list owners had policies, the policies were unclear, because the mailing list wasclosed. There was no way to tell whether the policies were applied consistently or not, and I suspect that they weren't. I don't know whether the policies were well thought out, because the mailing list was closed. Closed *posting* makes sense to me under many circumstances. But I don't see what it is about the development of the lexer that is so vital to national security that it must be conducted in secret. The lexer (or whatever) will come out better if more people get to see how the design is progressing and to raise their concerns. They don't necessarily have to be able to raise their concerns on the lexer development mailing list, but they do have to be able to find out what is being discussed so that they can raise their concerns with the people developing the lexer. Ask Bjoern Hansen: > Consider it added to my list of things that are not going to happen > with the lists (development lists, opposed to certain organization > lists) as long as I do the technical stuff for them. :) Right on. Power to the people, brother.