This is a meeting of the Editorial Board - it runs online from April 1 to April 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 03
Next meeting: Editorial Board Meeting 2007 06

Old Business:

Sticky Login

Motion Whereas -it is annoying to have to traverse from the home page back to where i was when i decided to login, we should change the site config and layout such that:

a) login box is in the top bar (like two)

b) logging in does not return the editor to the homepage.


DT: I see as low priority, but if you can get someone to do the work.....
MLP: I will do it or have it done if it is approved.
DT: In favor, but see change proposal below
Xavi: In favor. It's working right now on 1.9.x, isn't it? (it's working for me on other sites, at least). On 1.10 there is bug somewhere (see bug report)

In Favor: dthacker,xavi, chibaguy, marclaporte


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!

In Favor: dthacker,xavi, chibaguy, marclaporte

Upgrade to tikiwiki 1.10?

Whereas: 1.10 allows - edit by section, redirect, advances in admin and groups, freetagging, etc. Motion: The EB recommends moving on to 1.10


DT: Marc hosts the site, IMO, it's up to him when the upgrade gets done.
MLP: Ok I will ask marc.
DT: Marc has moved us to 1.9.7. not sure when 1.10 will release. I would like to move to 1.10
if possible
Xavi: redirect is available in 1.9.x as plugin. "edit by section" available in current 1.10? (I couldn't find it days ago 😑 ). I don't mind moving, if some people can take care of bug reporting and fixing (not my case in the following three weeks, at least - until the beginning of may)
chibaguy: If 1.10 is ready for a production site, the new features would be good, but the top priority should be dependability.

ML: I can take care of upgrades in 1.9.x but not in 1.10.x If someone is willing to update, that's fine. It seems to me that the feature-set of BRANCH-1-9 should be sufficient to make excellent documentation.

In Favor: DT, MLP

Theme project.

Motion: Mike will be tasked to work with Marc and (Gary?) to work on a new theme for doct.two - on a test site first.


DT: There are several themes available on themes.tw.o? Can't we just make them selectable?
MLP: Selectable is ok. Maybe just a change to top_bar (see above). Perhaps having a demo on a test site would be a good thing to do before putting ths to a motion
Xavi: Chose a more colourful theme! And add unedrlines to header2, 3, and 4, at least (either dotted or dashed). For instance:

+ border-bottom: 1px dashed grey;


Tabled: So as to put the theme before the motion.

DT: See additional proposal in New Business
chibaguy: I'd be happy to help on a specific theme or adaptation for the site. If people have ideas or models to emulate, it could be worked out.

Redo modules and menus.


DT: Modules and menus were just re-organized by ricks99. Please post a specific proposal to the dev list.
MLP: see above. 😊
DT: I think this is better stated in the motions in new business. See my comments there.
Xavi: Opps, I made a change directly on the menu (assumed working the wiki way to fix what I thought it was a mistake). See Author coffeshop post about it.

Opposed: dthacker
MLP: Withdrawn

Articles expire

Motion: Set all articles to expire after 30 days.


no more than the last three on the main page.

DT: Or expire after 30 days?
MLP: So amended.
Xavi: expiring is ok for me.

In Favor: dthacker,xavi, MLP

Simple Rules for the Editorial Board


Moved that the following heading be sufficient rules for an EB meeting.

This is a meeting of the Editorial Board - it runs online from March 1 to March 31st. 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.


in favor: mlpvolt, dthacker,xavi

MLP: this should be amended so that it is generic, anyway the idea is that the agenda is rolling and the page refreshed once a month: creating the next month;s agenda is just copying last months and dropping the items that have been decided or withdrawn.

note: an editorial board content template exists.

New Business

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

Discontinue Both Columns

Motion: Discontinue both left and right columns. Use phplayers across the top. Move modules currently displayed on left column to a dynamic wiki page.


DT: Again, a proposal from franck. This is a more radical approach. As an author I appreciate seeing last changes, etc. but do our docs consumers care? Perhaps not.
Xavi: not needed for me. 1 column is ok. And maybe, enable the show/hide column for users? (on the right only column, to avoid issues with IExplorer browsers...
chibaguy: I think having 1 side column is a good thing. But it might be good to experiment with having no side columns on actual doc pages (identical but no-side-columns theme would be used for these pages, assigned via category).
ricks99: non-contributors don't care about every little change, the forum, etc. But they do expect navigational aids.

Opposed: Xavi, MLP, sylvieg, chibaguy, ricks99

Create test doc site

Motion: Set up a test doc site, to experiment with radical simplicity in tagging vs. categories, search engine performance, alternative structures


DT: Sandboxes are good. That said, the EB needs to keep an 80/20 rule in place so work is still done on current site. I can host this site
MLP: i think the value of such a site is for customization / themes and templates work, and for "radical" experiments with the content configuration. so ok with me - but it is not a place for "draft" content. We can do that here.
DT: Agreed, this is not for draft content. It's a doc mad scientist lab.

Xavi: not needed, I think.
chibaguy: I don't think it's necessary to have a dedicated site for this, which would add to admin overhead and so on. I assume everyone involved has web space somewhere for experimenting. People can post links or screenshots to show ideas.

ricks99: not needed. if something is not ready for prime-time, just change the category/tag/permission to hide it from casual visitors

Opposed: xavi, sylvieg, chibaguy, ricks99
In favor: MLP

Replace Tiki Search with Google cse

Suggested by ricks99. Replace the current tiki search with a google search


DT: Pros. ricks99 says his users love it. We always want to improve our product. Cons: We're no longer "eating our own dogfood". We'll have little incentive to help improve Tiki search. I'm undecided. Waiting for other's input.
Xavi: until there is not "out-of-the-box" boolean search on tiki, I would suggest enabling google search (or whatever else). Tiki's search engine is frustrating, unluckily... Update: Ok, Ok, "eat-our-own-dogfood"... (and vote for a search feature that uses tiki's permission system)
MLP: Question - how often is google going to crawl the site - its not good unless it is very frequent - though i have heard of the local search being out of data as well. We should figure from the dev community what the best practice is and use it.
ricks99: Here is an even better example of an improved Tiki search. If someone adds the JS plugin here, we could embed this directly into a wiki page.
chibaguy: I agree it's appealing to have a more effective search, but in the end I have to go along with sylvieg. It sends a really bad message if the official Tiki support site is using outside tools in place of its own.

Opposed: sylvieg (eat our own dog food until we are sick and decide to do something else - lucene is a good alternative too - google is not open source - the toc should be enough in a doc), chibaguy, xavi, marclaporte (I use a lot of Tiki's in an Intranet setting, so I'd rather we have something which we can reproduce)

In favor: ricks99 (while i agree with the "eat your own dogfood" mentality, let's not reinvent the wheel. if there's a better solution, why not use it? let's not forget the #1 mission of docs.tw.o — to help users find answers to their questions. anything that furthers that mission is, imho, a good thing).

Introducing another search will not follow the perms - so it is very dangerous to show a better solution- What about to use the google module on the site?


Next meeting: May 2007