#   
         
    ##   
     #   
     #   
     #   
 #   #   
  ###    

         
         
 # ###   
 ##   #  
 #       
 #       
 #       
         

   ##    
         
  ###    
   ##    
   ##    
   ##    
  ####   
         

  _____  
 |  __ \ 
 | |__) |
 |  ___/ 
 | |     
 |_|     
         
         

 ______  
(  __  \ 
| (  \  )
| |   ) |
| |   | |
| |   ) |
| (__/  )
(______/ 
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''Brainstorming page for how to improve efficiency of team communications''' ---- '''Tavi to tiki conversion''' gbuonfiglio writes: * I've did first manual migration tests [2009-10-14] * Unfortunately we will have to do lots of tag conversions. I will keep notes of tags conversions and create a php script for that, parsing line per line for every page. * Do you have a list of valid tags for tavi? The page where it should be has nothing more. :( ** google: tavi wiki formatting tags ** [http://www.egroupware.org/index.php?page_name=wiki&wikipage=WikkiTikkiTavi tavi formatting] I think it misses the '''<''' pre '''>''' tag. ** doesn't tiki have "import from alien wiki" feature ? gbuonfiglio: No, it doesn't, but it has other migration scripts for popular software like Postnuke that we can use to create a Tavi2Tiki conversion script. Some links: [http://tikiwiki.org/tiki-index.php?page=MigrateToTiki General 2TikiWiki conversion information] [http://tikiwiki.org/tiki-index.php?page=ConversionFromPostnuke PostNuke2TikiWiki conversion scripts] But I guess the most promising is [http://search.cpan.org/~diberri/HTML-WikiConverter-0.68/bin/html2wiki html2wiki] perl script that converts from html to several wiki formats, including TikiWiki. It can read from standard input so I'm thinking about a script that: * iterate every current wiki page directly from database ** for earch page get it using curl and strips headers and footers ** insert the page directly on TikiWiki database The pages table is easy to convert: * tavi_pages X tiki_pages ** body = data (converted using html2wiki) ** title = pageName ** version = version ** comment = comment ** time (date format) = created (secsFrom1970) <not-available> = page_id (sequential for each page) ---- '''Critical''' This code is used by the wiki search. It is terrible, and slow: <code> SELECT t1.title, t1.body, t1.version FROM efi_pages AS t1, ( SELECT title, max(version) AS maxv FROM efi_pages GR OUP BY title ) AS t2 WHERE t1.title = t2.title AND t1.version = t2.maxv AND ( t1.title LIKE '%searchterms%' OR t1.body LIKE '%MembersPage/JanSaenen%' ) </code> This is sharkey's hint: <code> SELECT t1.title, t1.body, t1.version FROM efi_pages AS t1, ( SELECT title, max(version) AS maxv FROM efi_pages GROUP BY title ) AS t2 WHERE t1.title = t2.title AND t1.version = t2.maxv AND ( title LIKE '%trigg%' OR body LIKE '%trigg%' ) </code> TODO: * md5sum of all files, every day. So the diff should give some useful hints about anything suspicious going on. ---- '''Critical - webpage header''' Our site design is old, outdated. Brainstorming. * wiki page header hint: ** at the top, a link next to "Preferences" to take user to their own MembersPage. (or any page, that can be set in Preferences). * http://www.vems.hu top-menu ** Jason implemented some fancy header at the main page. ** http://www.vems.co.nz/menu/vemsmenu.html *** very nice looking menu Richard, great work! (hehe dont forget the dutch support point :)) **** Thanks! Any others missing? *** Very nice a horizontal shaded menu is much more Web2.0, I take it we're looking at using Blacks, Greys and Reds for the Common style then? **** Hmmm... good question. Do we have corporate colours yet? Blacks and Reds are easy to work with, and seem to match a) the existing (black and white) website and b) most representations of the (red) logo. *** UnderDevelopment/WiKi/MenuHierarchy ** http://www.vems.co.nz/menu2/index.html These are easy enough to make and to change, as I'm using [http://www.xara.com/products/menumaker/default.asp Xara Menu Maker]. * or left-menu http://www.vems.hu/vertmenu.html ** The above doesn't work in Opera, the menus are empty but responsive. *** Thanks for testing. By tweaking the sizes a bit I got the top menu to look reasonable in Firefox and Opera on Linux. Can you try again? ** It's cool, but unfamiliar to most users - people are just more used to the horizontal drop-down menu. * a menu that expands on demand. Interoperable javascript is possible now, but it would be nice if it worked without javascript too (just slower as the answer comes from the server that way, of course). The left-menu is more natural when used as a tree-browser. The top-menu can be shrinked to use less space originally (when unexpanded). * google: javascript example page header menu ** or: +javascript example page header +menu +opensource * [http://www.milonic.com/menusample83.php marcell's favorite] ** menus with pictures are extremely nice. ** cost is OKish ** it would be nice if it worked from static files, not database. Our database load is already high, and static service reliability is 99.9% while database is lower. *** Yup, it's nice... pics are more bandwidth/load-time for little benefit? * http://savage.net.au/Perl-tutorials.html seems to work from files ** http://microhaus.com.au/index.html *** As above, links don't summarise content - too much to read to find what's wanted... and while a tree makes sense after some thought (especially if you're the person uploading HTML files to those folders)... but the punters won't want to think too hard about it - web 'locations' don't live in folders. Stick to the common horizontal style drop-down menu. :-) ---- '''Wishlist''' '''Revert attack''' - automatically * Marcell has been extremely busy for a while, and found that there was an attack ongoing for several days. Thanx for Dana to keep reverting pages. I propose '''"revert attack"''' comment (summary of changes) for such actions. Marcell wrote a '''[http://www.vems.hu/files/MembersPage/MarcellGal/wiki_revert/ perl script] to automatically revert pages''' based on text snipped from recentchanges. It requires ** mysql access ** some manual intervention. Eg. pages that were reverted need 2 versions to be dropped (the revert and the attack). ** a professional version could be deployed in the wiki so trusted (authenticated) users could do this from the web (CGI). '''Turing test related''' - reopened * TODO: only allow page edit for registered users. Currently the test does not prevent casino spammers from commiting. ** registration can happen with (verification code sent in) email. This would be simplest to solve ** technical proposal: in WebShop (besides the secret pwd and public WebShop/ReferralId) this could be a 3d identifier (not as secret as normal pwd, but not public either) that would be used to edit wiki pages. However, currently even webshop doesn't validate entered email addresses (we noticed in a few cases that they were wrong!) ** '''or''' credit card (pay $9 membership fee) - not needed if we have the above * DONE: '''automatically apply "preview" if the turing-test fails to give the user another chance, without pressing "Back"''' (and the danger of losing text). This is the right way to do it (wonder why the turing test code authors didn't do it that way). '''Turing test - still a bit annoying''' * make it possible to commit without a turing test, maybe with a cookie. Username/password input-fields can be on the form (at least if there was no valid cookie) and set a cookie in the browser if they are of a registered user. * apparently the turing test refuses the code after a certain amount of time (if editing takes long, it almost always refuses; otherwise usually accepts) * turing-test has some '''hard to distinguish characters''' (v-u, m-h, e-b, d-o, etc...). Sometimes it does not accept very clear codes (maybe errors in the configuration? '''Other wishes''' * '''RSS feed''' for the Wiki, instead of reloading RecentChanges all the time ** There already is an [http://www.vems.hu/wiki/index.php?action=rss RSS] function. However, the patch at the bottom of [http://tavi.sourceforge.net/index.php?page=RSS+Syndication this] would be a nice addition. * '''Hardcopy''' download of the Wiki. So I can browse on the train, at my mother-in-law, the garage, or wherever I don't have internet access. This can be done with ''wget -r -l2 http://www.vems.hu/wiki/index.php?page=SiteIndex''. Should we do it "officially" on a remote machine daily so zip can be fetched from there ? ** See http://www.6speed.org/vems/web/wiki_capture.zip - from 13Feb05 * '''Distributed sourcecontrol'''. The ability to track local changes even without internet access is really useful. At work I have internet access, but the firewall forbids me to use ssh (thus making CVS impossible) and the web-proxy doesn't allow some commands (thus making SVN impossible). [http://www.gnuarch.org/ Arch] is gaining momentum among developers, even if I prefer [http://abridgegame.org/darcs/ darcs] myself. There are probably others that allows for distributed repositories. I think there even is a patch for SVN, but I haven't looked at it. Maybe I misunderstand this... but ''distributed sourcecontrol'' can be easiley done with keeping a copy before your changes (on unix cp -al allows to do this with almost 0 diskspace) and a ''diff -U 4 command'' between the original and the changed tree. That applies to SVN or CVS or anything. * '''Drop-down menus''' for the buttons on the top of the page - I have a feeling that would capture the attention and appeal to the wiki-unfamilliar. This must be configurable in preferences so it can be turned off (because it's less efficient than direct links). * '''MembersPage change''' get rid of the annoying MembersPage/ in front of everybody's username, maybe also alphabetically order the list of people? This will be wonderful, if we have a way to collect all member-pages on a page (easy) - the harder part is to have a siteindex2 that does _not_ link to these pages (or keeps them separate). It's not good if these links mix with the rest. I know that we shouldn't rely on SiteIndex, but that is even harder. ** This would require internal code changes to the wiki software most likely. I will sign up for it after OfBiz is up, running, and finally our new storefront. (Jason) * Search related. See below ---- '''The big question: how to store info?''' There are some information that must be stored in CVS (or SVN), some that must go to ofbiz, but for some information it is not clear where would be best (most efficient). * CVS or SVN: nice versioning systems; for professionals these beat anything, but for novices requires some learning (1..8 hours depending on previous skills and client and firewall issues) * Wiki is very easy to use, no firewall or client issues, but not ideal for versioning and structured info * ofbiz.org is ideal for inventory, order-processing, development workeffort and shares. In many case, the format (of human readable info) is a question. Information should be organized by content, not by layout. Major goal is that anyone can find the interesting info relatively fast. This requires an established index and easy maintenance of content. Note that email is not sufficient to store information, it's just useful for a nudge. Now looking for wiki engines that have CVS or SVN backend (or provide CVS or SVN interface to the page-set) tools that work on local files: * to enable the usage of (existing) advanced ** notification. An email every time something changes is the wrong way. If one just checks a project once a week will have 500 emails. The right way is provide a flag to show if the content changed since last checked. This works wonderfully with the SVN revision number. This way one can put 200 red/green buttons on his personalized (priority-arranged) information control board dynamic webpage, and follow any number of information areas without checking RecentChanges every time (frustrating for rarely changing info areas) ** edit (many nice editors) ** diff (nice differs, like eclipse) ** grep ** backup * support '''offline''' browsing and editing (I see many cases where the offline possibility is the only justification for email - direct CVS would be too big step for some people) * authorization support * better (than traditional wiki) handling of editing conflicts When I last looked at wiki engines, I wasn't sure of what's most important. Having used many systems since, now confident about the necessity of CVS/SVN interface. Have to review wiki engines, in this perspective. ---- '''clean up the rest sometime...''' - note: not just delete, that does not solve the discussed issues. '''target audience of change''' As our wiki traffic increases, people want to filter what they read and what they skip. * splitting to several wikis is the wrong way * having pages organized in major categories could be suitable, still a clumsy way for this (information must be organized thematically, not according to audience, or time of creation or source) The good way is to have explicite information of the target audience - in some cases. * when someone posts he can tell ''in attention of'' and adding some groups: * obviously, the selection must happen on group level, usually (''in attention of'' shopkeepers, firmware developers, firmware users etc...) rarely user level. Not needed, we'll use ofbiz to assign tasks (like "don't miss .... page in any case" and confirmation when it's done) * RecentChanges should have an option to filter changes; show those changes separately that are ''in attention of'' groups that I am a member of. If one has limited time, he'll only read those. Not needed. Which wiki has this feature? * tikiwiki ? * xwiki ? a clumsy workaround would be offchannel notification: email groups (a few more than what we have now) that are manually notified for major changes - with the link included. Ofbiz workeffort will be the perfect way to keep such meta-info noise out of the wiki, but still available. ---- '''Search engine proposals''' To find information in wiki easy, we need some conventions: * matrix on GenBoard/Manual * MembersPage stuff (grouping pages, but that need not necessarily show up in the title). Search for Ionsense first (verified there is an ionsense page). Broken google links, like ''ionsense site:www.vems.hu'' were caused by a change in CGI location (a /wiki/ prefix was added). '''I'm sure he had a good reason because this broke all external links'''. The google links fixed themselves by now, but the other external links will become broken. Also searched on wiki itself and got the following results: <code> Find ionsense CoilOnPlug DetonationDetection EdisIgnition/SoftwareModule FPGAProContra GenBoard/AutoTune GenBoard/CodeFlowChart GenBoard/EngineBoard GenBoard/Manual/InputTriggerTypes GenBoard/UnderDevelopment/FirmWare GenBoard/VerFour GoBox/Analog GoBox/BlockFlowDiagrams GoBox/TargetSpecifications IgnCalc InCylinderPressure IonSense IonSense/CicuitAndSimulation IonSense/Components IonSense/HardwareDesign IonSense/LoggingData IonSense/PeakPressureAlgorithms </code> So we obviously have a problem. the Ionsense page is about 20th down on the list. the '''exact match for the title and its child pages should be first'''. maybe we should try to glom on google? set it up so that the search is effective? * Yes, make a link please! * Also, use google to find references to the site and let's fix the links that we can. * also, the '''Search function needs a "not found" case''', for when the phrase you've searched for isn't found in the wiki. ---- '''See also''' * UnderDevelopment * [http://wiki.x-dsl.hu/cgi-bin/w/meta.cgi Meta-Wiki] eg. wikis with SVN and CVS backend. We'll slowly move information-storage and communication related discussion from this wiki.
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.