History: Editorial Board Meeting 2009 06
Source of version: 69 (current)
Copy to clipboard
! Editorial Board Meeting 2009 06
{REMARKSBOX(class=>Note,title=>"Note")}
!!!!- About Quorum and Voting
~~red:This methodology changed in May 2009, as an attempt to resurrect the effectiveness of the ((EBM)), which had been stopped since October 2008. We hope this way meetings are more agile to create, and decide upon.~~
__Quorum__: Defined as the smallest number which is greater than 50% of the number of current members.
__Current members__: individuals who have voted in ''both'' of the two previous meetings.
Example for the last two meetings:
* In ((Editorial Board Meeting 2009 05)): lindon, ricks99, marclaporte, xavi, luci.
* In ((Editorial Board Meeting 2008 10)): xavi, luci, chibaguy
In other words: Quorum "floats" to match half of whatever the current level of participation is. If someone misses a meeting (or is new) they won't count towards quorum for the next two. ''It does not mean that they cannot vote''.
The list of current members at the top of the page is for reference, anyone may note that so and so voted in some ((Editorial Board)) meetings and adds that name. Edit history of a page is the real proof of participation. there must be an edit in that month by that person.
If consensus is not reached on a particular motion, a vote will decide on accepting or rejecting a motion. It takes 50%+1 "current" members voting (for, against or abstain) to decide a motion. For example if the number of current members is 7, then quorum would be 4, which means that if two vote in favor, one against and one abstains, the motion passes.
!!!! This is a meeting of the ((Editorial Board)) - it runs online from June 1st to June 30th, 2009.
* Members considered current for this meeting (~~red:2~~): xavi, luci
+__2 votes (for, against or abstain) are needed to reach quorum on the decisions for this month__. Please read above the [[+] "About Quorum and voting" section.
* Contributors to this meeting: see "history" of the page.
{REMARKSBOX}
Last meeting: ((Editorial Board Meeting 2009 05)) | Next meeting: ((Editorial Board Meeting 2009 07))
!! Motions Passed Last Month
!!# Use proposal plugin for future EBM
!! Motions Defeated Last Month
none
!# Motions Carried Over
!!# Change doc.tw.o menus
^__Motion:__ Change menus according to doc.tw.o revamp proposal page: http://tikiwiki.org/doctwo+revamp .^
__Discussion__: see that ((tw:doctwo revamp)) page.
marc: I hope top menu will one day be used [http://profiles.tiki.org/tikiwiki_org_sites_profile|for global *.tiki.org navigation]
__Undecided__: lindon (I like having the ((All the Documentation)) site map link somewhere, also like the current choices under Author Resources. Depending on how reduced TOC in side menu looks, some keywords might still be helpful since lots of things are covered in keywords that wouldn't show in a reduced TOC or freetags. Otherwise menu proposals seem okay.)
lindon again: would also like a link to my user page for registered users
Things like __Author resources__ would appear only for authors. Not sure I agree about having __User Pages__ on doc.tw.o. IMHO, User Pages should be limited to the community site. (ricks99)
I'd also like to see the registration process change for tw.o changed so that new registrants can choose:
*Community Member (write access to tw.o)
*Developer (write access to dev.tw.o)
*Doc Contributor (write access to doc.tw.o)
+ -ricks99
{PROPOSAL(caption="Motion #")}
+1 ricks99
+1 luci
0 lindon
0 xavi{PROPOSAL}
!!# Change doc.tw.o modules
^__Motion:__ Change modules according to ((tw:doctwo revamp)) proposal page.^
__Discussion__: see that ((tw:doctwo revamp)) page.
* lindon (I don't mean that i completely oppose but i do like the registered users online, and search by page name modules for registered users. Also assume the developer menu would remain for those users.)
+ xavi: so do I. I'm ok with the general proposition with your additional comments, lindon
**For an end-user, what value does the "Registered Users Online" module give? (ricks99)
***If I register for a site like this, where just about the only reason to do so is to collaborate and "volunteer" in some way, then I enjoy seeing who else is online. It's motivating to me. If I just want info then I don't login here. But that's just me ;-) Certainly not a deal-breaker one way or the other, but I would miss it if it went away. (lindon)
****I guess to have it for Registered only would be OK. But for Anonymous visitors, I see little value.
*****Agree - my original suggestion above was for registered users only. (lindon)
lindon again: would like a bookmark module for adding own bookmarks
*Hmm... To be honest, I've never used Tiki's bookmarks. I've always simply used bookmarks directly within my browser.
**But nice to give the option for those that like such modules? Or do you think it clutters things too much? (lindon)
***For me, it is just visual clutter. But if we enable Registered users to configure their own modules, then people like me could remove it, and folks like you could keep it. (ricks99)
****Great idea. (lindon)
What about using polls, surveys, etc. to ask users for opinions on what modules they would like or not like (like "Would you like to see a bookmark module on the side menu?", "Do you find the keyword list useful?" etc.). We could expand it to cover other things periodically like "What area of documentation needs the most work?", "What pages do you think work best?". Just a thought. Not sure what the experience has been with this sort of thing. (lindon)
*IMHO this should be posted in the Documentation forum on tw.o. I really think we should strive to keep doc.tw.o neat and clean -- KISS.
{PROPOSAL(caption="Motion #")}
+1 ricks99
-1 lindon
0 xavi
{PROPOSAL}
!!# categories for status
Motion: keep Categories to indicate also the status of wiki pages, besides the wiki tags and freetags
__Discussion__: are there but not being used. Do we use? or do we nuke?
ricks99:
* I (ricks99) would like to continue to use them (to alert readers as to the "correctness" of a particular page). However I see a potential issue: How can we "split" the category of a page when using the VERSIONS plugin? For example, the 2.x information may be "LIVE", but the 3.x information may be "TO DO." Currently (I think), Tiki allows only 1:1 -- category:page.
* I (ricks99) would also like to see the categories be simplified. Maybe something like:
## Stub -- Newly generated page; no real content.
## In Progress -- Being worked on, not up-to-date or complete.
## In Review -- Content complete. Needs to be reviewed/verified.
## Complete -- Page is done & published.
Maybe also use Staging feature?
{QUOTE(replyto=>lindon)}I could take or leave the categories for users, but find the backlinks method used in ((documentation status)) and the other tools marc has set up (like ((All plugins))) to be the best for authors.{QUOTE}
xavi: I propose to remove all categories for status, since they are applicable to the whole wiki page, and I find the status ((tags)) and backlinks (implemented by mlpvolt and dthacker, afaik) much more versatile in a per version, section or paragraph basis.
+ I suggest to keep categories only for monitoring specific groups of pages like in ((EBM)) pages. CLick once to monitor somewhere for EMB pages, and you receive emails about changes on all pages, even if you forget the monitor the page for the new month (in case it has been properly categorized, of course ;-) ).
marclaporte: if we keep, who will clean up the 1000 pages? We need a reset/clean-up. Perhaps erase all and build organically from now on.
{PROPOSAL(caption="Motion #")}
+1 ricks99
0 lindon
-1 xavi{PROPOSAL}
!!# Remove en-uk as a possible language
just causes confusion. When we filter by language, there are uk english pages which are not really different to English pages
There is no en-uk version for Wikipedia, with [http://meta.wikimedia.org/wiki/List_of_Wikipedias/sortable|over 250 languages]
__Discussion:__
-1 -- __color__ is different than __colour__ (ricks99)
+1 No disrespect meant to UK people, but many languages have regional variations but are still essentially understandable and considered a single language. Tiki's en-uk is probably meant for UK-focus sites. (chibaguy)
{PROPOSAL(caption="Motion #")}
+1 marclaporte
+1 chibaguy
-1 luci
-1 ricks99
0 xavi
0 lindon{PROPOSAL}
!!# Remove my footnotes
to simplify interface
need to check in db if any data
__Discussion:__
+1, i never used it myself -- luci
-1, I like having it. It allows contributors to work on pages without actually editing the "real" content. ''If'' we implement the Staging system to doc.tw.o, then +1 from me (ricks99)
-1, I haven't used it but think it could be useful. Not sure if staging would replace it for me. (lindon)
{PROPOSAL(caption="Motion #")}
+1 luci
-1 ricks99
+1 xavi
-1 lindon{PROPOSAL}
!# New Motions
!!# New Motion 1
^__Motion:__ I would like to have the following entry added in its FAQ sections found at http://doc.tiki.org/tiki-list_faqs.php
Installation and Setup:
How do I know I have the latest/current version of TikiWiki?
The latest version is always the one you find on the Sourceforge download site http://sourceforge.net/project/showfiles.php?group_id=64258 or available from http://info.tiki.org/tiki-index.php?page=Get+Tiki
From a running installation, you can verify you are up to date by performing a release check. This is done by selecting the first item in the General section of the Configuration Sections.
^
__Discussion__: I find it dangerous and cumbersome to not be informed of new and potentially security related versions, upgrades and bugfixes of TikiWiki. While there is no solution to that problem, I find it important to provide the information how to overcome it, by checking before installing, or using the release check.
*Does this really need to be an EBM Motion? Why not simply submit this as a new Suggested FAQ? Isn't that the purpose of enabling the SUGGEST AN FAQ option? (ricks99)
** It was entered here since I was recommended to do so on IRC. (tobi_h)
*** Again, ignore this entry - I am checking on the status of this bug: http://dev.tiki.org/tiki-view_tracker_item.php?itemId=2591 (tobi_h)
{PROPOSAL(caption="Motion #")}
+1 xavi
+1 tobi_h
+1 lindon
+1 ricks99{PROPOSAL}
!!# New Motion 2
^__Motion:__ I would like to have the following entry added in its FAQ sections found at http://doc.tiki.org/tiki-list_faqs.php
Security:
How do I find out about vulnerabilities and security issues of my TikiWiki installation?
Currently, the best way to do that is to subscribe to the RSS feed of [insert relevant website here], and checking that on a regular basis. Maybe we will dedicate an announcement mailing lists later on.^
__Discussion__: I find it dangerous and cumbersome to not be informed of new and potentially security related versions, upgrades and bugfixes of TikiWiki. While there is no solution to that problem, I find it important to provide the information how to overcome it, by using the RSS feed. I'd appreciate if there were a commitment by the developers WRT the location of such announcements. ;)
{PROPOSAL(caption="Motion #")}
+1 xavi
+1 tobi_h
+1 lindon{PROPOSAL}
!!# New Motion 3
^__Motion:__ I would like to have the following entry added in its FAQ sections found at http://doc.tiki.org/tiki-list_faqs.php
RSS:
Can I have a RSS feed of comments to Blog entries on my site?
Currently, this feature is not yet implemented. Look at bugs http://dev.tiki.org/tiki-view_tracker_item.php?itemId=1194 and http://dev.tiki.org/tiki-view_tracker_item.php?itemId=2070 for updates on this.
^
__Discussion__: Concerning the RSS feed of comments: I am bitten daily by this, and have several users of my site on my back with this. I guess I am not the only one looking for that information. :)
{PROPOSAL(caption="Motion #")}
+1 xavi
+1 tobi_h
+1 lindon{PROPOSAL}
!!# New Motion 4
^__Motion:__ Provide the perms to the "doc.tw.o_contributors" group to add faqs.
^
__Discussion__: xavi mentioned this to be a good idea. I agree. :)
Is a doc contributor the same as a doc editor? If yes, then I agree. If not, then the doc contributor should be using the "Suggest an FAQ" feature, and the doc editor should approve/reject the suggestion.
{PROPOSAL(caption="Motion #")}
+1 xavi
+1 tobi_h
+1 lindon
0 ricks99{PROPOSAL}
---
!!# New Motion 5
^__Motion:__ Keep doc.tw.o for docs (what Tiki does) and send all support requests (how should I do this?, does Tiki do this?, etc) to http://tikiwiki.org/forums and bug reports/feature requests to dev:((dev:report a bug)) (what we wish Tiki did). So remove this page and ones like it: ((Feature Problems)) and review/clarify ((get help)). [http://doc.tiki.org/LDAP+authentication#Trouble_with_solaris_and_ldap|Here is an example of pollution]
^
__Discussion__:
I am ok to keep a link from doc to any relevant thread or info. So there could be relevant links section on all pages.
Maybe we can have a custom module or plugin on each doc page:
{DIV(width="250px")}^__For This Feature__
*[http://tikiwiki.org/forums|Have a question?]
*[http://dev.tiki.org/tiki-index.php?page=Report+a+Bug|Log a bug.]
*[http://dev.tiki.org/tiki-index.php?page=Report+a+Bug|Request an enhancement.]
^{DIV}
-ricks99
And, ideally, all doc pages that have corresponding sister wiki page on dev.tw.o should have a prominent link.
{PROPOSAL(caption="Motion #")}
---
((Editorial Board Meeting 2009 07|Next meeting: July 2009))