History: Editorial Board Meeting 2008 06

            ^__NEW CONTRIBUTORS: Please Read__
This is a meeting of the ((Editorial Board)) - it runs online from  June 1 to June 30. 
* Undecided motions are carried over to the next month. 
* Passing a motion requires 50% plus one of the __current members__. 
* Members who didn't participate in the last two meetings (either missed them or too new contributors to the ((Editorial Board))) are __not considered current__, and are __encouraged to keep contributing__ to the ((Editorial Board)) meetings in the following months.^ 

Last meeting: ((Editorial Board Meeting 2008 05)) | Next meeting: ((Editorial Board Meeting 2008 07))

* Members considered current for this meeting (7): chibaguy, dthacker, luci, marclaporte, mlpvolt, ricks99, xavi
+__Passing or defeating a motion will require 4 votes this month.__
* Contributors to this meeting, so far: marclaporte, xavi, ricks99, chibaguy

{MAKETOCBOX(float=>right)}{MAKETOCBOX}
!! Motions Passed Last Month
__none__!
Xavi: Please, participate at least leaving your name under as much motions as possible, and don't hide the content of any section, since it confused contributors in previous months.

!! Motions Defeated Last Month
__none__!
Xavi: Please, participate at least leaving your name under as much motions as possible, and don't hide the content of any section, since it confused contributors in previous months.


!# Motions Carried Over

!!# Documentation Page Formatting (kernel22's proposal) 
----
^__Motion:__ Use the example below as an "Information Sub-Section on all documentation pages.^
This really stems from 1.9 vs. 1.10.  I would like to propose an "Information" sub-section on each doc page relating to features/mods/etc which would contain sub-headings with related information like:

!!!-Example
~pp~!!!!Import forums
Blurb about what the feature does.

!!!!!Change Log
''Outlines significant changes in the appearance or behaviour of the feature...''

1.9.8.3 - Introduced.
1.10.0 - Added ability to import directly from another DB server.
1.10.1 - Able to now migrate phpBB3 forums.
1.11.0 - Removed SQL dump import option because seldom used.

!!!!!Known Issues
1.9.8.3 - Only works with mysql for sql dump import.

!!!!!Examples
blahblahblah....
~/pp~

!!!-__Discussion:  __

*You could make that "Starting Now we do it this way", but resources for feature archeology are usually not available. ((dthacker)) . Fully agree: ((xavi)) and ((marclaporte))
*mlpvolt: there ought to be a comprehensive list of templates at ((documentation templates)) - people should feel free to add and update those - we are not highly disciplined about using them at present - maybe there is a way we can prompt for this?  
*dthacker: More thoughts on this. We really need this feature, but I think it could be better maintained in a tracker, then using a template/plugin to bring it to the page   (as xavi says below).  I'm going to prototype that setup and bring it forward in a motion when it's done.  

__Vote__
In Favor:

Opposed:  dthacker, Xavi, marclaporte (but if "Starting Now we do it this way" statement is considered, I + marclaporte agree, and I guess, dthacker also), chibaguy

!!# Documentation page formatting (ricks99's proposal)
----
^__Motion__: Use for documentation page formatting something like the example shown [http://tikiwiki.org/tiki-index.php?page=UserPagericks99&pagenum=2|here] ^

__Discussion__

ricks99: [http://tikiwiki.org/tiki-index.php?page=UserPagericks99&pagenum=2|Here] was my proposal for redesigning doc pages from a while ago. I'm not 100% pleased with it, but I think it does a good job making it __easy__ to find the key information for a given feature (i.e., which Tiki version, required permissions, etc.). 

Xavi: as a General Idea, I like it, ricks99. But I'm scared of the work of reformating that part of every single page.... Moreover, shouldn't we use somehow the tracker info here in doc.tw.o that Marc Laporte created and many have been updating for all features?
*Which [http://doc.tiki.org/tiki-list_trackers.php|tracker] are you talking about? Are you suggesting using trackers in place of wiki pages for features? How would that work? (ricks99)
* I (xavi) mean creating a tracker to store all the metainformation  of the features, and retrieve whatever information for that feature using trackerlist plugin using filtervalue or similar params. Similar to how marclaporte has been using trackers on dev.tw.o to show the bugs related to that feature. We would show the metadata related to that feature... However, this is a bunch of work, which I can't do myself (I can't find enough time to even easier things...)
mlpvolt: again ((documentation templates)) is the process imo.
*dthacker: I want to tie this to a tracker too.   Now that we have staging, I can work up a prototype.  So opposed for now and watch for a new motion.
*dthacker: The problem with templates is that they are not dynamic in tiki, they are just skeletons.  This morning I saw a demo of templates on Mediawiki,  and they are dynamic across the wiki.  If you change the template the changes carry through to all wiki pages.  I think our dyamic content feature may allow for something like this so I'm going to experiment with that. 
*mlpvolt: overall, imo pagenames, linking and tagging is more important for the function of the docs than the similarity of individual pages. dynamic templates would be nice to have but let's keep the required boxes to fill to a minimum. I'm also concerned that staging&approval may  be too much to maintain. We might also differentiate between editors (who clean things up) and contributors (who can do anything they want - just contribute)   
* I agree that it looks like a good way to display the info, but am not sure about the method of getting the info, editing the pages, etc.

__Vote__
In Favor:

Opposed: xavi,  (it seems that we don't have enough human resources to accomplish this task, at least so far), dthacker, mlpvolt, chibaguy

!!# Screenshot Tagging/Captioning
----
^__Motion__: Tag or identify with a caption the version of Tiki each screenshot is from with the goal of the screenshots matching either the current release, or the current release candidate, whichever is more imminent.^ 
In the case of today, we would try and get all screenshots current as of 1.10.0 until we come up with a 1.10.1 down the road.  The Change Log proposed above will fill in the blanks.  Maybe also have a "-HEAD" version of the page that talks about and documents changes to an existing feature that are in development in the head branch.  When the time comes, those details can be easily incorporated into the current release page.  Obviously, if the feature doesn't exist yet, then instead of ahving a -HEAD version (for example Contributions-HEAD), then it'll just be the name of the feature (Contributions) and in the Change Log section we'd have "1.11.0 - Introduced".  I think we need to document new features that are being developed, but keep it separate from what is current so as to avoid confusion. %%% %%%

__Discussion:__
*All screenshots should have a standard caption including version.  We could add an "under development" tag as the equivalent to HEAD.(dthacker)
*I personally think that having a HEAD version of any doc page publicly available is dangerous. The HEAD version is __not__ easily available. Too many newbies are going to ask... ''Why is the doc page showing me 1.10, but I can only download 1.9.9??'' 
+ricks99
* in fact, they can indeed download 1.10 (or HEAD) at their own risk, from ((Download)) page (-> [http://dev.tiki.org/Download]). Mmmmmm, I like the idea: some people might like the idea of using 1.9.9 in themeantime but knowing that in the next version (1.10 in this case) this or that feature or enhancement is already coded and working... (specially if we as community take so long between releases of new stable branches...) (Xavi)
* One problem with a standard (static) caption is that as soon as a new Tiki version is released, all the doc captions are going to be (or appear to be) out of date. I mean if the screenshots were all labeled 1.9.11 now, what happens when 1.10 is released? People need to know what info is for what version, but hardcoding the version in the doc page should be done as little as possible, I think, since many or most descriptions will continue to be valid even as version numbers increase. Maybe the assumption should be (and described somewhere) that screenshots are accurate for the latest stable version unless otherwise indicated.
* ricks99: Could we use the ((pluginversions|Versions plugin)) for this, maybe?

__Vote__
In Favor: dthacker, xavi, ricks99 (via the ((pluginversions|Versions plugin)) )

Opposed: chibaguy (opposed to specific version numbers on screenshots unless the image is for a beta or old release)

!!# Using SourceForge for downloads
^__Motion__ : Keep all can we keep all file downloads on SourceForge instead on doc.tw.o server. Since the link to the latest pdf file in your doctwo server (http://doc.tiki.org/files/Tiki19beta.pdf) is written in several places (and I don't remember all of them, but I remember there were a bunch of places), I would suggest to do the following:
* remove the current Tiki19beta.pdf at the ftp server behind http://doc.tiki.org/files/
* create a folder called "Tiki19beta.pdf"
* add an index.html inside, with a redirect to
[http://sourceforge.net/project/showfiles.php?group_id=64258&package_id=68737&release_id=582492]
^
''(from Marc, rescued from a proposal sent months ago by him and xavi to ((Editorial Board Meeting)) page)''

__Discussion__:
Marc: 
* For instance :
http://doc.tiki.org/files/Tiki19beta.pdf

We could have a permanent redirect. Ex.: http://doc.tiki.org/printed to the exact location on SF (which could change over time)

It will reduce the load on my server and be counted towards our [http://sourceforge.net/project/stats/rank_history.php?group_id=64258&ugn=tikiwiki|stats] over there.

* Xavi:
+ {QUOTE()}I fully agree with you Marc. When I uploaded my first .odt & pdf, I didn't have access to upload files to tikiwiki area in sf.net, but I do right now. 

Months ago I uploaded files to tw area in sf.net, including the latest pdf from doc.tw.o:
[http://downloads.sourceforge.net/tikiwiki/Tiki19beta.pdf?modtime=1204906231&big_mirror=1]

And we could do something similar for the odt file? (or maybe it's not needed since less people download the source pdt file)...
{QUOTE}

__Vote__
In favor: xavi, ricks99, chibaguy

Opposed:

!!# Admin Settings for doc.tw.o 1.10
^ __Motion:__ Leave the settings where there has been no argument against, as they we iniatially set after the irc discussion on irc the day that Xavi upgraded doc.tw.o to 1.10^

We did set new doc.tw.o in a certain way. Some disagreement might arise (or not) on some of the proposals of new settings. Report below the changes that any admin on doc.tw.o made to the site, so that we can decide the best configuraqtion for the community according the maximum amount of points of view.    

!!! __details__
|| ::__Feature setting (on/off, enabled/disabled, etc.)__:: | ::__Comments__::
{DIV(bg=>yellow)}:: ''Admin (home) > General'' ::{DIV}
Log Mail in Tiki Logs: on
Contact user: dthacker | since dthacker is the "editor in chief", according to ((Editorial Board Meeting))

{DIV(bg=>yellow)}::''Admin (home) > Features''::{DIV}
feature_actionlog enabled
feature_freetags enabled | ricks99 thinks that freetags could be an extreemly powerful/useful method of navigation for new Tikiers.
wysiwyg left as "off" | to prevent mixing of wiki markup and html markup
feature_action_calendar enabled
feature_ajax disabled | It seems not to be needed at doc.tw.o, and it seems to be buggy accorging to Xavi (some pagination, at least, etc.)
feature_friends disabled | not needed, and maybe keep just one place for the social network within Tiki community. this place should not be doc.tw.o, imo (Xavi) but maybe tw.o. 
feature_fullscreen enabled
feature_morcego enabled
feature_redirect_on_error enabled
feature_webmail disabled | why was that enabled???
feature_mootools enabled
feature_shadowbox enabled
Use File Galleries for images inclusion ??? | Anybody can ensure that this is working already to dogfood it on doc.tw.o?

{DIV(bg=>yellow)}:: ''Admin (home) > Wiki''::{DIV}
Edit idle timeout:  60 (mlpvolt suggests a little longer than 30)
Create webhelp from structure:  on  
User's Page: on 
Show/hide heading icon displayed before the heading: on 
feature_wiki_discuss disabled | anonymous were posting to the forum, even if no local perms granted (Marc reported) 

{DIV(bg=>yellow)}::''Admin (home) > Login''::{DIV}
Protect against CSRF with a ticket: on
Displays user's contribution in the user information page: on
Reg users can change theme: disabled | If enabled, some (at least) registered users with "deafult theme" selected, seem to seing/using something like tikinew theme (even if Admin > Intertiki > import users preferences is disabled). Only when a user explicitly and manually selects mittwoch.css, he/she can use it when logged in to the site. Disabling the chance to change the theme style seems to fix it, so that I (xavi) propose to leave it like this, while "site default" user preference  doesn't work for all registeted users. 

{DIV(bg=>yellow)}::''Admin (home) > Forum''::{DIV}
feature_forums_search enabled | = "Search some forums by content (on "forum list")"
Search method when searching in content: Tiki search local to a forum: ??? | any idea what's that for?
Search method when searching in content: Non-Tiki search local to a forum: ??? | any idea what's that for?
forum_thread_user_settings_keep enabled | = "Configuration bar settings are kept for all forums during the user session:"
Default thread style: "threaded"

{DIV(bg=>yellow)}::''Admin (home) > Community''::{DIV}
feature_community_mouseover enabled

{DIV(bg=>yellow)}::''Admin (home) > Freetags'':: {DIV}
freetags_multilingual enabled
freetags_feature_3d enabled

{DIV(bg=>yellow)}::''Admin > mods'':: {DIV}
mods server set to: http://mods.tiki.org
installed lib-fpdf (1.4) ...
installed lib-fpdf_freefonts (1.1) ...
installed lib-fpdf_bitstreamvera (1.0) ...
html2pdf 1.1 (lib) | __couldn't be installed__ ; it reported: lib/html2pdf/classes/org/active-link/doc/DocHTML.php to lib/html2pdf/classes/org/active-link/doc/DocHTML.php impossible to copy

{DIV(bg=>yellow)}::''Admin (home) > i18n''::{DIV}
feature_multilingual_structures disabled | __please don't enable this as it currently causes very high load where single query can process more than 815000 MySQL rows!__
quantify_changes enabled

{DIV(bg=>yellow)}::''Admin > ((Action log))''::{DIV}
All actions except for viewing, downloading and loging in are logged | This way we'll be able to easily review what do users mostly do on doc.tw.o, etc. If after some time we don't use these data, and it takes too much resources (I don't think so), we can disable it again.

{DIV(bg=>yellow)}::''Admin > groups (Permissions granted)''::{DIV}
tiki_p_view_freetags added for anonymous
tiki_p_freetags_tag added for anonymous | Rick said it works fine on one site of him. However, there is no captcha anti-bot right now... (April 15th) %%% If we use freetags, can we remove ((Keywords))?
tiki_p_watch_structure added for registered | I (Xavi) though they might need it - wiki way methodology
tiki_p_rename added for registered | I (Xavi) though they might need it - wiki way methodology
tiki_p_view_actionlog | so that any user can review (or link) easily to what he/she did on doc.tw.o
tiki_p_wiki_view_source to anonymous | marclaporte : Please revert if you disagree. Xavi: ok with me

{DIV(bg=>yellow)}::''Admin (home) > Login (Users Defaults)''::{DIV}
user information: public
Show user's info on mouseover: enabled
users_prefs_mytiki_items enabled
users_prefs_mytiki_forum_topics enabled
users_prefs_mytiki_forum_replies enabled
||

__Discussion:__
*dthacker: These settings make sense to me.  I'd like to get the discuss feature re-enabled when possible
*chibaguy: Is web help working? It was broken the last time I tried it at a test site.
** xavi: no idea. Since I saw a new setting on Admin > wiki I thought (I wished, to be honest) that is was fixed. But I haven't tried. Just change it on the proposal, if you wish.
*ricks99: Can we disable the login module for anonymous visitors? There's already a login tab at the top of the pge.
** xavi: yes, I fully agree, as soon as the theme style is upgraded or patched to properly show the link to that "login" link on the horizontal menu for anonymous. I've just added the "logout" link for registered, which was missing (wasn't it there months/years ago??? what happenned to it?)  
* module last wiki page changes seems to have disappeared from doc.tw.o server. ¿?
** nope: it was called last_modif_pages . Reenabled (Xavi)

__Vote__
In Favor: dthacker, chibaguy, xavi, ricks99

Opposed:

!!# Use Blog to keep track of changes in doc.tw.o admin settings
^__Motion:__ Enable blog (or anything else) as on other tw.o sites where site admins could quickly put what change they done to site config. -- luci^

__Discussion__
*mlpvolt: why not just use the table created above, place it in ((doc.two settings)) edit to log changes and use the edit comment to explain why. 
**luci: err, what table ?
*mlpvolt: perhaps also the ((chief editor)) should approve (or at least be informed of) all settings changes. 
*ricks99: do end-users really care what features are enabled/changed on doc.tw.o? I can see value for editors and contributors, but for 90% of the visitors this seems like just additional noise.

__vote__
In favor: luci, xavi, mlpvolt, chibaguy

Opposed: ricks99 (unless the blog is visible only to actual contributors -- not anonymous)

!!# Defining groups, permissions and contributions
Ricks99 proposes a groups / permissions scheme as follows:

{FANCYTABLE(head=>User ~|~ Role ~|~ Ability)}
Anonymous ~|~ Reader ~|~ Read only %%% Tag (with CAPTCHA) %%% Rate
Any registered tw.o user ~|~ Contributor, minor ~|~ Edit pages %%% Tracker (log issues)
Doc contributor ~|~ Contributor, major ~|~ Comments
Editor ~|~ Contributor, major %%% Editor ~|~ Admin
{FANCYTABLE}
*Registered users __should__ be allowed to edit/update wiki pages, as needed.
*Doc contributors should use the pages' comments for editorial discussions of the page. This would:
##Eliminate the comment noise from "registered users" who use the comments for support questions.
##Replace the Author Coffeeshop forum.
*Editors are admins of the docs.


__Discussion__
*IMHO, this site differs from main tw.o -- end-users come here looking for specific information; not necessarily to contribute. (And in fact, all research shows that the overwhelming majority of visitors ''will not/do not'' contribute.) As such, 
*Anonymous users are simply ''looking'' for answers. Let them rate wiki pages (for quality) and add tags (a form of community-organization)
* xavi: I like your proposal a lot, Rick. I would suggest to clarify that registered users need also the perm to make minor changes, according to current behavior of translation feature, and once the related bug or misconfiguration is fixed. (See [http://dev.tiki.org/bug1697])
* xavi: I would suggest avoiding trackers for support tickets on doc.tw.o, but I know there is not much agreement on this issue on editorial board, and I would follow whatever we decide (afaik). Just comments ti wiki pages (either redirected to a forum through discuss or as comments on pages from a single ((All the Documentation)) structure that can be watched/monitored with a single click (to avoid dispersion of comments on pages that nobody was monitoring to answer).
* xavi:  if the issue with the msn bot spamming the forum through "discuss feature" is sorted out and fixed, then I would'nt mind keeping the discuss feature as it was before. 
* dthacker:  There are the tags that refer back to the status page (need a screenshot, refactor) and there are folksonomy tags.  Which tag would anonymous be able to work with?
** ricks99: The "tagging" I was referring to is the folksonomy tags... letting anonymous users "tag" wiki pages with keywords (which would/should replace the ((keywords)) pages. I'll confess that I'm not 100% sure I understood the discussion of ''tagging'' screenshots.
*** dthacker: I edited my question above for clarity
* dthacker:  Having used both, I think the tagging system works better than trackers. 
* dthacker:  The coffeeshop has been struggling for over two years.  Time to try something else
** ricks99: I aggree. Let's use comments to discuss a specific page. Making the comments visible only to major contributors will reduce the noise.
*mlpvolt: i like the description of groups and perms. "Editors" should more or less correspond to editorial board no?
**ricks99: Yes. IMHO "editors" == active editorial board members
*mlpvolt: disagree with using hidden comments to discuss changes to individual pages. That is way too micro. If something needs to be fixed, fix it. If a caveat needs to be applied, it should be visible to all readers. Inviting editorial discussion of individual changes invites stagnation i think, like wikipedia where 3/4 of all edits are to talk pages.
*mlpvolt, i guess o don't see less need for differentiation between registered and contributor. we can use it as a screen to help encourage self-training. Perms like revert, rename, categorize fit with contributor i think.
** ricks99: by default (via intertiki) any tw.o user is "registered" but in reality, only a ''very'' small number of these registered users are acutally contributors. I draw a distinct diffrence between the 90% "registered" users and the "5%" contributors.


__Vote__
In Favor: ricks99, xavi (ok with me), mlpvolt (ok except for using comments), chibaguy.

!# New Business
----
!!# Use H2 to describe the motion
----
^__Motion:__Put the motion text here enclose it in a text box^

__Discussion:__
*also need edit by section as soon as possible! :)

__Vote__
In Favor: mlpvolt (also tends to add show/hide), Xavi, ricks99, chibaguy

Opposed:

!!# New Editor in Chief
^__Motion:__ That candidates for editor in chief be nominated (or nominate themselves) by editing the page: ((Editor in Chief)), and that  the nomination process simply entails improving (on that page) the definition, responsibilities and priorities for someone in that role.^

__discussion__
Dave: {BOX()}Dave Thacker has been a great chief editor. He wants to step down gracefully and we are hard pressed to honorably refuse. :) 

Dave:''Over the last 3-4 months, I've found myself increasingly pulled to other parts of the tikiwiki project (Testing, UI issues, Packaging, Database neutrality, Hosting) and I think it's time to put more of my efforts into those areas.

This is to let the Docs Editorial Board know that they should pick a new
Editor in Chief next month, and that person should plan on taking over June'' {BOX}

* Xavi: I think we might not need that role as far as ((ebm)) keep working...

__Vote__
Opposed: luci (I also think (like Xavi) we don't need that role at all), chibaguy

!!# Proposed changes to doc.tw.o site
^__Motion:__ In addition to the doc.tw.o admin items included in prior motions, I would like to suggest some other structure changes to the site^

__Discussion__
#Remove the __Search by Page Name__ module. 
+We already have the Search bar in the header. Maybe (possibly) keep it for Registered users; but I think Anonymous visitors will become confused with 2 different search boxes
**luci: I'm not sure how efficient is the top search when you look for wiki page name
*** ricks99: Ok, i can see your point. But for the 90% of anonymous visitors, they're ''not'' searching by page name. They have no idea (nor should they care) what the page ''name'' is -- they just want content.
#The __Documentation__ menu is empty for Anonymous visitors.
+What's it for?
**luci: huh ? it's not empty here for me as Anonymous...
**ricks99: Actually, what's going on is... the module uses the "flip" parameter, but the FLIP icon is only visible when you hover over the menu title. I think this is bad usability -- ''if'' the module/menu is minimized, there's no way for user to know how to maximize it!
*** chibaguy: That's good feedback, Rick. I made the flip icons visible on hover to reduce visual clutter, which I think is a problem more with the rather bright blue shaded icon in 1.10 than with the smaller black line-drawing icon in 1.9. But if this is a usability problem, then I should look into always-on icons, and maybe have theme-specific icon images. (Sometimes the default 16x16 px is also too large, and Sylvieg pointed out there could be a performance hit for using CSS to resize them as I've been doing.)
#Remove the __To register__ module.
+Instead, let's add this information to the tiki-login.tpl template. Additionally it should be in the "become an author" section.
#Remove the __Last Forum Posts__ module
+I thought we were going to remove the forum functionality completely?
#Change the __Most Popular Tags__ module to a cloud, and show more than 10 tags. For example: ^{MODULE(module=freetags_most_popular,type=cloud,rows=30) /} ^

__Vote__
In Favor: ricks99, Xavi, chibaguy
 

!# New Motions
!!# New Motion 1
^__Motion:__ Describe it here in 1 or 2 paragraphs. Just describe, dont discuss or justify why you propose that.^

__Discussion__: Describe here why you propose that, pros and cons, etc. as much as needed.

__In Favor__: 

__Opposed__:

---

((Editorial Board Meeting 2008 07|Next meeting: July 2008))