History: Editorial Board Meeting 2007 06

            ^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!

{DIV(float=>right)}::{img src=http://zukakakina.com/show_image.php?id=37 width=200 link=http://doc.tiki.org/tiki-view_forum_thread.php?comments_parentId=321&topics_threshold=0&topics_offset=11&topics_sort_mode=commentDate_desc&topics_find=&forumId=1 }::{DIV}

!!Renovate home page

^See ((next 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!
~~#FF0000:Done!~~ (June 7. --Xavi, once Marc gave editors access to server - I could edit the css there)
~~#FF0000:"Mittwoch theme" remains a todo: [http://doc.tiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=348&comments_maxComments=1&comments_style=commentStyle_plain|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 [http://doc.tiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=348|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
~~#FF0000: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.

Options:
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__

#Most common keyword - use the most common keyword for that feature typed into google.
#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)).
#Shorter is better, Two words or less.  
#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 [http://doc.tiki.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=387|forum] )

---
!!Clarify role doc.two vs dev.tw.o

(you can wiki the motion, eh.)

^__Motion__ 
!!!tw.o: 
*feature tour!
*hype!
*tiki news!
*front desk (shoutbox)
*developer community / user pages
!!!doc.two
*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)
!!!dev.tw.o 
*Wishlist of what Tiki ''could'' or ''should'' do in the future (bugs, RFEs, etc), contributor user tracker
!!!themes.tw.o, 
*themes repository
*themes support
*theme-related tutorials, howtos, etc.
*extending Tiki visually such as by means of mods to .tpls, etc.
!!!workflow.tw.o
!!!mobile.tw.o
*specialized sites
!!!mods.two
*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?)
!!!i18n.tw.o
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.
---

!!feature_autolinks enabled

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


!!Organic growth

^__Motion__ 
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 [http://de.tiki.org/tikidocs/|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

---
!!Underline h2 and h3 headers in default css for Tikiwiki sites
^__Motion__ 
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 ~np~---~/np~ 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)'':
{CODE()}
H2 {
	...
	border-bottom: 1px dashed grey;
}
H3 {
	...
	border-bottom: 1px dashed lightgrey;
}
{CODE}

Line type options:
# Dashed
# Dotted

Line Colour
# black
# grey
# 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)
^__Motion__ 
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.

---
((Editorial Board Meeting 2007 07|Next meeting: July 2007))
This was a meeting of the ((editorial board)).