History: Editorial Board Meeting 2007 04

            ^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 ([http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1059&show=view&offset=0&reloff=1&status=op&trackerId=5&sort_mode=f_41_desc&filterfield=26|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 [forum1|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: [http://www.google.com/coop/cse?cx=016171230611334810008%3Afh1rdtcvlre&hl=en|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?


((Editorial Board Meeting May 2007|Next meeting: May 2007))