This is the *talk* page for ApacheWikiConventions
For the purpose of discussion the conventions please start by following convention #1 regardless of your agreement with it. - AndrewCOliver
The wiki is currently very youthful and vigous so it is certainly premature to start imposing an elegant knowledge representation scheme over the pages. Most wiki's tend to settle into having some kind of scheme. These are usually created using nameing conventions. For example here there has already emerged a universe of pages like: VelocityProjectPages, APRProjectPages, ApacheCommonsProjectPages, etc. etc. Once you have some conventions of this kind you can do searchs for those tokens and query out all the pages of a given kind (well at least those that adopted the convention.
Some wild and crazy folks then create pages for each one of the mnemonics. For example:
*ProjectPages (occationally *ProjectPage)
- *FAQ
- Jakarta*
- Java*
When such denotational knowledge schemas become really popular then you need to go back and rename lots of pages to bring them into conformance. At that point you usually edit the old pages to contain only a pointer to the new page with the normative name.
Like all coding conventions this makes the world a better place, and is obviously a best practice. Like all coding conventions (or other attempts to get a dominate standards bandwagon) it tends volcano generating an endly lava flow of flame wars.
Fortunately, unlike coding conventions, wikis support multiple parallel conventions. For instance, on WardsWiki, there are Categories (see Wiki:CategoryCategory), Wiki:RoadMaps, FAQs, and various other ways of organizing topics all coexisting peacefully. The only flame-like war was over categories vs. topics, and that ended pretty peacefully when categories turned out to be more popular (and thus useful).
I like to say that all program language use all the punctuation characters sooner or later. Bring back the APL keyboard!!
Meanwhile the colon is taken. It's used for inter wiki linking.
I agree that urging a neutral point of view upon the content (admitting, of course, that all language is hopelessly culturally embedded).
I lean toward adopting the convention that we put either partitition the NPOV from the talk by a double horizontal bar; or we put in a related disucssion node with a *Talk denotational convention. - BenHyde (oh bleck, that's not my handle...)
I'll see if I can link to the advice on this (the bars). Its not great idea. Basically its a form of ownership... Same issues apply to it as in software. - AndrewCOliver
The colon can be used for both. I made Talk link to this wiki with "?Talk". This convention came from www.wikipedia.org.
I'm confused. The colon is being used in the interlinking to provide a way to tie together the namespaces of all the world's wiki. For example if we add a line like: CocoonWiki http://wiki.cocoondev.org/Wiki.jsp?page= to the interlinking file then people can write CocoonWiki:Sitemap and interlink with that wiki same goes for the subversion wiki, etc. etc. One consequence of all that is the prefix that appears before the colon ought to be globally unique (like a domain name). - ben
Have you LOOKED at http://www.wikipedia.org?
Yes, of course, like I said I'm confused. I think I understand what your trying to do, i.e. mimic their convention of using the colon to partition namespaces within our communities wikis. I think that's a fine plan. I'm trying to point out that's a severe subset of using the colon to partition the name space of the universe of all wiki. They seem to have decided not to participate in the universal wiki namespace. I think we should. Particularly because it's the path of least resistance - i.e. it's what the code already does. Do you think you understand what I'm saying - can you echo it back so we can attempt to synchronize models. Example of interlinking Why:MoveFromArgumentTypeAToArgumentTypeB at work.
I understand what you're saying. Bla colon as a world unique identifier. It resembles the early internet reason for /etc/hosts. That being said. I've taken one word "Talk" plus "German" and "Spanish"... There isn't a standard yet for these purposes. Grabbing these words doesn't currently interfere with this emerging "standard" and so the damage is marginal (and I suggest that Wikipedia being so active will probably prevent these from ever being in conflict). If you object to it I suggest using "TalkPageName" as being equivilent and acceptable. The colon notation for talk and will be there for those who want to maintain compatibility with the other standard usage. They render to the same page either way TalkApacheWikiConventions == [Talk:ApacheWikiConventions Talk:ApacheWikiConventions]. Its more the concept that is important to me than the notation ([TalkPage]s rather than a bunch of pages people weigh in a biased opinion rather than a handy NPOV page), this generally works well on wikipedia. - AndrewCOliver
I totally agree with the analogy to the /etc/host file.
I like the seperating of a topics MeatBall:NeutralPointOfView from the Talk* conversation(s) about it. I'm comfortable with a Talk* convention. I'd be happy to see a list, like the one above (Java* *ProjectPages, Talk*) along with a hint about when to use that denotation. Currently, I think, those hints shouldn't be proscriptive but rather descriptive.
I'm taken aback how hard it is to do that square bracket colon thing. I think that's a sign of fighting against the flow. I don't see it's making things more delightful.
I prefer doing just plain Talk* or German*.
I think there is a curious subplot here. I don't have a model yet what this Wiki will get used for. I'm quite curious to see, but not particularly interesting in pre-judging what it might be. For example maybe it's really for random community citizens to keep their 'lab-books' or maybe it's another blog, or maybe it's a reference work of some kind. When you first mentioned wikipedia I wondered - oh, does he think that's the kind of thing we are building here... humm, mabe Why, or Everything2, or <what ever> as better example of what is going to haching out.
I came to the wiki discussion late, so maybe there was a well understood idea what role it was to be guided to fill.
Just curious... Why use a prefix to denote the talk page instead of using [UseMod:SubPages SubPages]? It seems like if we are going to use [UseMod:SubPages SubPage] we might as well use something like { { { /Discuss } } } instead...
Arbitrary. The great thing about standards is that there are so many to choose from.
Gentlemen, I do think we're BikeShedding here.. I mean what is important is the convention and not the notation. I really don't care about the notation. Pick one arbitrarily, stick with it. doing [Talk:ApacheWikiConventions Talk:ApacheWikiConventions] is equivilent to TalkApacheWikiConventions. They go to the same page, so its not important which one you use. As for { { { /Discuss } } } I prefer { { { /Talk } } } personally, but its totally irrelevant. One should be picked and documented, it doesn't matter which. I suggest someone propose one on the wikidiffs@apache.org list and we vote on it.
As for what we're building... we're building whatever gets built, but there are lots of precident and examples of similar things which can tell us what to avoid. Conventions make it cleaner and easier to read. Personally I think/maybe hope this turns out like WardsWiki only more or less pertinent to Apache (without being stringantly regulated to be such). The idea is that whatever will be will be.. emergence. I'm also hoping that better/more documentation will evolve. And I'm hoping that POI developers will have a good place to hash out plans.. But thats what I want.. Emergence will decide (though likely I'll get at least what I put into it).. Unsettling I know, but thats my "subplot".. You may just be building your LabBooks.
-AndrewCOliver
I'm partial to SubPages, but I also think that something like a convention will emerge over time. I've used SubPages on /CodecProjectPages, and I believe that those subpages will eventually be transformed into meaningful official documentation. (Of course, dependent on Codec ever awakening from a deep languishing slumber.)
I don't know why, but I have a problem with *ProjectPages. I tend to agree with what has been done on the James page. I think that StrutsProjectPages should just be Struts, but then again, I'm partial to SubPages and it makes life easier as such.
-TimOBrien