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