• 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}

• Motion 1: Dogfood versions plugin

• none

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 Versions plugin for this, maybe?

Vote
In Favor: dthacker, xavi, ricks99 (via the 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)

discussion

• 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 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

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....)

Motion: Change logo in doc.tw.o to something similar to dev.tw.o. For instance, something like:

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):
  
  
  
  This is how it could look like, even on IE6
  
  

• 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: (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 (=tikiwiki.org 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:

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 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:

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:

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 😡 (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:

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:

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:

Next meeting: January 2009