To save this page you must answer this question:
How many lives does a cat have?
= Discussion = What is "freestandards.org" ( http://freestandards.org/ ) ? I think there used to be a wiki there in 2006. What happened to the wiki? How do I let the people of that wiki know about PICA? -- DavidCary 2007-10-11 "OpenI18N.org :: The Free standards Group Open Internationalisation Initiative" ( http://www.openi18n.org/ ). How do I let these people know about PICA ? -- DavidCary 2007-10-11 "openformats.org is a collaborative documentation project on the definition and use of open formats and public standards, and related technical, economical and political issues" ( http://wikiindex.org/Openformats.org ). How dow I let these people know about PICA ? -- DavidCary 2008-06-29 "we don't want to change the standard ... because we believe there should be no standard. I know this statement may sound even bolder than talking about changing a standard, ... Now, if there was a standard stating this, I'd even sign a petition to support it. ... so-called standards that attempt to fit every feet in the same shoe are doomed to failure. Standardize on flexibility instead." -- [http://www.gobolinux.org/index.php?page=doc/articles/clueless "I am not clueless: Myths and misconceptions about the design of GoboLinux"] by Hisham H. Muhammad == older discussion == [new:LionKimbro:2005-04-12 20:19 UTC] 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.) [new:MurrayAltheim:2005-09-04 07:25 UTC] (this post to the old CommunityWiki page was deleted b/c it was not public domain) [new:LionKimbro:2005-04-13 03:50 UTC] 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. [new:LionKimbro:2005-04-13 15:55 UTC] I'd like to rework the page, including some deletions, but I fear removing ideas that people are attached to. BayleShanks has taken the lead in refactoring, and I don't want to interfere with that work. So, I'll just rework my previous post into a BulletSummaryBlock. * Aspirations & Atmosphere: ** I'm impressed with MurrayAltheim's work. ** I believe we can do useful work here, if not as grand. ** I like the "schoolyard" atmosphere. (vs. the courtroom) * Need for PICA: ** We're making lots of interface specifications. ** They need to be collected, not scattered. ** They need to be thought out. ** They need to ''show'' that they are thought out. ** specifications: HttpPipe, XmlRpcFilteringPipe, ULI over XML-RPC/POST/GET, ULI in Python, MachineCodeBlocks, & description for wiki, wiki engines, WikiBlackList ** Since giving LocalNames a nice spec & site, it's received a lot more attention from others. ** We have a lot more specifications coming: Machines need to talk with other machines. ** Cheap: Writing software. ** Expensive: Getting software to talk with other software. * PICA: Easy system for ratifying, collecting, presenting specifications. ** We don't need a ton of documentation. * PICA rules: ** A registered member is someone who wants to be a registered member, and puts their name on a list. ** A group of 20 registered members can pass a spec. * justifications: ** Why no vote? Because we're here to present specs that many people have rallied behind, ''not'' to pit ourselves mano-a-mano. ** We're too small to worry about IBM, Microsoft, IETF, whatefver. ** If we're worried about patents, we may as well not write software. ** If PICA is destroyed, we can remake it somewhere else. [new:MurrayAltheim:2005-04-14 03:32 UTC] (this post to the old CommunityWiki page was deleted b/c it was not public domain) [new:BayleShanks:2005-04-14 08:49 UTC] Re: "anyone can be a member, but some are registered members": i think that's sort of abusing the standard meaning of "member". I think PICA should have a list of its members. Also, I feel the membership should be a little tighter. We don't want to be intimidating, but we still want to be serious. If membership has some attached privilages and responsibilities (even as minor as, privilage: saying you're a member, responsibility: sign up; although I think it should be a little more than that), then members will feel more attached to the organization. A related point: we'll need to have bylaws, and we'll need a formal procedure to amend those bylaws. Which should probably be that the members take a vote of some sort. So, we need a list of voting members at least. I would propose that membership be much tighter than we have it now (but still not intimidating). I propose that anyone can become a "member", who can do all the main stuff, but that it's slightly more difficult to become a "voting member", i.e. person who sets policy for PICA. I'm thinking that anyone who wants to can become a voting member, except for people whom are considered disagreeable by 1/3 or more of the other voting members. In great detail: * Anyone can join the mailing list or the BBS or the wiki * Anyone can apply to become a member; applications are usually granted routinely * "members" can do proto-standards stuff within PICA; "voting members" can do meta-stuff like set PICA policy * "members" can count towards the 20 signature PICA proposal minimum; but only "voting members" can vote on bylaw changes * To become a voting member, there are 3 conditions: ** 6 months of being a member ** Have a voting member sponsor ** 3/4 vote of other voting members are in favor of making a voting member *** Actually, anyone may become a voting member by 3/4 vote at any time; the 6mo is a guideline to ensure that the organization has a chance to get to know the person, but in some cases (i.e. someone that most people already know) this isn't necessary *** By tradition, voting members should make an effort to contact members whom they would sponsor and offer to sponsor; nothing's wrong with asking someone to sponsor you, but some people might be too shy * Members, even voting members, can be expelled by a majority vote of voting members. If a member is expelled within 1 year of being a voting member, their sponsor has voting privs suspended for 1 year ** (of course, there could be some sort of vote to suspend this rule if people decided punishing the sponsor in a particular case was unfair) * Becoming a voting member should not be difficult if you get along with everyone else. It should not be limited to friends-of-friends of the original founders. If PICA had 20,000 members, I would expect it would have 2,000 voting members; it should not be like a board of directors, with only like 7 people on the board. Why? * First, this'll add a little more psychological weight to the organization * Second, there are plenty of people who may be smart but who can't get along with others in many situations. We've seen these people wreak havoc in open wiki communities. One problem is that in an open wiki, these people claim as much right to set policy as everyone else, and then claim that any attempt by the community to tone them down is against policy. I'm not talking about people who have a small number of other people whom they don't get along with, I'm talking about the people who cause huge wiki-wide wars. Let's keep these people out of the voting membership when possible. * Third, because becoming a voting member is a small annoyance, we'll probably minimize the number of people who have a vote, who use that vote, but who don't care enough about the organization to read the discussions surrounding that vote This sounds complicated, but it's really simple in terms of "members", which is what matters. And hopefully it wouldn't prevent most people who wanted to become voting members from doing so. [new:BayleShanks:2005-04-14 09:01 UTC] 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. [new:BayleShanks:2005-04-14 09:26 UTC] Patents: I agree that being sure there are no patent problems is impossible, but we may as well at least make a small effort. I think that any member who submits a PICA memo, or signs it, must agree that * (1) they aren't aware of any patent which would cover the submission * (1a) In their best judgement, there probably isn't such a patent (this is to guard against a corporation sending in reps with plausible deniability about specific patents; they might not know for a fact that this patent exists, but if they suspect that their corporation has one and isn't telling them just so that they can submit a proposal to PICA, then they would meet condition (1) but not (1a)) * (2) if they have or come into possession of such a patent in the future, they will give it to PICA In addition, any PICA member who is even aware of the submission of a memo for which they know of or should know of (this is shorthand for conditions (1) and (1a)) is obligated to disclose this within two weeks. All public PICA documents, including memos and bylaws and what have you, should have some standard copyright status, like PD or CC-BY-SA-NC. PICA will own at least an unlimited sublicensable license to all public PICA documents, and will be free to re-release them under any copyright license that it wants in the future, should it choose to do so. ---- Yet another person complains about standards documents from other organizations: [http://www.controldesign.com/heardondiscrete/?p=34 "Why am I paying so much for these documents?"] If I give away safety standards for free -- I won't make any money from it, but if it allows more people to read those documents and learn how to do things better and safer -- perhaps the guy wiring my house or designing some product I buy -- and it prevents my premature death, isn't that worth it? PICA is currently focused on "software protocol standards" -- is there some other wiki more appropriate for "hardware safety standards" ? -- DavidCary ---- [http://www.joelonsoftware.com/items/2008/03/17.html "Martian Headsets"] by Joel on Software, March 17, 2008 claims that "it’s required reading for every developer who needs to design interoperable systems." ... discusses ONE TO ONE, ONE TO MANY, SEQUENCE-MANY, and MANY-MANY ... and mentions that "standards documents ... Those documents are super confusing." I hope the Pica wiki will develop standards documents that are ... somewhat less confusing. ----
Summary:
This change is a minor edit.
Username: