History: Editorial Board Meeting 2007 08
Source of version: 19 (current)
Copy to clipboard
^This is a meeting of the ((Editorial Board)) - it runs online from August 1 to August 30 2007. 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.^
__Remember:__
*please use a short clear statement as a motion (not a question) and place it in a box.
Last meeting: ((Editorial Board Meeting 2007 07))
Next meeting: ((Editorial Board Meeting 2007 09))
!Old Business
----
!!Naming conventions for features. (PASSED)
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 ((Article)).
#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.
__Passed__
^
__VOTE__
MLP:in favor (of whatever lets cap this!)
chibaguy: in favor (I also thought this was tabled for now.)
Xavi: in favor
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.
__note__ we gotta harmonize it across atleast two, doc and dev.
!!Clarify roles of tikiwiki sites (PASSED)
2009-09-20: This is now being maintained: ((tw:Where))
^__Motion__
!!!info.tw.o
*feature tour!
*hype!
*tiki news!
!!!tw.o:
*front desk (shoutbox)
*user pages
*prominent links to tiki sites
!!!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
!!!edu.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
^
__VOTE__
dthacker: in favor
mlp:in favor
chibaguy: in favor generally, but I don't see why info.tw.o is necessary. I think tikiwiki.org should be the place for news, feature tour, etc. There's a danger of too much info diffusion/fragmentation here, I think. If user pages and shoutbox, etc., shouldn't be at tw.o, then I think a good breakdown would be to move them to a community.tw.o site. In other words, the "front page" of Tiki is tw.o. As the top domain, it's what the visitor should see first. "info.*" to me has a secondary ring to it, which I don't think is appropriate for the main face of the site/program. Also, I think it'd be good to get more feedback on this. Any proposal should go to the dev (especially) and user mailing lists just in case anyone wants to speak up.
xavi: I agree with chibaguy.
ricks99: in favor. my thinking is that the top domain of tw.o could be redirected to info.tw.o (so users would not notice the difference ''and'' none of the content currently on tw.o would need to be moved. my thoughts are that the "content" on info.tw.o should be: short, sweet, and sexy -- a lot of flash and pizzaz. The "meat" is (already) on tw.o.
!!-Multilingual development (Decided?)
^__Motion:__ encourage documentation at fr.tiki.org?^
__VOTE__
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
chibaguy: agree with Xavi
-- Xavi's side wins but what does this mean wrt the motion?
!!Underline h2 and h3 headers in default css for Tikiwiki sites (PASSES)
^__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
^
__VOTE__
Xavi: I suggest the example in the box above: dashed grey for h2, dashed light-grey for h3. no line for h1.
chibaguy: In general I think these details are best considered in the context of the theme design as a whole, but I vote in favor of this motion, for a general guideline.
mlpvolt: in favor
---
!!Discontinue tracking documentation bugs with tracker8 (PASSES)
^__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.
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.
^
__Discussion__
dthacker says:
*All items in tracker 8 were added by me
*All items in the tracker were replaced by tags, which I think is a much more effective solution
*No new items have been added to this tracker for 9 months
*My goal was to make reporting doc errors a one-click process. Tags are not one-click, but they are one step. They update the content page and the status page simultaneously. I would love to put a big user-friendly button that would say "tag a problem on this page". Then we'd have the best of all possible worlds.
*While I appreciates Rick's desire for limited noise, it's important to remember noise can be a symptom of a problem that needs to be solved.
I continue to urge that we use the coffeeshop for page discussion and tags for page problems.
__VOTE__
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 completed, factual info only, should this be removed? I like having the tracker
!!New theme (PASSES)
^__Motion__
Use Mittwoch theme as the base theme for doc.tw.o.
(in case it needs vote).
^
__Overview__
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)
(Aug. 20) Thanks for the feedback. I spent a little time increasing margins for more white space, increasing line heights, etc. to improve readability. I still need to make the alternate images for IE6. My target was to have this theme ready to go when 1.9.8 is released, and figure that will be possible. (chibaguy)
__Vote__
Xavi: in favor.
mlpvolt: in favor
chibaguy: in favor
!!!-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)
!!- Reorder Table of Contents in .pdf from documentation (PASSES As AMended)
I mean all the subsections 5.x at ((All the Documentation)) and thus [files/Tiki19beta.odt] ([files/Tiki19beta.pdf])...
^__Motion 1__: reorder features in docs as alphabetical list.^
__VOTE__
(interpreted votes below wrt amended motion 2)
dthacker: agreed. propose alpha sort (am I the only persone that looks up a feature by name!!!?)
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.
chibaguy: disagree. I think we should follow the pattern of a book: the table of contents lists things in a meaninful hierarchy. Additionally, there could be an index page that lists alphabetically.
ricks99: disagree. a toc is ''not'' meant to be alphabetized -- it should reflect the actual structure of the document. Maybe you're looking for an index instead?
xavi: disagree. The problem might be in the motion summary. ''(The original idea-motion was "in a logical way, or as alphabetical list")''. So if motion was the one stated by mlpvolt, probably more people would have agreed at the first glance?
^__Motion 2__: reorder features in docs in a logical way (2n trial): sort the features into categories with a meaningful hierarchy, so people are aware of related/overlapping features. categories plus alphabetical is fine with me^
__VOTE__
Xavi: I agree.
MLP: agreed.
!!Add doc.tw.o as a custom search provider (PASSES)
^Motion: 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.
^
__VOTE__
MLP: agree
xavi: Agree
chiba and ricks have weighed in, i call this a pass - mlp.
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........
chibaguy: If this is just a new file to provide to browsers or whatever (I only skimmed over the opensearch.org docs), then I don't see any problem, if it improves access.
ricks99: it is a single XML file placed on the webserver, then a single __link...__ element added to __header.tpl__.. See [http://tikiwiki.org/tiki-view_blog_post.php?blogId=26&postId=321|my blog] for details.
---
((Editorial Board Meeting August 2007|Next meeting: August 2007))
This was a meeting of the ((editorial board)).
!New Business
!!Remove long copyright notice (PASSES)
^ __Motion:__ Remove the long version of the Copyright on printed page. For example, print this page. It's a waste of paper.
And change by something like this:
{img src=images/code.png}%%% {CODE()}
This is licensed under a Commons Attribution - ShareAlike License.
http://creativecommons.org/licenses/by-sa/2.5/
{CODE}
^
__VOTE__
mlpvolt: in favor (fait accompli?)
dthacker: in favor
xavi: in favor
((Editorial Board Meeting 2007 09|Next meeting: Sept 2007))