Excellent! I've actually wanted to e-mail you to ask you to share what you learned through this process. Your wiki was really battle-tested... it probably went through more changes by more people in the shortest time (which must have led to lots of concurrent editing issues) than any other wiki ever. And it wasn't only working on shared reference material, for example, but there was real design, collaboration, and discussion going on... votes were held and everything.
I was really impressed throughout the whole process that you seemed to keep the whole thing well-refactored and under control. If you have any other insights you can share beyond what can be gleaned from your slides alone, please share.Posted by Keith at
FYI, the links for "defended" and for "wiki being used as a bad BBS" on the O'Reilly page point to the same place.Posted by Keith at
I'd love to hear the actual presentation. Was it recorded, perhaps?Posted by Dave Walker at
Does the IETF thing in August mean we won't have a version 1.0 until then? I was hoping for a stable version by Easter-ish (topics recurring also implies we've run out of things to talk about).Posted by Graham at
What a wonderfully stimulating day today at eTech04! After the keynotes came the first in a series of sessions that......
Trackback from All the Pages are My Days
Sam Ruby has posted his slides for his ETCon2004 presentation . This is one of the presos I was most...
Trackback from ...pickhits...
Nice work. I do hope you'll revisit this when release version 1.0 is in the bag.Posted by Danny at
Keith, while the bad link on the O'Reilly site was entirely my fault, it is not something that I can readily correct. Here is the link that I intended link I intended to provide.
Dave, no guarantees, but watch this space. I'm not clear on what O'Reilly intends to do with such recordings, or even if my session was recorded.
Graham, 0.3 is stable and widely implemented. I, for one, intend to slow down the rate of new snapshots. In any case, it would be foolhardy to make any presumptions at this point about the rate at which an IETF working group could come to completion.
Danny, thanks, and thank you for Finally Atom.Posted by Sam Ruby at
Um no Sam. The big reason it's been widely implemented is because lots of people like the idea of it. That says nothing about the quality of the actual spec. It still has several major flaws and inconsistencies that need resolving. So it's only "stable" if we're going to just not fix them, and also ignore everything else discussed in the last two months.
The other big problem is that almost everyone thinks the current version is just an early draft - hardly anyone but you and Mark think of it as stable. A few big sites have picked up on it, yes, but everyone else is waiting. There needs to be much clearer information about the status of the next snapshot.Posted by Graham at
Graham, 0.3 is stable in the sense that any changes will go into a 0.4.
There have been a number of good ideas discussed in the last two months (example: I think that changing author/url to author/link is a good idea). However, I don't think that a rapid set of new versions would be a good idea.
Question: for the areas where you think that there are major flaws and inconsistencies, would you be willing to produce camera ready copy to cut-and-paste into the spec?Posted by Sam Ruby at
Summarising Sam Ruby's slides about the !Echo wiki experience from ETCon. I think he may have spotted some candidate collaboration patterns......
Trackback from Synesthesia
I totally agree with you. The current spec is at best a rough draft that snapshots thinking that was in flux at a particular point in time and not something I'd consider stable or worth deploying. The fact that a number of people rushed of the swap out the tag names in their RSS feed generating code with ATOM namespaced ones is no indication of the quality of the spec. Then there's the fact that it has various deficiencies compared to RSS in practice when it comes to features (lack of comment support for one).
Anyway, another splinter syndication format is an afternoon's work to hack into RSS Bandit so it doesn't really matter one way or the other. Hopefully the encoded/mode complexity will be sorted out by then.Message from Dare Obasanjo at
What exactly is meant by a stable draft spec? Maybe it's because I usually deal with the W3C so I expect that drafts are by definition stable since they are a snapshot in time and stability refers to the spec as a whole.
This isn't facetious, why would you call 0.3 stable as if it is meant to be deployed in the real world as opposed to being out there for informative purposes so people can give feedback perhaps based on implementation?Message from Dare Obasanjo at
Hmmm. Semantics are a bitch, aren't they? ;-)
Let's go back to Graham's original comment. Apparently, Graham is waiting for something, presumably as a prerequisite before he does something.
Without trying to force Graham to disclose the later "something" (unless he wants to, of course), Graham, is there a punchlist of workitems that represent the first "something"?
As an aside, I find it intriguing that a number of people would apparently have behaved differently if the first three drafts were numbered 1.0, 2.0, and 3.0 instead of 0.1, 0.2, and 0.3.Posted by Sam Ruby at
re: "hardly anyone but you and Mark think of it as stable"
I have never said this. As discussed on atom-syntax, the Atom feed spec needs several critical clarifications, and I am confident that it will get them in 0.4.Posted by Mark at
This isn't about me. Shrook 2.0 supports Atom 0.3 just fine. But I keep seeing blog and mailing list postings saying "I wanted to make my new feed Atom, but that's still immature, so I went with RSS", and they're right on both counts. I'd rather people were producing Atom, but 0.3 by any other name would still be incomplete. The real problem is uncertainty. Do these "wide implementations" understand 0.2 feeds? If not, what guarantee is there that creating a 0.3 feed now won't be a wasted effort very soon? That's what I mean by stability.
You're nominally in charge of this process. Can you give these people some answers?Posted by Graham at
I don't know about Graham but I'm waiting for a draft of ATOm that fixes issues like the ambiguities with dates, the complexity of encoded/mode and has support for comments. If your claim is that each interim draft of ATOM is expected to be a full release that can be deployed as oppsed to a stepping stone until the final version of ATOM I think this is a horrendous mistake and will be waiting to see when Mark Pilgrim writes his "There are really 9 versions of ATOM" blog entry since based on that reasoning we already have 2 versions of ATOM with more on the way based on your comments.
Mark: I was referring to you having said there won't be major changes before the final release, that it's basically finished (I can't find the quote). That's just about consistent with requiring it "critical clarifications" though, so I'll take it back.Posted by Graham at
Independent of any work that may go on prior to the IETF Working Group being formed, it is quite conceivable that changes will be made during the IETF process itself.
My motivation at this point is to get as much "rough consensus and running code" as I can prior to entry into the standards process.
A clear identification of issues that need to be worked would be appreciated.Posted by Sam Ruby at
I would like to suggest the "Ruby's Law".
:-)Posted by Janne at
Oh. I was under the impression that standards bodies would only be invoked after we had a finished released spec. So the big question is: Will pre-IETF implementations require only minimal changes to be IETF-compliant? Because not having anything that's considered more than a rough draft before gone-August doesn't seem very practical.Posted by Graham at
First draft collaboration pattern extracted from Sam Ruby's experience with the !Echo wiki...
Trackback from Synesthesia
As an FYI, regarding "a clear identification of issues", I will not have time to continue the work I started on the Atom issues tracking. Someone will need to pick up that task.Posted by Ken MacLeod at
Graham, I expect there will be significant improvements in the specs themselves, but no, I don't expect that there will be changes which will require dramatic rewrites in terms of the various implementations that exist.
Ken, noted, and thank you for all your contributions to date. You will always be welcome to participate to the level that you are interested and able. I am hopeful that the creation of an IETF working group will create the much needed structure that it will take to drive this effort to closure.Posted by Sam Ruby at
Sam Ruby's slides from ETCon, discusses the pros and cons of using a mailing list, Wiki and blogs for a project like Atom.......Excerpt from Finally Atom at