First of all, congratulations on CDR getting some traction!
Secondly, what's the charter of the cdr-devel list? Is it only for "talking about the CDR process", or are existing CDRs a proper topic too?
If not, I propose a separate list cdr-talk, for which existing CDRs are on topic, and where the subject line should carry a [CDR N] header to indicate which CDR is addressed. (Leaving the cdr-devel for meta-discussions on the process and whatnot.)
Also, can we get the lists (including the archives) on Gmane, please? The subscription form is here:
http://gmane.org/subscribe.php
Finally, have you considered providing a liberal boilerplate licence (eg. CC attribution only, or 1-clause MIT) that CDR authors could use should they want to? I am cogitant of the fact that such a licence may not be appropriate for all CDRs, but for those for which it is, it would be nice to have a single default choise to cut down on possible future ambiguiety.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
Hi Nikodemus,
Thanks a lot for the congratulations ;) and also for the suggestions.
Before I comment on specific details of your suggestions, here is first a general disclaimer: The idea behind CDR is to be as light- weight as possible. We have tried to ensure that managing the CDR process is very straightforward and doesn't involve too much overhead. It's our impression that such processes can easily create too much overhead and requires work that doesn't really help improve the contents of the CDRs themselves. That's why some ideas that we have discussed ourselves didn't get into the CDR process because of potential hidden harmful costs.
So for example, we specifically didn't add any way to "approve" documents, or prescribe a format, etc., because this could put us in the position of having to judge something that we actually cannot judge, which would block the whole process.
So much for the background of the CDR process.
So now to your actual suggestions. (The following are my personal opinions and don't necessarily reflect those of the other CDR editors.)
On 10 Nov 2006, at 13:44, Nikodemus Siivola wrote:
First of all, congratulations on CDR getting some traction!
Secondly, what's the charter of the cdr-devel list? Is it only for "talking about the CDR process", or are existing CDRs a proper topic too?
If not, I propose a separate list cdr-talk, for which existing CDRs are on topic, and where the subject line should carry a [CDR N] header to indicate which CDR is addressed. (Leaving the cdr-devel for meta-discussions on the process and whatnot.)
So far, the mailing list is only for discussing the CDR process itself, not for discussing specific CDRs. There are different ways to produce and discuss documents, not only through mailing lists. We don't want to require any specific way how people come up with CDRs, we don't want to require their public discussion in mailing lists, and we don't to give the impression that this is the case. We also don't want to give the impression that CDRs are "approved" by the participants in mailing lists.
There are several options to create mailing lists, install Wikis, or whatever, outside of the CDR process, and we would like to encourage authors to use whatever they think is most appropriate. If authors/ submitters haven't done so, you are still able to contact them directly to send them your feedback on specific CDRs.
Maybe there is a middle ground here that I simply don't see at the moment. But I think that our encouragement in the CDR manual to have documents publicly discussed before they are submitted is sufficient.
Also, can we get the lists (including the archives) on Gmane, please? The subscription form is here:
Do you think that cdr-level is appropriate for gmane when it is only about the CDR process? (That's not a rhetorical question. ;)
Finally, have you considered providing a liberal boilerplate licence (eg. CC attribution only, or 1-clause MIT) that CDR authors could use should they want to? I am cogitant of the fact that such a licence may not be appropriate for all CDRs, but for those for which it is, it would be nice to have a single default choise to cut down on possible future ambiguiety.
...but there are enough resources on the net where you can find such licenses.
Again, the CDR process intentionally doesn't involve any quality control, and we also don't want to favor open source approaches over, say, commercial software vendors. Any specific recommendation could give the wrong impression here.
Sorry that this email sounds as if we simply want to reject all your suggestions, but that's certainly not the case.
Cheers, Pascal
Pascal Costanza pc@p-cos.net writes:
Before I comment on specific details of your suggestions, here is first a general disclaimer: The idea behind CDR is to be as light- weight as possible.
--snip--
So for example, we specifically didn't add any way to "approve" documents, or prescribe a format, etc., because this could put us in the position of having to judge something that we actually cannot judge, which would block the whole process.
...which is indeed one of the reasons why I am so enthusiastic about its possibilities. ;-)
So far, the mailing list is only for discussing the CDR process itself, not for discussing specific CDRs. There are different ways to produce and discuss documents, not only through mailing lists. We don't want to require any specific way how people come up with CDRs, we don't want to require their public discussion in mailing lists, and we don't to give the impression that this is the case. We also don't want to give the impression that CDRs are "approved" by the participants in mailing lists.
There are several options to create mailing lists, install Wikis, or whatever, outside of the CDR process, and we would like to encourage authors to use whatever they think is most appropriate. If authors/ submitters haven't done so, you are still able to contact them directly to send them your feedback on specific CDRs.
Maybe there is a middle ground here that I simply don't see at the moment. But I think that our encouragement in the CDR manual to have documents publicly discussed before they are submitted is sufficient.
I see your point, but I do think there is a middle ground to be found: while document authors are free to choose any venue of their liking for discussions about their document, it would be handy if a "sensible default" existed.
Quoting from the CDR website:
"You are encouraged, but not required to:
* Discuss your document publicly before you submit it as a CDR document, for example in mailing lists, newsgroups, or other public forums.
* Provide an archive of the discussions that influenced the contents of the CDR document that we can publish as accompanying material alongside the document itself.
..."
Frankly, there is no single good forum for most such discussions at the moment. An increasing number of people find comp.lang.lisp is horrible drain on with decreasing returns, yet it remains the only broad forum in existence -- everything else is specific to an implementation, library, user group, or an application area.
Even if a CDR is produced by a separate working group using whatever discussion tools they prefer (eg. coffee breaks) it remains that for third parties to comment on it, they need to either talk directly to authors, or pick a bad forum.
Or so unless the author(s) have provided a separate forum for discussing the document -- which has yet to happen for any of the 3 CDRs so far. ,)
I naively assume that if a list like cdr-discuss existed, it would get fairly wide readership, and provide a place for such commentary. Its existence would be no onus to the authors that I can see, and by restricting the topic to existing CDRs it should be able to maintain a good signal/noise ratio (which still leaves budding CDR authors without a good place to talk about their plans, but admitting "I'm thinking of a CDR" seems to me like a really bad idea and potentially disastorous to the quality of correspondence.)
Take CDR-2 for example: Where would you go to talk about writing more invasive CDR based on it, that would describe an extension to CL that does the same thing, but with the standard GETHASH &co? Where would you go to see if there have _already_ been discussions like that? (Note that these discussions can easily take place long after a CDR has been finalized and the original authors have moved on.)
Maybe I'm missing something, but I really don't see how such a list would create barriers for authors -- quite the opposite. Of course it should be made clear that the list has no official standing, but I would hope that some vestigial reading comprehension still lingers on both shores of the Atlantic...
Do you think that cdr-level is appropriate for gmane when it is only about the CDR process? (That's not a rhetorical question. ;)
Appropriate yes (Gmane is a really nice way to read mailing lists you don't want to clutter your inbox), strictly necessary no. Announce list at least would be good to have there, though.
and we also don't want to favor open source approaches over, say, commercial software vendors. Any specific recommendation could give the wrong impression here.
I'll take your word for it, but I don't really see how saying "we believe licence XYZ to be a good match for the needs of most CDR documents, but you are free to use any licence you want" can be interpreted as favoring open source over commercial vendors -- but clearly I am not the most unbiased person to think about this.
In any case, CDR is a damn fine idea, and I believe it will benefit the mythical beast known as the lisp community immensely in the long run.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
-
Nikodemus Siivola -
Pascal Costanza