This is a meeting of the Editorial Board - it runs online from June 1 to June 30. Undecided motions are carried over to the next month. Passing a motion requires 50% plus one of the current members. Members who miss two consecutive meetings are no longer considered current.

Last meeting: Editorial Board Meeting 2007 04
Next meeting: Editorial Board Meeting 2007 07

Old Business: - Done!

Renovate home page

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.

Discontinue Right Column

Motion: Discontinue the right column. Keep the Left column. Use phplayers menu for top bar login

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)

New Business

Naming conventions for features.

Motion 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.

A. Image Gallery (Keywords, not plural)
B. Image Galleries (Keywords, plural)
C. Image_Gallery (Hardspace, not plural)
D. Image_Galleries (Hardspace, plural)
E. ImageGallery (CamelCase) (please don't go there)

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. :-)

Motion: Naming Rules for Features

  1. Most common keyword - use the most common keyword for that feature typed into google.
  2. Redirect to/from plurals: Whatever the feature uses for a name (plural or singular) (whatever sounds most natural) we must redirect from the other e.g. Blog redirects to Blog, Articles to Articles.
  3. Shorter is better, Two words or less.
  4. No punctuation. Plain words only no camelcase

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]

Current features for renaming

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.

Batch creation from structures

Motion No more batch creation of page in 6 languages from structures + let's erase all non English pages which have no content. Sylvie is looking into a batch delete of all pages which have no content.

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 )

Clarify role doc.two vs dev.tw.o

(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

Multilingual development

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.

Organic growth


Let's create at least of page per Keyword and have Tiki helps links to there, but let's wait for a need to create Feature Admin, Feature Setting, Feature Ref, etc

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:

Underline h2 and h3 headers in default css for Tikiwiki sites


Make header2 and header3 styles in css be underlined with either dashed or dotted lines, either black or grey colours. Not h1 headers. Many people wants to separate more visually the sections between headers (a la mediawiki/Tikipedia style), and they are using hr html tag instead (uglier). Look in here at this page itself, as example (some people added here and there --- tags to visually separate sections...)

For instance, what I'm using in many places (see demo at http://www.moviments.net/drecerca/Ajuda )
(replace the "..." by the current details for that header in each css):

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

Line type options:

  1. Dashed
  2. Dotted

Line Colour

  1. black
  2. grey
  3. lightgrey

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

Discontinue tracker8 here at doc.tw.o (doc. bug report through trackers)


Discontinue tracker8 here at doc.tw.o. Use Author Coffeshop forum instead, either through the "discuss" button of the related page, or directly as a new thread.

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.


Get Started

Admin Guide User Guide


Keywords serve as "hubs" for navigation within the Tiki documentation. They correspond to development keywords (bug reports and feature requests):

Accessibility (WAI and 508)
Articles and Submissions
BigBlueButton audio/video/chat/screensharing
Browser Compatibility
Link Cache
Clean URLs
Communication Center
Compression (gzip)
Contacts (Address Book)
Contact us
Content Templates
Custom Home and Group Home Page
Date and Time
Debugger Console
Directory of hyperlinks
Documentation link from Tiki to doc.tiki.org (Help System)
Dynamic Content
Dynamic Variable
External Authentication
Featured links
File Gallery
Friendship Network (Community)
Gmap Google maps
i18n (Multilingual, l10n)
Image Gallery
Inter-User Messages
Kaltura video management
Live Support
Logs (system & action)
Look and Feel
Map with Mapserver
Meta Elements
Mobile Tiki and Voice Tiki
Performance Speed / Load
Platform independence (Linux-Apache, Windows/IIS, Mac, BSD)
Profile Manager
Search engine optimization
Search and Replace
Semantic links
Shadow Layers
Shopping cart
Social Networks
Spam protection (Anti-bot CATPCHA)
Tell a Friend, alert + Social Bookmarking
Theme CSS & Smarty
Tiki Manager
User Administration including registration and banning
User Files
User Menu
Web Services
Wiki History, page rename, etc
Wiki Syntax
Wiki structure (book and table of content)

Tiki Newsletter

Delivered fresh to your email inbox!
Newsletter subscribe icon
Don't miss major announcements and other news!
Contribute to Tiki