History: Editorial Board Meeting 2008 10

            !Editorial Board Meeting 2008 10

^__NEW CONTRIBUTORS: Please Read__
This is a meeting of the ((Editorial Board)) - it runs online from  (month) 1 to  (month) 28/29/30/31. 
* 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.
^
* Members considered current for this meeting (6): chibaguy, dthacker, luci, marclaporte, ricks99, xavi
+__Passing or defeating a motion will require 4 votes this month.__
* Contributors to this meeting: chibaguy, luci, mlpvolt (MLP), ricks99, xavi (+ add your name if you vote for anything) 

Last meeting: ((Editorial Board Meeting 2008 08)) (no meeting on september'08) | Next meeting: ((Editorial Board Meeting 2009 05))

{MAKETOCBOX(float=>right)}{MAKETOCBOX}
!! Motions Passed Last Month
* Motion 1: Dogfood versions plugin

!! Motions Defeated Last Month
* none

!# Motions Carried Over

!!# 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 having 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 the meantime 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)) ) mlp (as a ((guideline)), not a ((rule)).)

Opposed: chibaguy (opposed to specific version numbers on screenshots unless the image is for a beta or old release), luci (can be described under the image)


!!# New Chief Editor
^__Motion:__ That candidates for editor in chief be nominated (or nominate themselves) by editing the page: ((Chief Editor)), 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...
* MLP: Strongly in favor of having a EiC, only because although multiple people have admin level access, one person should make or be aware of global changes to configuration. In this way EiC is not so much about editorial rules but site admin. Agree that EB handles editorial rule decisions well enough. Having one person responsible rather than many however is important is something went wrong technically. 
* Xavi: I understand what you mean, MLP. However, I wonder if we can keep ruling doc.tw.o without that role on a single person but on the whole ((Editorial Board)) (I wish so, and we have been doing fair enough - even if not perfect - for a year or so, at least. some times me, sometimes Marc or others, taking the lead and creating the new Editorial Board Meeting pages and revising motions passed-defeated-and carried over, stoping spam, ... I'd love to see (prove) that under some circumstances (?) we are able to rule headless (understanding head as a single person) but group-head-in-chief... Wikis allow ((wp:Anarchism)) in a new way ("Anarchism reloaded"?), and why not using this power ourselves?
* MatWho: I know I am a bit of a "new kid on the block" but I would not mind volunteering for the EiC role. I do feel the documentation for TikiWiki is very important to the project. I would like to contribute to this great project and try and encourage others to do the same. I promise you can sack me any time without hurting my feelings. :)
* Xavi: yes, you can vote (to express your opinion). However, your vote will not be taken into account if not consensus is reached, until you are a "current member" in two months if you keep contributing to ((ebm)) (see above).

Before we vote, please let us review/revise ((Chief Editor)) (nb: MLP cannot reliably spell chief :) - gak the page DNE untill now. 

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

In Favor:  MatWho

Abstain: MLP (defers to the majority view), ricks99 (anyone but me!)

Xavi: yes, still opposed, at least for the time being and according to our natural evolution in the last year 2007-2008


!!# Allow Tiki community members to be added to DocContributors
^__Motion:__ Allow registered users to be added to ((DocContributors)), after they confirm they have joined the TikiWiki Community Group. See [http://tikiwiki.org/tracker8] ^

__Discussion__: This way there is a natural way to stop new users to just stop by and throw their questions as  comments to pages. And doesn't require a process that some of us have to review and validate user requests...
  
MLP: doesn't understand what this is about. :)
Xavi: See ((DocContributors)) (from last ((ebm)) )
ricks99: The fact of the matter is, 99% of the TW.o users are ''not'' going to contribute to the docs. I am opposed making it too easy for anyone to add anything to any page, because we will end up with folks using the doc site for support. The folks who want to make a 'real' doc contribution will seek out the correct process to become a doc editor.


__In Favor__: Xavi, chibaguy

__Opposed__: ricks99 (if i understand correctly....)


!!# Change logo in doc.tw.o to something similar to dev.tw.o


^__Motion:__ Change logo in doc.tw.o to something similar to dev.tw.o. For instance, something like: 
{img src="img/wiki_up/tikilogo_doctwo_shadow.png" }^

__Discussion__: 
Xavi: 
* I know png backgrounds face problems on IE6, etc. That's why I suggest to use on doc.tw.o the logo with the same background of the mittwoch header (blue in this example, and with the small text at the bottom in white, since it gives better contrast in all background colors of mittwoch than black, imo): 
+ ::{img src=http://tikiwiki.org/show_image.php?id=345 link="http://tikiwiki.org/tiki-browse_image.php?galleryId=27&sort_mode=created_desc&imageId=345&scalesize=o"}::
+ This is how it could look like, even on IE6
+ ::{img src="img/wiki_up/tikilogo_doctwo_proposal_mittwoch_blue.png" }::

* I even would suggest to allow using only one color on doc.tw.o header, and use the other colors for other x.tw.o sites, keeping a similar logo as these logo set. However, I know this motion/suggestion doesn't concern only to the doc.tw.o squad but all people in devel-list, etc. Anyway, opinions?
** Otherwise, then I would suggest creating one doc.tw.o for each of the background colors offered in doc.tw.o header, and "somehow" (Gary?) use each logo color depending on the color the user clicked in. Is it feasible? needed?

MLPvolt: I would vote for the white header - for continuity reasons, although i have just seen the new design by patrick for tw.o (which is awesome) - and we coulld just wait and adopt a variation of that theme. The blue version is ok but perhaps without the reflections - they don't work well on the blue background IMO.

MatWho: If you go ahead and use this image with the blue background, please can you improve it just a little bit. I agree with MLPvolt, the shadows are rather confusing, we have got shadows on shadows and they are all going in different directions! I would be very willing to help do this. Just let me have a GIMP/Photoshop file.
Xavi: here it is: {img src="http://tikiwiki.org/tiki-download_file.php?fileId=48&thumbnail=y" alt="tikilogo_doctwo_white.svg (16.13 Kb)" link="http://tikiwiki.org/tiki-download_file.php?fileId=48"} (svg. editable with Inkscape, for instance, and importable with Gimp, also, even if you'd better edit it with inkscape type of programs: vectorial images, etc.)

Klang: I am too new to express a view on logos - but may I observe that 'tw.o' is jargon, at least to some extent -  a diversion for the user (I wonder what that means? is it a pun on 'two'? why? is there a top level domain '.o' that I don't know about? is this really the main docs site?). So it's good to keep a prominent reference to the real site name/purpose. That's simply an observation from someone who just arrived - I'll probably feel differently next week, when I've got used to it... But then someone else new will be arriving.
Xavi: All subsites from the tw.o domain use to have the tw.o at the end (=__t__iki__w__iki.__o__rg in short)
klang: Sure - I worked it out fairly fast - but it __was__ a diversion on first arrival - particularly being unsure if this was the correct official docs site, or a third party site of possibly dubious pedigree.

Gary/chibaguy: I'm not in favor of using a logo with transparency. I posted on the dev mailing list the reasons for this opinion. I think it would be better to use an image that doesn't need transparency to look good consistently in all browsers. If the appearance of transparency is wanted, then we can make logo images to match the header background. I haven't seen Xavi's SVG file yet so can't comment on that. I would prefer a smaller image (height and width) than is used at dev.tw.o now. Marc said that Patrick's new design for the Tiki sites would be ready in a matter of weeks, not months (which was said already a week or two ago), so I'm not sure if it's worth putting much time and energy into a logo to work with the Mittwoch theme, if this theme is going to be replaced soon. I could make background-variation versions of whatever logo is decided on for doc.tw.o/Mittwoch, but don't really want to if the theme will soon be replaced.
Xavi: I fully agree with you, chibaguy, but since themes for all *.tw.o sites may take some time, and things in Tiki Community are slower than expected (usually), and since the next Wikisym is in early september (8-10), I don't mind replacing the current logo with something like this other proposed ones above, taking into consideration all comments. And whenever the new theme design is ready for all *.tw.o sites, then we replace them as we decide what to use in doc.tw.o etc.
 
__In Favor__: Xavi, MLP (white or modified blue), chibaguy (wanting to help go forward with this, but hesitant for the reasons listed)

__Opposed__:



!!# Revision of left hand menu
^__Motion:__ I propose that the left hand column 'Documentation' menu should simply contain the main content headings used in [http://doc.tiki.org/tiki-index.php?page=Documentation&structure=Documentation|the documentation page] - Introduction, Installation, Configuration, etc.^

__Discussion__: 
There are difficulties for a new user arriving at the home page in deciding where to look for information, because there are multiple menus pointing in different directions. The main [http://doc.tiki.org/tiki-index.php?page=Documentation&structure=Documentation|docs] menu is structured - and provides a good basis for the user to locate the required information. There is no need for a second (and less structured) menu list - it increases the possibility of confusion.

MLP: I think the LH menu should use a wiki page - like the main LH menu in dev.tw.o 
We should allow it to be refactored more easily. Agree that the first set of items should match top level headings in the main doc structure. 



I assume I'll not be able to vote on this - but am happy to hear other views and observe on the sidelines :)

MLP: (point of order) Mat - i think new members votes count - the ((Editorial Board)) page should contain the complete set of rules (or a link to) - and it is a very short set. 


__In Favor__: MLP

__Opposed__:


!!# Re-structure section introductions
^__Motion:__ That the main documentation adopts a strict tree structure, so that section introductions are not hidden dead ends.^

__Discussion__: 
Currently as a user I can see a menu item called (for example) 'Introduction', with 3 sub-headings: 'Goals', 'Social Contract', 'Tiki 2.0'. It's very tempting to choose one of them, and remain unaware that there are actually 4 content pages, the other being hidden under the main 'Introduction' heading.

Alternatively a user might choose the main heading 'Introduction', and be unaware that he has not covered the whole of the 'Introduction' section (as there are indeed mini-subheadings within that little branch).

I suggest there should be 4 sub-headings - clicking on the 'Introduction' heading should take the user to a page which simply lists the 4 sub-headings. That is what would be expected by very many users.

__In Favor__: 

__Opposed__:

!!# Revision of Author Resources menu
^__Motion:__ Remove the 'CoffeeShop forum' item from the Author Resources menu.^

__Discussion__: 
The forum doesn't exist; just housekeeping.

I recall the decision to end the coffeeshop discussion, but am not sure what was proposed to replace it. Maybe this is in the past board meeting notes, which I haven't read recently (:redface:) (chibaguy).

klang: xavi pointed me here - that's why I've arrived ;). Not sure whether this is a good place for discussions though - or whether I should be discussing via proposals... feel free to point me on a better path

__In Favor__: 

__Opposed__:

!!# New Motion - For September
^__Motion:__ That the ((Editorial Board)) adopts, as the terms of reference for itself the contents of the page ((Editorial Board)) as of sept 30 2008.^

__Discussion__: There seems to be confusion or disagreement about who can vote in an EB meeting, the notion of what quorum is seems to be generally agreed but needs a little clarification. My last revision of ((editorial Board)) clearly states that new members, or returning members can vote (but do not count toward quorum?)

 
__In Favor__: MLP

__Opposed__:


!# New Motions
!!# New Motion 
^__Motion:__ Grant permission to edit the documentation structure to registered users.^

__Discussion__: Documentation structure doesn't follow the code evolution. We are a few people editing it, and with access to add pages to the right place to the documentation (lets say, documentation for new mods, plugins, etc.). I would prefer investing my time to move new pages placed in wrong places by new users by mistake (and telling them to join the ((ebm)) effort, than having to add myself by hand each page for each new mod or whatever. We need to facilitate community involvement and teaching them to help rather than doing the few of us things by hand all the time, which is not scalable... 

__In Favor__: Xavi, luci (when there's daily backup of db in case the users mess it up)

__Opposed__:

---

((Editorial Board Meeting 2009 05|Next meeting: January 2009))