To save this page you must answer this question:
What is the first letter of this question?
All material on PicaWiki is PrimarilyPublicDomain. == Introduction == The '''Pro-am Internet Communications Alliance''' is a hypothetical organization. "Pro-am" stands for [ProAm "professional-amateur."] The goal of '''PICA''' (pronounced "pika," as in "pikachu") is: : to encourage the development of Internet standards by providing an accessible standards track and by encouraging a community of implementation and support To make it perfectly clear: '''this is a mini-[http://en.wikipedia.org/wiki/Internet_Engineering_Task_Force IETF],''' complete with numbered documents and all. == List of people interested in initially joining/starting up PICA == * LionKimbro * AlexSchroeder? * JulianKrause? * BayleShanks * MattisManzel == More details == === What needs will PICA meet? === PICA attacks the problems of * no one hearing about each other's standards ideas * standards efforts being hard to find * generating initial momentum for efforts * (if it does voting) providing a stamp of approval for new standards, * keeping half-finished efforts alive in the form of memos even during "slow spells" of a couple of years. * Today, a lot of good protocol ideas are just lost because there's not a focused effort to develop protocols, and to integrate them into our software. * Today, someone with a new idea is faced with "Well, if you can get your idea popular enough, then I'll think about putting it into my software.". * However, perhaps there are plenty of people willing and happy to integrate, we're just all seperated into these little islands right now. * Example: "In 2002 or whatever, Les Orchard wrote the XmlRpcFilteringPipe. Great idea. Wonderful idea. But who heard about it? He published it to his ''blog''. How many people cared? No: His idea needs to go before a group of people who are listening and cataloging and explicitely looking for ideas, and pre-approving ideas. We want pre-approval. It provides courage." ---- ==== Anecdote from LionKimbro ==== Okay, so we found those groups, and it was good. By working on SubPathetaEdit, we collected ''all'' (as far as I know) of the energy into rewrites. At least we all know each other- at the very least. CoEd, as far as I know, (@DATE@), is the one holding the torch. crschmidt and Eloquence abandoned ''their'' work, I think the LEO guys are still working, but within Leo, and I think CoEd is holding it right now; that's thecrypto. If you want details on this subject, talk with me, or one of them, we'll fill you in on the details. I like Palimpsest, I think that's the way to go. Other story: ''General Text Filter.'' I looked around. ''Didn't find anything.'' I thought, "DAMN! This is a great idea!" I'm shocked that there isn't anything! Looked all over the place, didn't find it. ''It costs so little to make.'' I just went ahead and started doing it. And then, ''I found XmlRpcFilteringPipe!'' I told everybody, with lots of excitement! ''Holy Shit! There's one already!'' And what's more, it had ''2 plugins'' for it already! That is, a Movable Type plugin, and a Bloxsom plugin. What's more, it already worked with Twiki's, because it was implemented in Twiki. (Or at least, it was; I don't know if it is now.) We had to do a little work improving the plugins, they weren't totally up to spec, and they had hard-coded links to URLS, but we fixed them up, and promoted the standard. It was only like 4 lines of code to adapt my existing code to the discovered format, and I did so. Piece of cake, and now, we have a bunch of plugins and working servers. It's wonderful. It was really surprising, because our respective specs were ''near-identical.'' The only difference, was I had thought to put in a self-documentation system, and Les had thought to put in a content type. I dumped the doc system, and incorporated the content type. ''Wonderful.'' It ''just works.'' Now, we are in the process of making an HTTP Post mechanism, instead of XML-RPC. There is only one delimma left, and I think I'm going to just take the lead, say, "It's this way," and start implementing. Nobody ''really'' cares about which way the decision goes, it's kind of dumb to be hung up on it. I think everyone just wants to see it go forward now. I keep thinking, "This should ''all'' have been done at least 2 years ago." Why didn't it happen? Because there was nothing like PICA. It's just haphazard, "here's an idea, does anybody like it?" And ''of course,'' the response is: "no," or utter silence. I'm sorry, that's just the way of things. That's just how people respond to stuff. Like everyone's got a veto card. There's no use in hating it, or dislike it, you just have to find ways around. Otherwise, nobody will implement anything anywhere. Sad fact. === What functions will PICA provide? === ==== High-level functions ==== * a SharedAwarenessSystem * an accessible, fair, quick, easy, and not overly formal standards track * community connections, that we might otherwise feel too shy to make * encouragement! ==== More specifically ==== * a formal submission queue; PICA numbered memo series ** Benefits: *** everyone will know when ideas are presented seriously *** this will help demarcate when the brainstorming stage is over, and a proposal is being presented for consideration by the community * a hub for people to publicize their efforts ** will include news about non-PICA proposals ** bulletin board, wiki, mailing list ** Benefits: *** Exposure for proposals *** A way for interested people to hear about new proposals * a catalog of standards efforts, both PICA and non-PICA ** including notes on the ''relationships between'' various standards *** For example, there should be an entry on Atom, and somewhere on that page there should be a link to the entry on WebDAV. ** (this is the "standards wiki" idea) * keeping track of who/how many people ("signees") endorse each standard ** maybe: a voting or endorsement threshold process to make some of the numbered memos "official PICA standards" * documentation support * people willing, even eager, to make their software work with yours * ''fun'' and ''glory'' === What kind of projects would it handle? === The PICA track would include things like: * XmlRpcFilteringPipe, and the forthcoming HttpPipe * LocalNames * ULI, the UniversalLineInterface * CoEd * [[nLSD]] * OverHear * a method of instant signaling across the Internet * various Wiki:TextFilters * CommBot * code to make it easy to read from or write to [http://www.openclipart.org/ the Open Clipart Library] * a HalfWiki document store access interface * an interface to get a directory of images from a wiki, and recommend methods for retrieving and posting images to the wiki I suspect that many of the formats are ''too cool'' for us, but it would be amazing to see things like XML-RPC, DOAP, Blogging APIs, MarkDown, etc., join forces with us. That said, ''it is not our aim.'' Our aim is ''to find people who want to work together with us,'' and write our software ''together.'' ''Should that set of people'' share that aim, then we would want to work with them. ''If not,'' then oh well, too bad. No hard feelings. === Aren't there already lots of standards organizations? === Consider: * the IETF. * PEPs. * the ASF. * the Mozilla foundation. * W3C. * the Jabber guys. None of these fit our niche, for various reason. * IETF is too formal. (and necessarily so; this isn't a criticism. It's just not our nitch.) * W3C is absolutely closed to us; it is targeted at large organizations * The others are all focused on specific projects (PEPs are for Python, silly. The ASF is for Apache and weird Java-Apache interop stuff. Mozilla is, well, Mozilla. The Jabber guys are Jabber.) There ''are'' "pro" efforts in our space. ''They hate each other.'' They ''scare'' me. They are not Pro-Am, they do not like the phrase "Pro-Am," they don't want to be anywhere near us. As Lion said: " They are ''viciously fighting against each other.'' I mean, have you seen it? It's positively bloody. I was walking by Dave Winer the other day, and it was like: ''' ''BLAM! BLAM! BLAM!'' ''' CZ-75. Guts ''everywhere!'' Absolutely disgusting; Horrible. Trust me: ''You don't want to go there.'' Part of the reason I am encouraging things like the efforts of artists and manifesto writers, is to keep it lighthearted, and friendly, and joyous. Things like that. " ---- ==== More on why not just IETF ==== I think that the IETF process is ''way'' too big, and ''way'' too formal, for our immediate purposes. ''Once we have some solid stuff,'' and it's implemented and people have seen it, and even people outside PICA implement it, then we can start talking IETF standardization. I'm astonished that ATOM made it! I think that means that IETF consideration, and eventual approval, is a reasonable thing to expect. === OK, but if you want a more open forum, there are plenty of wikis and bulletin boards already, aren't there? === Sure, and while each of these might have a one or two specification discussion on them, none of them are focused on formalizing and providing exposure for new specifications of all sorts. See "what needs will PICA meet?" and "What functions will PICA provide?", above. === What will members be expected to provide? === Developers would provide: * Love, goodwill, reasonable openness, and commitment to help * Free, open, or public domain software * access to the distribution for the purpose of implementing PICA protocols, designs * answers to questions about how the software works, and how to manipulate it ''Everyone'' would provide encouragement, support, their ideas, energy, and protocols. People who are not developers are ''invited'' to participate, contributing their enthusiasm, encouragement, ideas, publicity, translations, and art. === So who's gonna implement all these proposals? === This will happen just like it used to --- their supporters. However, with PICA, a good proposal will have more visibility, making it easier to gather supporters in the first place. === Votes & Membership === [new:LionKimbro:2005-01-19 06:54 UTC] The way I imagine it, PICA would have an explicit membership. Like the [Wiki:InternetEngineeringTaskForce IETF,] only ''individuals'' are recognized. Corporations, governments, and organizations cannot be members. However, a sufficiently advanced artificial intelligence with a distinct identity could conceivably be a member. Anonymous individuals could be members, provided that the member meets the entrance vote. === PICA documents === PICA documents (the equivalent of RFC's) could be: * specifications * UserInterface recommendations * application designs * how-to's * manifestos * even artwork -- if a picture or icon captures the spirit of what we do and believe in within PICA [new:LionKimbro:2005-01-19 07:19 UTC] I'm thinking: Call the documents "POI" documents, for "Point of Interest." The acronym is pulled from my book. It is completely arbitrary, it could be anything. Just not RFC, PEP, JEP, or ISO. (They're taken.) I would say: Encourage the use of HTML, PurpleNumbers, PlainTalk, and VisualLanguage. Perhaps permit smileys where appropriate, though that's likely not our spec documents. Maybe manifestos. We leave ASCII to the IETF. They are 133t. We are not. (Yet.) For some historical perspective on all this, I recommend reading, say, [http://www.ietf.org/rfc/rfc6.txt RFC 6.] Un hunh. Or, say, [http://www.ietf.org/rfc/rfc3.txt RFC 3,] which I found particularly illuminating. Mmm-Hm. Constrast [http://www.ietf.org/rfc/rfc2223.txt RFC 2223.] This isn't to throw stones: We absolutely love the IETF. If we're lucky, PICA documents may go on to become IETF documents- like ATOM did! But I perceive the need for our own, ''independent,'' baby RFC track. === Community Communication === [new:LionKimbro:2005-01-19 07:19 UTC] You all know that I dislike mailing lists; They are closed, they are difficult to work with, you have to send mail and confirm a bunch of junk in order to even get ''off'' the mailing list; all the usual LimitationsOfMailingLists. I'd say: Use a [http://www.phpbb.com/ BB Bulletin Board.] Ideally, we'd have a static site and a wiki as well. There'd be an IRC channel, ChumpBot, and whatever stuff we end up creating ourselves. === Argument for publishing specs supported by a minority === '''Acceptance''' does ''not'' require a majority. It requires only the collective endorsement of N people. I am taking N to be something like 10-20 people. Why do we choose some N number of people? * We want to make sure that the idea has had enough exposure, so that if there is already an existing standard, someone in the group should know about it, and be able to relay knowledge about it. More people = more likelihood that someone will know of an existing standard. * We want to make sure that there is some degree of support. We don't want someone to wake up with an idea, and just immediately start putting it into other people's code. That person needs to gain support for the idea. === Who would join PICA? === Who would initially participate in PICA? I imagine most everybody here, interested in seeing these technologies go forward. I imagine Sean Palmer, Aaron Schwarts, and Cristopher Schmidt may be interested. I imagine Les Orchard may be interested. I imagine that various wiki developers may be interested- I have met some who are struggling to find acceptance and interoperability for their whatever-it-is that they have made. (I'm immediately thinking: "Xwiki has some ''really incredible stuff'' for making collaboratively produced data structures and databases a reality.") === Optimistic visions === I have noticed something in my mind: When I start writing down my ideas, my brain gives me more ideas like that. It's like my brain goes: "Hey! ''You're'' paying ''attention!'' You like that? Here, let me give you ''some more.''" I believe it will be the same way with PICA, and developers. People will wake up, and go, "Wait! You care? You accept implementations?! You guys ROCK!" It'll be beautiful. :) ---- I think we'll see a lot of victories in our first 2-3 years. I think that people will recognize: "WHoah! These guys are getting things implemented! ''Look'' at how that software works together with ''that'' software! Isn't that amazing? Sure, that formats a little funky, and that thing over there is just butt ugly, but overall, look at that!" Also, we should not underestimate the role of the ''non-PICA'' members: They are likely to implement ''the best ideas'' from within PICA, magnifying what they saw in there. They will adopt PICA standards that ''they like,'' and thus, PICA standards will gain some reknown. Then we can say, "IETF, we present this experimental standard." Look: As this develops, ''all'' those people who have dreams, ''all'' those people who have ideas, ''will be attracted to PICA.'' === Stuff to do === [new:JulianKrause:2005-09-04 07:25 UTC] (this post to the old CommunityWiki page was deleted b/c it was not public domain) [new:BayleShanks:2005-07-07 05:19 UTC] Here is what we need to do next to make this happen: # Create a mailing list for interested people to discuss the formation of PICA # Create a wiki # On the mailing list and wiki, discuss and agree upon an initial constitution for PICA ** It isn't necessary to determine all PICA's bylaws before the constitution is written; at a minimum, we need a BootstrapConstitution, that specifies: *** How the membership list is determined, and how it can be changed *** How the constitution can be amended After these steps are complete, we can begin deciding how to carry out the actual business of PICA (how to do the PICA memo series, what are "PICA endorsed standards", if any, etc). So, who is going to setup and host the PICA mailing list?? I could set up a PICA mailing list and wiki hosted on the interwiki sourceforge umbrella project. The only downside to this is that PICA is supposed to trancend mere wiki, so the "interwiki-PICA" mailing list name might confuse some people. But we can always move it later. I'd rather start there and move it later rather than waiting months for someone to volunteer to host it elsewhere. ---- = 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 08:49 UTC] Re: PPD: I just wanted to retain maximal flexibility in case we end up re-using some of the words that we develop on this page as part of PICA -- i.e. in case PICA wants it's bylaws to be PD, but its bylaws use some sentences from this page, etc. [new:BayleShanks:2005-04-14 08:49 UTC] BTW, my girlfriend Katherine had a good idea: we should pronounce it "pike-a", and then use this guy as our mascot: http://images.google.com/images?q=tbn:wvqDuz2ZfJIJ:www.myhimalayas.com/ladakh_tso_moriri/images/pika.jpg he seems to embody our "niche" (as opposed to IETF, W3C, etc)! On the other hand, a "pica" seems to be a neat type of bird: http://images.google.com/images?q=tbn:EwSVj8YlErcJ:www.aves.be/images/blix/Dscn1404_pie.JPG so maybe that would be cool too. [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. [new:MattisManzel:2005-07-07 07:31 UTC] I like the magpie-birdy. They are beautiful, they fly around in my yard in Berlin sometimes and they are known for stealing shiny things which they love for some reasons. Like a spoon or a ring - putting them on your window-shelf they might take it away. Elster in German, ''diebische Elster'', thiefy pica. I won't be of much help for now on the project but I strongly support it. Added my name above, just for making it look better. [http://en.wikipedia.org/wiki/Pica_%28genus%29 en.wikipedia: pica], [http://commons.wikimedia.org/wiki/Special:Search?search=magpie&go=Go wikimedia.commons: magpie], [http://www.ijon.de/elster/] == More neat links == * http://www.google.com/search?hl=en&lr=&safe=off&q=%22Rough+Consensus+and+Running+Code%22&btnG=Search * http://www.arussell.org/papers/ICOHTEC2002Abstract.htm * http://www.open-organizations.org/
Summary:
This change is a minor edit.
Username: