To add to our Naming conventions a rule about feature names, and make it universal on doc.tiki.org, dev.tiki.org and tikiwiki.org, it is important to have a common way of naming features. So we always know that doc:Newsreader is it does and dev:Newsreader is what we wish it did.

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. 😊
dthacker: throw this motion out, use the keywords page

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]

This seems to have been implicitly approved? Forwarding to Editorial Board Meeting 2007 08 for explicit approval.

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

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 ) ML: Ok, this means the current UI is not clear enough. There should be a button "create a new page/translation" in one step...
dthacker: opposed

(you can wiki the motion, eh.)

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.
dthacker: agree with Xavi

ML: it seems like a good feature. Anyone object? If so, we can turn off,
Xavi: ok to keep it.
dthacker: 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.
dthacker: do not create more than one blank page per feature. Agree

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).
dthacker: I thought I killed it already! agreed.
MLP: in favor documentation status is best for errors in documentation, bugs in code should go to dev.

ricks99: against. currently the __discuss_ link is being used by readers to log issues and request troubleshooting help. This creates a lot of noise (consider: http://tiki-view_forum_thread.php?forumId=1&comments_parentId=470).. if this site is supposed to be for compelted, factual info only, should this be removed? I like having the tracker

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.

ML added a logout button, to be approved
ML added a module with explanation/link to register on tikiwiki.org, copied from themes.tiki.org to be approved.

• I would suggest to include an option in some admin interface: if intertiki is toggled on, then the login-box shows some content like the one in this box you made (something like done in http://edu.tiki.org/tiki-login_scr.php), but getting automatically the intertiki master site url and link to register there. (Xavi)

I mean all the subsections 5.x at All the Documentation and thus files/Tiki19beta.odt (files/Tiki19beta.pdf)...

Opinions?
dthacker: agreed. propose alpha sort
mlpvolt: disagree - we need to sort the features into categories, so people are aware of related/overlapping features. categories plus alphabetical is fine with me.

dthacker: agreed. I'll work on modules and plugins. I would like to do another test of 1.9.8 links before release. Maybe we can schedule
a hug day.

In order to increase visibility of the the doc.tw.o resources, I propose that we add doc.tw.o (and possible tw.o, too) as a custom search provider. This would let users search the docs from their web browser. This is supported in FF and IE.

I am currently implementing a custom search provider for my site, and user feedback has been overwhelming positive.

See OpenSearch for details.

Just an idea........

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