DT: Home page was just cleaned up by ricks99. Please post a specific proposal to the dev list.
MLP: Decisions by email? (shudder). Wiki developers, eat thine own dogfood?
MLP: next home page - the prototype.

DT: xavi helped get items postitioned on the page, let's make sure all links work and install it
Xavi: and update css according to footnotes on next home page
MLP: nice work!
ML: nice work!
Done! (June 7. --Xavi, once Marc gave editors access to server - I could edit the css there)
"Mittwoch theme" remains a todo: chibaguy's nice proposal of nice Mittwoch theme!

MLP:Looks good!

Latest version at http://zukakakina.com/tiki-switch_theme.php?theme=mittwoch.css. See Coffeeshop post.

DT: This was proposed by franck in IRC. I like the idea of having more screen real estate. Please review the next motion as well.
chibaguy: I agree that 3 columns make the pages too cluttered. I'd like to see a slightly larger type size and more white space.

in favor: xavi, MLP, sylvieg, chibaguy, ricks99
Done! (I see on June 7. --chibaguy)

ML: I can live with any choice as long as we are consistent. Keywords page seems the way to go 😊 Let's decide on a masterlist and after, we clean up all the help links from the software itself and from other *.tiki.org sites...
Xavi: "I can live with any choice as long as we are consistent". Mee too. 😊

Marc: I renamed all the pages. I hope it's OK with everyone.
MLP: Right on. I've refactored the motions. I concur.
chibaguy: I think the logical (common sense/normal usage) way should apply regarding singular/plural and keyword length. As "smiley" shows, plural is often better. Sometimes more is better than less, as with "User Tasks" vs. "Tasks." It's possible to simplify and standardize too much and lose meaning in the process. I think things that are commonly seen/used in plural should have their doc page in plural form: "Image galleries" when thought of as a feature is more natural than "Image gallery," "Comments" more natural than "Comment," etc. Sorry, but the new singular forms seem unnaturally truncated to me and don't have the immediate recognition that the plural forms do.
Xavi: I fully agree with Gary's comment. (chibaguy).

MLP: Ok "prefer the singluar" dropped in favor of a more natural approach.

chibaguy (after reading Skype log discussion of singular vs. plural for page names): [soapbox mode on] I think "natural speech" vs. "search term" isn't the best way to approach this question. People doing searches generally enter the singular form because it's the most common, most-root form and thus most likely to return good results. But there is a different rationale for page names. What is the logic for, for example, a page named "Comment" that has a title (h1 headline at page top) of "Comments"? This inconsistency shows there is something wrong with the page name, which doesn't correctly label the page content. If the page defines (the concept or whatever of) "comment," as in a glossary, then singular is appropriate. But the doc pages here are more comprehensive than that, and the plural form is often more suitable. This is the logic as I see it: reflect in the page name the use of the term in the Tiki context. People may search for "smiley" but they don't think "How do I use smiley?" An index will contain "smiley", but it will often refer to a page called "Smileys" or "Using Smileys" or whatever. That's the nature of that connection.

Keywords can still be (and generally should be) singular, but they can link to pages named with either the singular or plural form (or a multi-word term if that's appropriate). It's counterproductive to streamline for simplicity's sake if comprehensibility is reduced in the process. When I see singular forms of words where I (as a user of the language) expect them to be plural, it strikes me as taking a principle too far. The impression is skeletal output that needs a commonsense touch to make it (in this case) good English. [soapbox mode off]

Footnotes ---> "My Notes" (in favour: ) or "Private Notes" (in favour: Xavi, chibaguy)
Inter-user messages ---> "Tiki Mail" or "Messages" (in favour: Xavi, chibaguy) or ""Message"
Debugger Console ---> Debugger (whatever: Xavi)
Articles --> Articles done already.

note we gotta harmonize it across atleast two, doc and dev.

ML: Let's be realistic! Let's get things going properly in English and the other languages will evolve organically.

MLP: Oui!
Xavi: Remember people tries to translate pages step by step in their language. And it's easier for them if empty pages for their language are available, so that they only need to edit that desired pagew and go translating. Otherwise, they need to request an editor/admin to add their pages to an structure... Review "fivos" case last week with greek pages (overwriting english pages)... (some info in the forum )

(you can wiki the motion, eh.)

• feature tour!
• hype!
• tiki news!
• front desk (shoutbox)
• developer community / user pages

• how to, faq and "official" documentation (whatever that means)
• Factual information about what Tiki does now.
• glossary of terms
• links to dev. for bug reports
• user forums! (moved to doc to better integrate with the documentation)

• Wishlist of what Tiki could or should do in the future (bugs, RFEs, etc), contributor user tracker

• themes repository
• themes support
• theme-related tutorials, howtos, etc.
• extending Tiki visually such as by means of mods to .tpls, etc.

• specialized sites

• custom modules
• commits that never made it in
• extending Tiki functionally via hacks to .php files, etc.
• eventually make it gforge-like area (maybe with workspaces?)

Future project to ease translations

Do we encourage documentation in French to go on doc.tw.o or fr.tiki.org?

MLP: Use multilanguage features as they are now?
Xavi: I'd suggest to use intertiki, and french doc. being set at doc.tw.o. Granting editor perms to editors at fr.tw.o that write documentation, etc.

ML: it seems like a good feature. Anyone object? If so, we can turn off,
Xavi: ok to keep it.

ML: Features are so different. Some need one page, some need 5-6. Better to start with one page and refactor as needed. But the goal is to still have a structure and ultimately use WebHelp to make offline copies and print from structures to PDF to make a manual at least as great as the Tiki 1.6 docs.
MLP: Agree - tracker for instance - really you need to walk people through screen by screen.

Xavi: However, I like the basic common structure for all pages (Feature User, Feature Admin, Feature Details). I would suggest to keep it as it is, and and new pages when and where needed. But for new documenters, that basic division in three basic pages per feature allow organizaing content, etc.

MLP: About the Tikiwiki documentation - updated.

Idea: have a nice quicktag for voting, which adds these nice icons:
http://microformats.org/wiki/icons

H2 {
	...
	border-bottom: 1px dashed grey;
}
H3 {
	...
	border-bottom: 1px dashed lightgrey;
}

Xavi: I suggest the example in the box below: dashed grey for h2, dashed light-grey for h3. no line for h1.

Xavi: I hadn't seen that before (just discovered it today), and I think it's not needed, or even that it diverts to much the places to invest energies for new documenters. I propose to use the plain Wiki way (most documentation bugs could be fixed by normal registered users, nowadays, since they can edit almost all pages).

If motion is accepted, link from http://dev.tiki.org/Documentation to http://doc.tiki.org/tiki-view_tracker.php?trackerId=8 ("Doc Bugs & Wishlist") should be removed, and write Author Coffeeshop forum instead.

Next meeting: July 2007
This was a meeting of the editorial board.