History: Editorial Board Meeting 2007 10

Source of version: 18 (current)

^This is a meeting of the ((Editorial Board)) - it runs online from  October 1 to October 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 08)) (Due to the release of Tiki 1.9.8, there was no Editorial Board activity during September.)
Next meeting: ((Editorial Board Meeting 2007 11))


{MAKETOCBOX(float=>right)}{MAKETOCBOX}
!! Motions Passed Last Month

8 Motions Passed in ((Editorial Board Meeting 2007 08)).

!! Motions Defeated Last Month

!! Old Business

None. Yay!

!! New Business

!!! Adding Tiki 1.10 Documentation
A Tiki BRANCH-1-10 has been created, and more people will be using 1.10, really soon. There was some discussion earlier about how to organize information for different Tiki releases, wasn't there?

At the least, features that are new in 1.10 and existing things that have changed should be listed, and information added as much as possible. 
__Motion: new 1.10 features should be put into the current hierarchy__ 
In favor: 
mlpvolt, dthacker, Xavi, marclaporte

Motion: Update ((Manual of Style)) to require a notice on each feature's page as to what version it was introduced (eg. Introduced in 1.10) 

In favor:
mlpvolt, dthacker, Xavi, marclaporte


Comments: 
Xavi: Afaik, some pages for 1.10 specific features where already created (months ago): ((Action log)), ((contribution)), ... but many more are missing still, and your comment, Gary, is very appropriate. we need pages for the 1.10 new features to be created and added to structure. Plus request in tiki-devel list that coders please create pages with basic info for their new features or improvements...

Xavi: Related to previous comment by Gary, I (Xavi) suggest that we all take care of producing/updating the new page  ((Tikiwiki 1.10)), which is more users oriented (eye candy), in contrast to ((Changelog 1.10)), which is more "techies" oriented. I've started myself already: ((Tikiwiki 1.10)) ...
Btw, I've added this page to documentation structure under ((Introduction)) section...
Comments?

MLP: ((needed for 1.10)) is intended to be a ((Tag)) for this purpose.

MLP: I think trying to maintain different "versions" of documentation will be mostly futile and possibly counterproductive to producing ''any'' complete docs. I think that just adding a remark in a text box or something like that (dummies style) when version differences come up is adequate. For the most part the documentation should serve the "new" and "last" branch. 

dthacker: Are we deprecating any features?  How do we mark those?  I agree with MLP on the version support.  New and stable would be the terms I'd use there. 

__Motion: Declare that 1.8 branch is no longer supported and remove 1.8 specific info (where it exists) from current versions of pages.__

In favor:
MLP, dthacker, marclaporte with Xavi's amendment

Disagree:
Xavi

Comments: 
Xavi: I agree with removing 1.8 info everywhere except at pages related to ((Upgrade)) process from 1.8.x pages. Maybe you were already thinking so in the motion, but since it was not clearly stated, and today it's the last day of October, I'm not "in favor" until this point is clear (upgrade-lazy users/admins should still find information on how to upgrade from 1.8.x version through documentation).


!!! New categories for 1.10 ((Tikiwiki 1.10))
^__Motion__:
Add two new categoies for 1.10 to doc.tw.o: 
* "1.10.0 ready", and 
* "1.10.0 NOT ready"
^

In favour: Xavi
Opposed: mlpvolt, dthacker

Xavi: I don't suggest to add those tags inside the page text since they would be annoying for printing once the page is 1.10.0 ready...
This way, we can have an easy way to list pages which are ready for 1.10..., without any extra "meta-information" to be shown on each updated page (which new users wouldn't need to see at all).

MLP: I'm against any use of categoies for 1.10 other than for permission control. In discussions with Dave we abandoned the category system  for content purposes because it was just another thing to maintain (and never was). Tagging and backlinks is better because it fits within the natural workflow of editing pages. 

Tagging pages with ((needed for 1.10)) works better because it is added when needed and removed when completed, and works with the backlinks dashboard method. By default there is nothing extra to maintain.

Xavi: Ok, I understand, again. However, I see the problem that nowadays, none of us know (nor will ever know, with the Tag system as it is) when a page is 1.10.0 ready... I leave this motion as it is (to let others agree or disagree - I guess they'll disagree ;-), and I set another motion (to see whether it makes a compromise good enough with ((manual of style)), etc.

dthacker:  IMO, backlinks and tagging are working as intended and should be relied on instead of categories. Is there another technical solution to the issue of printing tags?

marclaporte: yes, let's find a technical solution to this. I think there is a {noprint} syntax. Let's see if possible to have the same for our tags.

!!! Add a Tag "1.10.0 ready"
__Motion: add a new ((Tag)) called ((1.10.0 ready)) (or similar) so that we all know when a page that needed to be updated to support new features or behaviour in 1.10 Branch (at least, 1.10.0) is updated already. This way, other documenters would know that somebody considered that page to be quite ready, and effort can be put on other pages, rather than re-checking by everybody all pages to see whether they are 1.10 ready or not).__

In favour: Xavi

dthacker: Isn't a complete page supposed to be clear of tags?  Pondering.....
Xavi: Well, we could always keep the Tag "1.10.0 ready" (to follow this example), and when new features are added to >1.10.0., if the Tag is not updated, it means that the documentation could be not in sync. with features/behaviour (or not, if no change has been made to that feature in that release number increase....). We should sooner or later discuss and decide upon this issue ...

!!! Upgrade doc.tw.o to 1.10 branch?
After some talk between tiki users (Marc and Xavi) while the [http://www.wikisym.org|Wikisym07] days in Montreal (:smile:), some improvements to structures are underway, in order to make it easier to transfer doc.tw.o/Documentation content to OpenOffice .odt files.

Sylvie said that it was a shame that doc.tw.o was not upgraded to 1.10 (so that it's easy to dogfood and test those changes directly on doc.tw.o), nowadays that 1.10 has been created as a new branch and ready to start becoming even more stable than before... 

The thing is that neither Marc or Xavi can take care of upgrading doc.tw.o to 1.10 (and maintaining) right now... If anybody from the editorial board can offer some help on that, it would be lovely to dogfood 1.10 for documentation also... If anybody interested, please contact Marc.

(Maybe I can help with that. I'd like to get sites onto 1.10 early. I need to do a lot of theme updating (to 1.10 compatibility), though, including the current one for this site.)

In favour (if somebody can take care of that): Xavi, mlpvolt, chibaguy, marclaporte

!!! Where to keep/upload latest pdf files
See 
[http://doc.tiki.org/tiki-view_forum_thread.php?comments_parentId=535&topics_threshold=0&topics_offset=1&topics_sort_mode=commentDate_desc&topics_find=&forumId=1|forum post] about it (I'm wondering where is the best place for such general questions, since I feel as if very few documenters are watching changes of editorial board meetings... nor even previously active editorial board members... 

!!! Keeping one single Editorial board "todo" page
I have the impression that too few documenters are watching this editorial board meeting pages. Even people that were active some months, I guess that it's not easy for them to comment/give their opinions on new issues because they are not "by default" watching the new editorial board meeting pages month by month. To ease this process a bit, I suggest to make a slight change in the process of creating new pages for EB meetings:
^
__Motion__:
There is a single EB meeting page, which users can subscribe to (only needed once). when a month is over, the decided content (passed or rejected) is moved to a new "minutes" page with the information, and undecided issues are kept in the same "((Editorial Board Meeting 2007 11))" page.
^

In favour: Xavi, chibaguy, dthacker
Opposed: mlpvolt, marclaporte

MLP: We used to do this "way back when" and ditched it - the editing required to maintain the meeting page was way more work that way than this way, and plus you didn't have a proper record of minutes. A one page system will become disfunctional, i can almost guarantee it. 

Xavi: I've been using the one single page of "todo" for meetings for ngo (where I used to coordinate minutes), and it was further easier to me (and to let others in the ngo know where to look for last things remaining to be discussed or done...). Oh well, maybe it's not that important (either way is good or bad enough ;-). If people cannot keep up to date, then it doesn't matter the way we use?
In my case, I'm a bit scared of tracking full changes of all pages... (on most tiki sites I admin...). Email box getting quite full now and then... (full not for the size of the inbox of other email boxes, full for my ability to read everything which needs to be read and processed in a "decent" time frame...)

chibaguy: I wouldn't mind giving the single-page method a try. It seems to me the carrying over of old business to the new month gets kind of messy, so if unresolved things just stay in their original place until dealt with, there won't be that problem. Also, lately some months have had no discussion. I made the pages for them just for consistency but with a single page rather than monthly pages, this wouldn't be an issue.

dthacker: I'd like to try single page again. 

marclaporte: I'd prefer different pages and dogfood the new "Watch category" feature to get around problem mentioned above. Something like this would be great as well: http://twiki.org/cgi-bin/view/Plugins/ActionTrackerPlugin

__Motion__: All EB members should be subscribed to watch all documentation pages. This will take care of the meeting notification problem and will genenerally strengthen the EB community.

opposed: dthacker, Xavi


mlpvolt: i've been on full changes for the last six months or so, haven't found it difficult, it is beneficial in many ways. 

dthacker: this can be like drinking from the firehose during active doc cycles, and I'd like it to be voluntary.
Xavi: I agree with dthacker

marclaporte: as above, watch category would be better.



!!! Features page
I (Xavi) propose to change ((Features)) page so that you don't have to click 8 times to see the full list of features... (nowadays using "... page ..." tags to separate it in 8 sections). Options I see:
* Option 1: Show all sections in one page, and add a "maketocbox" (or handmade anchors forward and backward) to ease the browsing within the long page.
* Option 2: Use VERSIONS plugin, so that page is still divided in 8 sections (or whatever number), but you can needed for 1.10 to any section with one click
* Option 3: Leave it as it is (using "... page ..." tags )

Opinions?
Users whose preferred option is number 1: Xavi, mlpvolt, chibaguy, dthacker

MLP: I like having a full list as the main, and then people can make redundant sub lists for types of features (CRM features, Admin features, Wiki features etc. )

---
((Editorial Board Meeting 2007 11|Next meeting: November 2007))

---
Btw, some errors: 
(1) search and replace doesn't work for me with IE7.0 (just tried from the computer in my new job... I wish I could install full linux OS...). anyway, it was a good excuse to try doc.tw.o with IE7 for production... (nice job, Gary!)

(2) ~ np ~ tags don't work if calling ... page ... 
Example:
{img src="img/wiki_up/doc.tw.o-Editorial_Board_Meeting_October_2007_1193644731359.jpg" alt="image_of_example" }