History: Editorial Board Meeting 2007 07
Source of version: 31 (current)
Copy to clipboard
! Editorial Board Meeting July 2007
^This is a meeting of the ((Editorial Board)) - it runs online from July 1 to July 31. 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 06))
Next meeting: ((Editorial Board Meeting 2007 08))
! Old Business:
!!-Naming conventions for features. (Forwarded)
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.
^__Motion: Naming Rules for Features__
It was agreed to avoid hard rules for now
#Natural Language - prefer most natural usage (no hard rules)
#Prefer 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))
#Renaming an existing feature requires an EB vote, and notice to dev list.
__Passes?__
^
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.
!!-Current features for renaming (Approved)
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.
---
!!-Batch creation from structures (Failed)
^__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.
__Failed__ - improving UI is chosen as preferred option.
^
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] ) 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
!!-Clarify roles of tikiwiki sites (forwarded to August)
(you can wiki the motion, eh.)
^__Motion__
!!!info.tw.o
*feature tour!
*hype!
*tiki news!
!!!tw.o:
*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
^
(in favor: dthacker)
!!-Multilingual development (forwarded)
^__Motion:__ encourage documentation at 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.
dthacker: agree with Xavi
!!-feature_autolinks enabled (Approved)
ML: it seems like a good feature. Anyone object? If so, we can turn off,
Xavi: ok to keep it.
dthacker: keep it.
!!-Organic growth using ((Keywords)) (Approved)
^__Motion__
Create at least one 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
Keyword pages must link to all sub pages under that and vice versa, Backlinks is used (either automatically with the ((Backlinks Plugin)) or manually by checking.
^
---
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.
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
---
!!-Underline h2 and h3 headers in default css for Tikiwiki sites (forwarded)
^__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.
---
!!-Documenting doc bugs with tracker8 (forwarded)
^__Motion__
Discontinue [tracker8] here at doc.tw.o. Use ((Documentation Status)) instead, with ((author coffeeshop)) as backup. 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).
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.
! New Business:
!!-New theme (forwarded)
!!! Latest news
I uploaded the Mittwoch theme files to this site. Please have a look and make suggestions. Use the URL [http://doc.tiki.org/tiki-switch_theme.php?theme=mittwoch.css] to use Mittwoch. So far I haven't been able to do this while logged in. Maybe there is a conflict with Intertiki. When I log in, I get switched back to the site's default theme.
The left and main column need a wider margin between, I think. And maybe the line-height should be increased a little. There is also a glitch with the module titles not being the right size.
About the colors, I don't know if the color switching will be possible here because Intertiki might insist on overriding the choice. But probably the switching isn't really necessary. We can use the switching while choosing which color to use here. So far I only tested in Opera 9.2. The switching was a little flakey, with the preference not always being remembered, and sometimes a flash of blue at the beginning of the display (maybe this is a feature, not a bug. ;-) ).
Congrats. Gary. :-). I agree on you comments of needed changes, plus I would suggest:
* make a clear difference in the box to create a new page in structure navigation bar (bakcgroup of the box for that field is too similar to background of the structure navigation bar surrounding it). Same for fields of login box, search wiki pages, etc. (confirmed on all browsers Firefox, Seabird, Konqueror, and IE 6 on GNU/Linux).
* Options labels in drop down boxes as shown cut by the lower part, for me. Using Firefox 2.0.0.4. Less cut with Mmozilla Seabird, and ok under Konqueror and IE6 under GNU/Linux.
* Under Internet Explorer 6 (on a GNU/Linux platform) I see grey background for png images: text logo on header, icons on the "learn" and "write" columnes, etc. It's only me? (Xavi)
!!! Older discussion
There are a few layout quirks to finish up, and some style issues need to be decided.
# Which color should be used for doc.tw.o?
** Proposing Blue: Xavi
# If none of these colors is right, please make suggestions.
** Xavi: They are right (and very nice, thanks Gary :-). Looking at drupal.org and joomla.org, for instance, their sites tend to be more colourful. These Mittwoch themes are by far much better than many of previous styles in Tikiwiki (my personal opinion, of course - I love white background with colourful details here and there...), and I just wanted to suggest that for further improvements, to include some more color on top of white background (hec.css is quite in that way..., even if simpler compared to Mittwoch).
# In some places (dropdown select) there may be contrast problems (i.e., not enough contrast), so those can be changed. I haven't checked on a variety of displays.
# Is the small plus sign sufficient to indicate the page edit, etc., tools dropdown?
** Xavi: I don't think so, if we think in new users, newbies in computer science, ... (usability). I would suggest a much bigger icon, or just a word like "tools" or similar (like in andreas09.css). However, usability geeks frequently complain about those hidden things (when thinking in potential new users with low skills of computer usage - remember talk from Alain in ((tw:TikiFest198)) ).
# Or would people prefer the standard Tiki wiki page tools layout (for edit, print, etc.)?
** Xavi: If this is going to be a standard theme for doc.tw.o only, then I would vote for this option (most tiki sites have standard layout for tools). If Mittwoch can be released as LGPl, then I would HIGLY encourage making this nice new theme as the default for 1.10 sites, and thus, also for doc.tw.o.
# The horizontal navbar can be either static links or a PHP Layers menu, so this should be decided.
# Styling is also done for a PHP Layers menu in the side column so that's an option.
# The Site Identity header is done, to match the current one at doc.tw.o.
# Other suggestions/changes/etc.?
** Underline (dashed in greys) h2 and h3 headers in default css's for new tikiwiki sites
** make some kind of "A+" "A-" "Reset" sings on tikiwiki site identity header (a new option) so that users can increase or decrease in a click the default size of text in the site. (similar to many more usable sites: example: [http://joomla.org] header...
# ??
-- Gary/chibaguy
Thanks heaps Gary for your nice (and hard) work! (Xavi)
!!- Site config (tabled)
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)
!!- Table of Contents in .pdf from documentation (forwarded)
^Motion: reorder features in docs as alphabetical list.^
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.
!!- Modules Documentation Project (discussion item)
^
__Motion (suggestion)__ (from irc chat on July 6th):
In a first phase, suggest to anybody willing to invest some time on doc.tw.o to include info on the Modules pages , of adding pages & info for the missing plugins, .... On pages with ((stub)) that you consider that they are important enough in a daily Tiki usage on common sites.
~~red:''(Read full discussion and explanation below)''~~
^
{QUOTE()}
[[08:54] <xavi> btw, checkout this message I posted this morning to your work on Games pages: http://doc.tiki.org/tiki-view_forum_thread.php?topics_offset=1&forumId=1&comments_parentId=438
[[08:55] <xavi> (sorry again, for my part in the confusion, I didn't note that links in structured pages where to your out-of-structure previous pages in plural...)
[[08:57] <xavi> I can do the merge myself, if you preffer (I'm very concerned when very skilled people have to invest their time in things like other not so skilled people in tiki issues (like me) can do ...)
(...)
[[09:20] <chibaguy> xavi, I don't know what to do about the page names. I strongly feel natural language should be the test. If people generally refer to something in plural form, if it's listed as a Tiki feature in plural form, etc., then I think it's page name should also be plural. But there is also a "make everything singular" trend going on, so how to resolve that?
[[09:20] <xavi> and chibaguy: I fully agree... I didn't rename pages myself this morning because I was afraid if stopping by too much on obstacles not "compulsory" (imho) for my turtle race... but as I fully agree on your opinion (it's the same I though t this morning), I'll do it right now... (combining wiki pages, and renaming or including in toc)
[[09:21] <xavi> chibaguy: neither do i. I preffer natural speaking too. But I'm facing the left overs of the page rename to singular in the toc.... and turtle is attempting to avoid as much obstacles as possible...
[[09:22] <xavi> (to avoid confusion: I take care of the Game names confusion myself, no more, no less, right now)
[[09:22] <chibaguy> I understand the appeal of a simple, singular keyword, but would like to restrict that form to where it is natural, as in a glossary or index.
[[09:23] <chibaguy> OK. I was afraid to mess with names because of upsetting the turtle. But this needs to be resolved somehow.
[[09:30] <xavi> I agree
[[09:32] <chibaguy> I could go down the hierarchy and rename as I think, but is that too pushy?
[[09:35] <xavi> __Suggestion: leave that energy&time for a later stage phase... I would first suggest to anybody willing to invest some time on doc.tw.o to include info on the Modules pages , of adding pages & info for the missing plugins, .... But of course, do whatever you consider the best__
[[09:35] <xavi> (the stub pages...)
[[09:36] <xavi> (stub pages of features or thigns we consider quite commonly used, etc.)
[[09:36] <chibaguy> In other words, make the page content complete first of all.
[[09:38] <xavi> my suggestion is not completely complete, but the main & important things, yes... (that is bveing my criteria, aprox., to decide in which obstacles to invest some time, etc. (not all obstacles at this frist stage). I think whenever we make a pdf (or webhelp) ready for all users, keeping the stub, help, urgent keyboards content, more users will come to help...
[[09:38] <xavi> (I hope so (:smile:) )
[[09:40] <xavi> whenever we consider Tiki19beta.pdf (or should we call it Tiki19alpha.pdf then?) is decent enough as a rough companion of new users, then we can focus on the secind stage (reordering, if needed, compelteness of the least used features, updating previous versions screenshots, etc.), but hopefulym, with a wider user base contributing to doc.tw.o....
{QUOTE}
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.
!!- Add doc.tw.o as a custom search provider (forwarded)
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 [http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document|OpenSearch] for details.
Just an idea........
---
((Editorial Board Meeting 2007 08|Next meeting: August 2007))
This was a meeting of the ((editorial board)).