Dave Cridland wrote: > On Wed Aug 15 21:01:07 2007, Peter Saint-Andre wrote: >> The XSF is a standards development organization. We're supposed to be >> developing standards. If people want to publish the results of their >> experiments on their own websites as input to the XSF's standards >> development process, they are free to do so. But as far as I can see, >> nothing in the XSF's mission or bylaws dictates that such experiments >> deserve to be published by the XSF. > > Actually I disagree. Not publishing (in some way, it doesn't have to be > as a XEP) experiments and early-stage working documents, and in > particular encouraging these to be privately published, does not > encourage the kind of commonly-owned specification that can be developed > into (or used as input for) a proper standard. > > I suspect - without much justification, I'll admit - that the result of > encouraging specifications to be worked on outside the XSF would lead to > fragmentation and proprietary extensions (by which I mean the term in > the sense of not held under common ownership).
Yes, that result is to be avoided. > A good SDO, therefore, not only encourages open participation (as we and > the IETF do), but also encourages open publication of proposals (as the > IETF does with it's I-D documents, which represent a low barrier to > entry, centralized, publication mechanism). We tend toward promoting a > "do or die" approach to publishing XEPs, which leads to the bulk of a > specification being developed outside the XSF, potentially encouraging > multiple non-interoperable approaches to the same goal. Well, it's odd. I used to be very liberal about publishing JEPs (before they were XEPs). This was back when the JEP Editor (me) decided which specs would get published, and the only hurdle was that the spec was properly formatted. Look at lots of the early specs and you'll see that many of them were little experiments that people did. Then folks wanted to control the process more and we instituted the Council as a gating function. If it were still up to me I'd argue for the liberal approach. > This has demonstrably happened with the whiteboarding proposals, and > it's obviously not in our interests - whether that's as a result of the > XSF's processes is most certainly a matter for debate, but I feel the > XSF's processes might be adjusted to try to reduce this. Yes, I prefererd the old way. But then I'm pretty much of an anarchist anyway. ;-) > I believe the best mechanism for encouraging interoperable protocols > through the XSF is to support their publication, even when the proposal > has flaws that the Council require to be rectified. Hence my comments in > another message about adjusting our processes to allow for a long-term > use of the Inbox without forcing publication as a XEP. Or just publish-at-will and take greater care about reviewing specs. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
