I'm intent on just backing this page up to an archive page, and then redoing it. Take the TechnologyUnion? idea out of it, and then putting in some mechanisms.

I sketched this out recently, here's what I was thinkinging:

• Anyone who is a person, is interested in PICA, and wants to be a member, is a member. Even without telling anybody. :)
• Any member can register. If a member registers, then they are called a registered member.
• 20 registered members can ratify a PICA document.
• Ratify a PICA document: Pick the next number, stick it up on top, and host it somewhere.
• While we're less than 20 registered members, 50% of registered members should be enough.

One difficulty is: "How do you serve the PICA documents?"

• The PICA document server serves both source and presented forms.
• PICA source documents never change.
• We should choose our source forms carefully. Pick something that can be served, at least.
• However, let's please not restrict ourselves to ASCII. We should be able to include SVG images, I would think.
• There should be a way to attach information around the document. That is, just plain XHTML documents wouldn't be good, because we couldn't put a header, footer, whatever, around it. (I don't think, at least.)
• Perhaps we'll have a super-dumb wiki-like markup for the first version. Two levels of headers, italics, bold, and SVG images. Maybe a hyperlinking mechanism. Maybe.
• We probably want to keep the id's of ratifiers coupled with the source somehow.

"Why just 20 registered members? Shouldn't it be based on a percent of total membership, or something?"

The idea is to make it quick and easy to make a formal interface specification. The idea isn't to make a standard that everyone must follow. I take the plurality of MP3 and OGG and what have you as my inspiration: It is enough to concentrate sympathetic people around a document. The later steps of putting the documents in a death match against each other- that seems like something that can come later.

It may be impossible to collect 95 of 100 people around 1 format. But it is probably possible to collect 40 people around 1 format, 30 people around another, and 30 people around still another. Then, you can just write adapters to the rest, or let those 3 groups with their good interface specifications write code and duke it out.

The LanguageOfStandardsAndSpecifications? is confusing, and perhaps the word "Standards body" is inappropriate. People will bite each other's ears off over these things, it seems to me. It's a discussion I'd rather not have.

Basically, I just want to see things go forward. We need nice shiny interface specifications. :) People trust them, because there's process behind them. You have to get a bunch of people to read the document, and put their rubber stamp at the bottom of it. That way, you know it's not some thing that somebody wrote at a moments notice on some wiki page some where. When they see the nice presentation, and when the form of the presentation is familiar and comfortable, they feel like they can trust it.

(Eeegh! I just made an argument for plain text! I'd rather not. I believe that, later on down the road, we can probably write up style guidelines for the use of SVG. Make it monochrome, specify valid line widths, whatever. For now, I'd just like to keep it loose- this is a detail, and I don't want to get bogged down in details.)

I am, frankly speaking, floored by your experiences in these various standards bodies. I'm really impressed, and in many ways, aspire to work on projects of similar value.

I believe that we can do useful things (of similar value) from out here in the boonies. Likely less fanfare, likely nobody really notices, but: Every day I see things that need to be done, that nobody's really doing, and that doesn't really require a whole lot of work. (I mean, considering millions of dollars and the grand scheme of things.)

It is like you say:

I like the table, I like the mat on top, I like the napkin drawings, and the laptops out and coding. Duking it out mano-a-mano with Microsoft, IBM, the UN, whoever, doesn't really strike me as all that appealing. And I have no idea where to find a mecha-suit made out of big company, anyways.

The reason we need PICA, (I feel,) is because we are producing documents. Lots of documents. Most of these documents describe interfaces, systems, machinery.

We have two problems:

• finding the documents is kind of tricky
• once found, most people think we're not serious about them

PICA will solve both of these issues.

The way we've been managing the documents so far has been: Storing them on wiki pages, storing them in e-mail, referring to IRC chat logs, Moon-Edit pages, the works.

Consider:

• HttpPipe? -- on a wiki page
• XmlRpcFilteringPipe? -- on a wiki page, on Les Orchard's wiki
• ULI over XML-RPC/POST/GET -- God knows where they're written, I think I just keep them in my head, along with everyone else
• ULI within Python -- you'd have to get kpreid and I to explain it to you
• MachineCodeBlocks? -- another page on this wiki, everyone's wondering where discussion about it should go
• MachineCodeBlocks? form for Wiki descriptions and WikiEngine? descriptions - you have to look through a log of a MoonEdit? conversation
• WikiBanList? -- I think it's a page on this wiki
• Local Names -- the sole exception, described on http://ln.taoriver.net/spec-1.1.html , complete with it's own website

Incidentally, the one specification that's actually made to be presented semi-professionally: This one specification has received the most interest and development. Greg Schueler found it, and wrote an implementation in Perl.

Why did I specify it and present it nice? Because people were telling me to. "Gee, is this the spec? Or that? Which wiki page am I supposed to look at?" They wanted it clear and unambiguous. When I did, suddenly people took note. Even my own attitude about Local Names changed. So, it is clear to me that there is value in a solid looking clean presentation.

The XmlRpcFilteringPipe? is something that should have been widely implemented like,... 2-3 years ago. I think people just don't know about it, because it's some idea written on some wiki page on Les Orchard's site.

We are producing specifications like mad. There's just so much specification work to do, it's incredible. The limiting factor in getting all these systems to talk together is lack of specification. You know this, I know this, we both know this.

I have discovered that I can code up working implementations very quickly. Many of our tiny specs, you can implement them in a day or two. A month, tops.

The time it takes to get our specifications agreed upon and out the door, though, starts at around 1-2 months. Eh,... well, I'm going into another discussion. But, anyways:

I feel that we would gain a lot of value, as an alliance, if we made an easy system for ratifying our specifications, collecting them together into one navigable space, and presenting them nicely.

We get that social and mechanical system in place, ("PICA, the Cyborg,") and we're golden.

We don't need a ton of documentation. (did you see my recommendations?) Basically, it's just: Anyone who's interested in being a PICA member is a PICA member. You can't be a corporation, you can't be a government. You have to be a person, you have to be interested, you have to be benevolent towards PICA, and you're a member. Casual? Hell yah.

Any group of 20 people who want to pass a spec can pass a spec. Say PICA has 100 people participating in it. 20 people can pass a spec. It doesn't matter what the other 80 think. If 20 people sign on, hey- that's probably worth something. We're not here to quibble and argue, we're here to meet each other, publish specifications, so we can write our codes to agree with each other.

I'm not at all worried about Sun, IBM, Microsoft, whoever the hell. We're incomprehensible to them. I mean, seriously: Can you imagine IBM publishing a PICA spec? They'd lose- what does Chomsky call it... "Credibility." It'd be like the UN deciding to meet in a fort Sakura (she's 4 years old now) made in our living room, in our apartment. It'd be the most rediculous thing you've ever heard of.

I'm not terribly worried about patents and other such things either. If anyone is worried about patents, they should not be writing software right now. Pretty much any project is invariably going to violate somebody's patent. So, if we want to play it strictly by the boundaries of patents, I would just withdraw entirely from writing software. PICA's the least of your concern at that point.

If PICA somehow raises eyebrows, and gets destroyed, where do we end up? Exactly where we are right now: Out in the boonies, completely off anybody's radar. You just start the whole process up again, with a new name. I'd call it: "CHUU."

Here's what happens: Someone gets a cool idea. They go, "Hey! Here's an idea!" Someone else says, "Yah! I had that same idea!" There are big ideas, and little ideas. We want to understand big ideas, and let the little details sort themselves out. After the ideas thought and told, it's time to act. If you find yourself writing papers upon papers, organizing people for the sake of organizing people, or using fancy language and what not, you're dead. You gotta act. In our case, that means: Write code.

Damn straight. I stand by every word.

But, we have to write specifications. And they have to be nice and it would be really good if they were collected. Making specifications that aren't specific is like writing code that the compiler won't eat.

The specifications have to be thought about, people have to buy into them, because otherwise you make errors, which means changes, which means lots of people rewriting the interfaces to their code, which means lack of interoperability, which means it doesn't go anywhere.

So, the strategy I've been thinking is:

• Collect 20 signatures, sigils, identifiers, whatever: And stamp the document with it. "Look! 20 people thought about this and liked it!"
• Present it nice. Nice presentation communications "20 people thought about this and liked it" rather well.
• Collect it with other stuff: Strength in numbers. Builds trust, people get familiar with the form, ideas in the documents, and people behind them.

That's the idea. Basically.

(this post to the old CommunityWiki? page was deleted b/c it was not public domain)

To reiterate what Lion already said in reply to Murray's older post:

Yes, this is not really a "standards" organization, this is a "boonies" organization. It's purpose is NOT to define authoritative standards. It's purpose is to assist in the development of proto-standards. Like standards organizations, PICA is basically administrative. It's function is mostly as a SharedAwarenessSystem, to take notes on what is happening. It lets everyone know what has been proposed, and which proposals have a few (>20) supporters.

Timeline for a standard:

• 1) Bob has an idea for a protocol, syntax, or format. He writes up a specification.
• 2) Bob (and friends?) submit his spec to PICA (maybe a submission needs 3 sponsors?). It is issued as a numbered PICA memo with some status like "just an idea"
• 3) Bob discusses his idea on PICA, but also elsewhere
• 4) Bob's specification is refined; new versions are issued of the PICA memo so that everyone knows what's current
• 5) 20 people give their signatures to Bob's spec. The PICA status is changed from "just an idea" to "PICA proposal"
• 6) Now everyone who watches PICA takes note, because here's a new spec that at least 20 others think is worthwhile
• 7) Work goes on developing and implementing the spec for a few years
• 8) By this time, Bob's idea has a bunch of implementations, is pretty much fixed, and has a lot of buzz. Now the spec is submitted to IETF.

So, PICA helps Bob's idea in steps 2-6, long before it is a standard. By the time it's being considered as a serious standard, PICA is no longer involved; now things are handled by the IETF.