Much pixel has been spilt over our recent newsgroup reorganization and new hosting infrastructure. The high-order bit is here: we have better project communication and discussion now than we’ve had at any time in my recollection, and we all owe Gerv a genuine debt for pushing it through so many false starts and obstacles. (We also owe the others who have laboured to get the mail pieces talking to the news pieces, and the news pieces talking to the web pieces, and the web pieces able to talk at all, but if I had to pick one person to laud…)
A lower-order, but also important, bit is outlined by fantasai here, and I have been meaning for some time to post at length about my feelings on the matter.
This is not that post; I have to go to sleep a few hours ago, such that I can drive to Ottawa tomorrow. But I do want to at least outline my core beliefs on this topic, to partially assuage my guilt as much as to inform anyone usefully.
I believe these things:
- We should prefer fewer groups to more groups, where all else is equal. All else is never equal, so that’s sort of a cheap belief, but traffic/spam/etc. problems should first be attacked with techniques and tools that don’t require us to split a community, and especially those that don’t leave people confused about where a given discussion should or will happen.
- Where scale permits, and where there is a reasonable path from consumer to producer for the enthusiastic, we should keep discussion of the development of a piece of our technology alongside discussion of the use of that technology. AJAX toolkits and their mailing lists provide a good example of the value of this, though it may well be that for many of our technologies — especially those that implement widely used, standard APIs — the scale of the consumer community makes that impractical. Even where that happens, we should see the separation as a necessary compromise and not a goal with inherent value; in these cases we should strive to subdivide the community as little as possible, and with an eye towards helping people mix with and learn from their “betters”.
- Gecko “internals” discussion probably needs a group focused on those implementation details and design decisions, but it almost certainly does not need a set of such groups, each devoted to a different portion of layout (style, dom, parser, etc.).
- I was one of the people involved in the re-re-organization, and I erred significantly in not raising my objections and making my demands in a more public forum. I have no defense here but the goodness of my intentions, and please rest assured that the bitter irony of a private discussion undertaken to improve the quality of our public communication is not lost on me.
With the exception of the last point, I could certainly be in error, but these are not beliefs that I have come casually to hold, and I genuinely believe that we will be better off if we are able to adhere to them.
(Dammit, this turned into that post. Ah well, I don’t need to be rested to drive!)