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

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

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

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:

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.

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

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

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

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.

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

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

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

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