Tiki Wiki CMS Groupware

le Mon, Jun 30, 2003 at 01:22:13PM -0700 par Tony Colley :
> > There are so many short comings that are based on poor project
> > planning, leadership, standards, practices - that it will never
> > succeed as a practical, real-world, application.
> > It will remain a developers toy of eye-candy and bag of showoff
> > coding.
> 
> Actually, I *am* using it as a practical, real-world, application.
- same here.

And strong leadership is made for army. In free software we use
collaboration rather.


mose
(major default: is a coder)

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Oliver Hertel <rom@re...> - 2003-06-30 21:42 On 30 Jun 2003 at 21:50, Patrick Van der Veken wrote: > People have spoken about these 'Tiki' flaws before. Through posts and through > logging RFE's. I don't think it's fair to go Tiki-bashing now, not with all > the hard work that all the developers are putting in. I'm not bashing. If tiki was that bad, I wouldn't use it myself. :-) Bye, Oliver

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: zaufi <zaufi@se...> - 2003-06-30 22:56 On Tuesday 01 July 2003 01:06, mose wrote: > le Mon, Jun 30, 2003 at 01:22:13PM -0700 par Tony Colley : > > > There are so many short comings that are based on poor project > > > planning, leadership, standards, practices - that it will never > > > succeed as a practical, real-world, application. > > > It will remain a developers toy of eye-candy and bag of showoff > > > coding. > > > > Actually, I *am* using it as a practical, real-world, application. > > - same here. I have 2 working servers -- both inside intranet -- and 3 for tests/development: Internet public, home computer, notebook :) > > And strong leadership is made for army. In free software we use > collaboration rather. That's right... __BUT__ # absence of coding standars make source looks like abomination :() -- It is __real__ clog (at least for me) to read the code... I (PHP newbie :) see that PHP have C-like syntax, but have no C-like coding rules -- PHP code (I saw in TIKI) looks awesome... :) # absence of API docs force developer reinvent (+ test/debug time) code/function/classes which is possible already exists in project... so code reusing among developers == almost __zero__ # absence of some (even brief) architecture/internals overview prevent new developers be rapid involved into development cycle... -- it is real hard to track whats going on in not so small system like TIKI become :) to implement 1 and 2 collaboration is highly required :) -- but as KDE team shows it can be achieved :) -- (2500 members and more than 650M source code) I'm agree that TIKI for most of us is a eye-candy but after some high level of entropy system should be transformed to next level of order to keep continuity... Isn't it? :)

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: zaufi <zaufi@se...> - 2003-06-30 23:03 On Monday 30 June 2003 23:50, Patrick Van der Veken wrote: > I have in the past suggested of > using a release scheme like the linux kernel (a solid release alternating > an experimental release). I think this way you can combine the great > creative efforts of developers (and the sometimes erratic user demands) > with a piece of software that is stable enough to please at least 80% of > the user population. > fully agree +1 from me ;)) we don't make a commercial software so no need to produce stable releases so often (every time :) as smdb already said: Tiki stay developer eye-candy :) -- some of us needs periodically to release 'creative efforts' :)

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-06-30 23:42 On Monday 30 June 2003 03:01 pm, Luis Argerich wrote: > > There are so many short comings that are based on poor project > > planning, leadership, standards, practices - that it will never succeed > > as a practical, real-world, application. > > It will remain a developers toy of eye-candy and bag of showoff coding. > > Welcome to the open-source world. > So compare your project against GNU/GCC - Then decide if you want to build a solid open-source project. It is a matter of choice, all up to the active developers. Mike > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Dev-Tiki? Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Tex <tex@te...> - 2003-07-01 00:01 Do you think it might be a good idea to put up a wiki for the developers? as a place to collaboratively sort out priorities, problems, roles, design principles and goals? As a starting point for an dev/api documentation? Maybe it might even make sense for the users too. Now that we have virtual hosting implemented :) I'd happily donate bandwith, as long as it fits into my server's headroom. Tex Am Dienstag, 1. Juli 2003 00:54 schrieb zaufi: > That's right... __BUT__ > # absence of coding standars make source looks like abomination :() -- It > is __real__ clog (at least for me) to read the code... > I (PHP newbie :) see that PHP have C-like syntax, but have no C-like coding > rules -- PHP code (I saw in TIKI) looks awesome... :) > # absence of API docs force developer reinvent (+ test/debug time) > code/function/classes which is possible already exists in project... so > code reusing among developers == almost __zero__ > # absence of some (even brief) architecture/internals overview prevent new > developers be rapid involved into development cycle... -- it is real hard > to track whats going on in not so small system like TIKI become :) > > to implement 1 and 2 collaboration is highly required :) -- but as KDE team > shows it can be achieved :) -- (2500 members and more than 650M source > code) > > I'm agree that TIKI for most of us is a eye-candy but after some high level > of entropy system should be transformed to next level of order to keep > continuity... Isn't it? :) -- Tex tex@... 030 6953 4584 0163 839 66 28

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 00:04 On Monday 30 June 2003 04:06 pm, mose wrote: > le Mon, Jun 30, 2003 at 01:22:13PM -0700 par Tony Colley : > > > There are so many short comings that are based on poor project > > > planning, leadership, standards, practices - that it will never > > > succeed as a practical, real-world, application. > > > It will remain a developers toy of eye-candy and bag of showoff > > > coding. > > > > Actually, I *am* using it as a practical, real-world, application. > > - same here. > > And strong leadership is made for army. In free software we use > collaboration rather. > Collaboration need not be without guidance and direction. > Perhaps that word did not translate well... "strong leadership" != "dominate leadership" "strong leadership" == "quality, productive leadership" At least in the sense I used it in my post. Mike > > mose > (major default: is a coder) > That is an acceptable default. > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Tex <tex@te...> - 2003-07-01 00:07 on the other hand, a couple of years ago there wasa a split in gcc, a couple of guys forked and built "egcs" on a "wreckneck" release-early, releasy-often, release-premature bazaar-style scheme. After about a year the new code was not only a lot further developed, but also more stable, so egcs took over; it is now the official gcc (as far as I know). > So compare your project against GNU/GCC - > Then decide if you want to build a solid open-source project. > It is a matter of choice, all up to the active developers. > Mike -- Tex

Re: Dev-Tiki? Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 00:13 On Monday 30 June 2003 07:01 pm, Tex wrote: > Do you think it might be a good idea to put up a wiki for the developers? > as a place to collaboratively sort out priorities, problems, roles, design > principles and goals? As a starting point for an dev/api documentation? > > Maybe it might even make sense for the users too. > Very good suggestion. It makes a lot of sense for developers also. Nearly everything mentioned in this thread could be dealt with in a (tiki-)wiki. Doesn't it make sense that the people who write it should also use it? Mike > > Now that we have virtual hosting implemented :) > > I'd happily donate bandwith, as long as it fits into my server's > headroom. > > Tex > > Am Dienstag, 1. Juli 2003 00:54 schrieb zaufi: > > That's right... __BUT__ > > # absence of coding standars make source looks like abomination :() -- It > > is __real__ clog (at least for me) to read the code... > > I (PHP newbie :) see that PHP have C-like syntax, but have no C-like > > coding rules -- PHP code (I saw in TIKI) looks awesome... :) > > # absence of API docs force developer reinvent (+ test/debug time) > > code/function/classes which is possible already exists in project... so > > code reusing among developers == almost __zero__ > > # absence of some (even brief) architecture/internals overview prevent > > new developers be rapid involved into development cycle... -- it is real > > hard to track whats going on in not so small system like TIKI become :) > > > > to implement 1 and 2 collaboration is highly required :) -- but as KDE > > team shows it can be achieved :) -- (2500 members and more than 650M > > source code) > > > > I'm agree that TIKI for most of us is a eye-candy but after some high > > level of entropy system should be transformed to next level of order to > > keep continuity... Isn't it? :)

Re: [Tikiwiki-devel] Re: Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 00:16 On Monday 30 June 2003 03:36 pm, Dennis Heltzel wrote: > Luis Argerich wrote: > >>There are so many short comings that are based on poor project > >>planning, leadership, standards, practices - that it will never succeed > >> as a practical, real-world, application. > >>It will remain a developers toy of eye-candy and bag of showoff coding. > > > > Welcome to the open-source world. > > <SOAPBOX> > That is *so* true! > > The really interesting, cutting edge software is easily confused with > "eye candy", and that's by design. I bet there are a lot of OS projects > in the dustbin that were quite good architecturally, but didn't look > that nice at first glance. First impressions are very powerful, even if > often wrong. My mother always said "you can't tell a book by it's > cover", but it you look at modern book covers, you realize that few > people believe that anymore (at least in the minds of the publishers). > > No OS project (not even Tiki -- sorry Luis) is the perfect fit for every > person or organization, and trying to do that will create a giant mess. > I call Windows as my witness, particularly appropriate if you look at > the rant above <DisClaimer> That isn't a rant - it is a stated observation of fact. If you take it personally, that is your choice. Mike </DisClaimer> > and substitute MS for the Tiki team (I guess they will > never succeed either). > > Personally, I like the leadership that Luis provides. If you are looking > for disfunctional leadership, OSS is rife with examples, but Tiki's too > young and too successful to even be a contender. Luis doesn't always > accept my suggestions (I still think we should release beta versions), > but it doesn't make the software less valuable to me. > </SOAPBOX> > > Dennis > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 00:24 On Monday 30 June 2003 03:29 pm, Terence wrote: > On Mon, 30 Jun 2003 14:16:36 -0500, "Michael S.Zick" <mszick@...> > > said: > > Right On! > > There are so many short comings that are based on poor project > > planning, leadership, standards, practices - that it will never succeed > > as > > a practical, real-world, application. > > It will remain a developers toy of eye-candy and bag of showoff coding. > > > > Like the website says: > > Open Source Excellence, One line at a Time > > (with the same foresight applied to design, implementation > > and support - one line at a time.) > > Hmm though I am no developer, my bosses and I have found Tikiwiki good > enough to be deployed as a CMS system for the IT department at my > university. For me, it has the perfect blend of power-user features and > user-friendly design. There is, to my knowledge, no CMS system that > combines the ease of a wiki system and the out-of-the-box functionality > and one-click installation and configuration of the *Nuke family CMSs. > Is that not a sign of good design and vision? Tikiwiki fills a very > important niche perfectly. > Vision and Foresight - most likely. But don't compare Good Luck with Good Design As someone else proposed in this thread, establishing a Tiki-Wiki to deal with all of these matters would be a good idea. Nothing really compares with expecting the authors to actually USE what they write. Consider it testing in a for-real, mission critical setting. Mike > > > Unless, > > someone steps forward with the leadership to get the current situation > > in hand. > > PS: You are missing a big audience by not having an English version > > of the user visible output ("English" => includes spelling, syntax, > > grammar). > > What do you mean by "English user visible output"? In any case, those of > us who are no coders but have good English skills should help out in the > documentation and proofreading departments. Hopefully I can contribute > some relevant in-house documentation to the project in the future. > > A big thank you to all Tiki developers. > > Terence > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 00:43 On Monday 30 June 2003 05:54 pm, zaufi wrote: > On Tuesday 01 July 2003 01:06, mose wrote: > > le Mon, Jun 30, 2003 at 01:22:13PM -0700 par Tony Colley : > > > > There are so many short comings that are based on poor project > > > > planning, leadership, standards, practices - that it will never > > > > succeed as a practical, real-world, application. > > > > It will remain a developers toy of eye-candy and bag of showoff > > > > coding. > > > > > > Actually, I *am* using it as a practical, real-world, application. > > > > - same here. > > I have 2 working servers -- both inside intranet -- and 3 for > tests/development: Internet public, home computer, notebook :) > > > And strong leadership is made for army. In free software we use > > collaboration rather. > > That's right... __BUT__ > # absence of coding standars make source looks like abomination :() -- It > is __real__ clog (at least for me) to read the code... Good point, If you can't read it - how can you fix it or extend it? > I (PHP newbie :) see that PHP have C-like syntax, but have no C-like coding > rules -- PHP code (I saw in TIKI) looks awesome... :) For a starting point, check Chapter 4 of your PEAR documentation. I don't agree with those standards myself, but it is a document which is available to all which could be adopted in whole or part; with or without modification. Lacking any agreement in this area, sense it is usually very personal... A minimum would be for a developer to adopt the same conventions demonstrated in a source that they are changing. Mixed coding styles within a single source file... I have nothing (polite) to say about that. > # absence of API docs force developer reinvent (+ test/debug time) > code/function/classes which is possible already exists in project... so > code reusing among developers == almost __zero__ Good point. Coding is one of those things that is easy to "learn as you go" - and self taught skills are very rewarding. Documenting what you have written isn't as much fun - but it does illustrate what you think of your own work. > # absence of some (even brief) architecture/internals overview prevent new > developers be rapid involved into development cycle... -- it is real hard > to track whats going on in not so small system like TIKI become :) Good point. But that takes planning. > > to implement 1 and 2 collaboration is highly required :) -- but as KDE team > shows it can be achieved :) -- (2500 members and more than 650M source > code) > Yes. and OpenOffice is another one. > > I'm agree that TIKI for most of us is a eye-candy but after some high level > of entropy system should be transformed to next level of order to keep > continuity... Isn't it? :) > The simpler solution is to just update the PDF manual, take out that list of possible uses and put in a "We really don't take what we do seriously, neither should the user." Mike > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Luis Argerich <luis@fu...> - 2003-07-01 11:38 > So compare your project against GNU/GCC - > Then decide if you want to build a solid open-source project. > It is a matter of choice, all up to the active developers. > Mike Why compare? we don't need to compare Tiki, we do this because we like it and because we believe that the effort of many developers can be combined to create an application that can be useful to some number of people.

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: zaufi <zaufi@se...> - 2003-07-01 12:23 On Tuesday 01 July 2003 04:06, Michael S. Zick wrote: > > That's right... __BUT__ > > # absence of coding standars make source looks like abomination :() -- It > > is __real__ clog (at least for me) to read the code... > > Good point, > If you can't read it - how can you fix it or extend it? > Oops.. I guess my English too bad -- it never was my strengh side :(( I mean that reading such code add some kind of difficulty ... I'm still not found in Tiki source that looks like C++ style I (and team where I works) use... :) For example, how do you like this: $litype=substr($line,0,1); if ($litype=='*'||$litype=='#') { $listlevel=$this->how_many_at_start($line,$litype); $liclose='</li>'; $addremove=0; if ($listlevel<count($listbeg)) { while($listlevel!=count($listbeg)) $data.=array_shift($listbeg); if(substr(current($listbeg),0,5)!='</li>') $liclose=''; } elseif($listlevel>count($listbeg)) { $listyle=''; while ($listlevel!=count($listbeg)) { array_unshift($listbeg,($litype=='*'?'</ul>':'</ol>')); if ($listlevel==count($listbeg)) { $listate=substr($line,$listlevel,1); if(($listate=='+'||$listate=='-') &&!($litype=='*'&&!strstr(current($listbeg),'</ul>') || $litype=='#'&&!strstr(current($listbeg),'</ol>'))) { $thisid='id'.microtime()*1000000; can it be named good style? IMHO NO! All in this style designed to make cryptic-looking unreadable source code... > For a starting point, check Chapter 4 of your PEAR documentation. > I don't agree with those standards myself, but it is a document > which is available to all which could be adopted in whole or part; > with or without modification. > of couse yes... we r free to change anything :) But my opinion that team __must have__ some type of coding standarts... > Lacking any agreement in this area, sense it is usually very personal... Initialy all members have personal coding style, but when styling rules approved in team after 2 weeks it become your nature.... -- 'bcouse all members agreed (less or more) with every point of coding standarts ... -- and you will got difficulties when read you old code :) > A minimum would be for a developer to adopt the same conventions > demonstrated in a source that they are changing. > Mixed coding styles within a single source file... > I have nothing (polite) to say about that. code listed above wrote by me and adopded to the style I saw around... another peace of code I fix later was in other style -- IT IS VERY HARD to switch coding style on the fly... 8() It is like context switches vs. long jumps ... if you understand that I'm talking about... > > > # absence of API docs force developer reinvent (+ test/debug time) > > code/function/classes which is possible already exists in project... so > > code reusing among developers == almost __zero__ > > Good point. > Coding is one of those things that is easy to "learn as you go" - and > self taught skills are very rewarding. Documenting what you have > written isn't as much fun - but it does illustrate what you think of > your own work. > Of couse there is no need to documenting 'hello world' program if you have no plans to make it public... BUT IMHO it highly recommended when: # distributed team -- to explain idea implemented in cryptic-looking code... :) Even if the only coding style in team some algorithms (especially parallel and distributed) not so easy to undestand by reading code w/o comments... BTW, doxygen (good documenting tool) support PHP... > The simpler solution is to just update the PDF manual, take out that list > of possible uses and put in a "We really don't take what we do seriously, > neither should the user." > ... and soon tiki will be just developers toy -- i.e. all tiki users == tiki developers :)) -- or even 'not gt' instead of '==' :)) IMHO it is strange when 34 mans playing with one toy :) When I join to team I think 'bout making Tiki bugs less and sometimes even more better (of couse I should like that I do)... IMHO if you starting any public project w/o thoughts 'bout world domination :) you never rich anything good/great... better to start nothing... :))

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 12:31 On Tuesday 01 July 2003 06:38 am, Luis Argerich wrote: > > So compare your project against GNU/GCC - > > Then decide if you want to build a solid open-source project. > > It is a matter of choice, all up to the active developers. > > Mike > > Why compare? we don't need to compare Tiki, we do this because we like it > Not compare Tiki, Compare policies, practices, stability of releases, response of developers to user reported problems, ... > and because we > believe that the effort of many developers can be combined to create an > application that can > be useful to some number of people. > What number? Small? Large? What people? Technical background only? In what environment? Private? Public? Mixed? Useful? For what? The subject here is the Project. Not the application that it develops. Mike > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 12:36 On Tuesday 01 July 2003 07:22 am, zaufi wrote: > On Tuesday 01 July 2003 04:06, Michael S. Zick wrote: > > > That's right... __BUT__ > > > # absence of coding standars make source looks like abomination :() -- > > > It is __real__ clog (at least for me) to read the code... > > > > Good point, > > If you can't read it - how can you fix it or extend it? > > Oops.. I guess my English too bad -- it never was my strengh side :(( > No matter, much better than my Russian. I think we agree on many of the basics. Mike > I mean that reading such code add some kind of difficulty ... > I'm still not found in Tiki source that looks like C++ style I (and team > where I works) use... :) For example, how do you like this: > > $litype=substr($line,0,1); > if ($litype=='*'||$litype=='#') { > $listlevel=$this->how_many_at_start($line,$litype); > $liclose='</li>'; $addremove=0; > if ($listlevel<count($listbeg)) { > while($listlevel!=count($listbeg)) > $data.=array_shift($listbeg); if(substr(current($listbeg),0,5)!='</li>') > $liclose=''; } elseif($listlevel>count($listbeg)) { > $listyle=''; > while ($listlevel!=count($listbeg)) { > array_unshift($listbeg,($litype=='*'?'</ul>':'</ol>')); > if ($listlevel==count($listbeg)) { > $listate=substr($line,$listlevel,1); > if(($listate=='+'||$listate=='-') > &&!($litype=='*'&&!strstr(current($listbeg),'</ul>') > > || $litype=='#'&&!strstr(current($listbeg),'</ol>'))) { > > $thisid='id'.microtime()*1000000; > > can it be named good style? IMHO NO! All in this style designed to make > cryptic-looking unreadable source code... > > > For a starting point, check Chapter 4 of your PEAR documentation. > > I don't agree with those standards myself, but it is a document > > which is available to all which could be adopted in whole or part; > > with or without modification. > > of couse yes... we r free to change anything :) But my opinion that team > __must have__ some type of coding standarts... > > > Lacking any agreement in this area, sense it is usually very personal... > > Initialy all members have personal coding style, but when styling rules > approved in team after 2 weeks it become your nature.... -- 'bcouse all > members agreed (less or more) with every point of coding standarts ... > -- and you will got difficulties when read you old code :) > > > A minimum would be for a developer to adopt the same conventions > > demonstrated in a source that they are changing. > > Mixed coding styles within a single source file... > > I have nothing (polite) to say about that. > > code listed above wrote by me and adopded to the style I saw around... > another peace of code I fix later was in other style -- IT IS VERY HARD to > switch coding style on the fly... 8() > It is like context switches vs. long jumps ... if you understand that I'm > talking about... > > > > # absence of API docs force developer reinvent (+ test/debug time) > > > code/function/classes which is possible already exists in project... so > > > code reusing among developers == almost __zero__ > > > > Good point. > > Coding is one of those things that is easy to "learn as you go" - and > > self taught skills are very rewarding. Documenting what you have > > written isn't as much fun - but it does illustrate what you think of > > your own work. > > Of couse there is no need to documenting 'hello world' program if you have > no plans to make it public... > BUT IMHO it highly recommended when: > # distributed team -- to explain idea implemented in cryptic-looking > code... > > :) Even if the only coding style in team some algorithms (especially > : parallel > > and distributed) not so easy to undestand by reading code w/o comments... > > BTW, doxygen (good documenting tool) support PHP... > > > The simpler solution is to just update the PDF manual, take out that list > > of possible uses and put in a "We really don't take what we do seriously, > > neither should the user." > > ... and soon tiki will be just developers toy -- i.e. all tiki users == > tiki developers :)) -- or even 'not gt' instead of '==' :)) > > IMHO it is strange when 34 mans playing with one toy :) > > When I join to team I think 'bout making Tiki bugs less and sometimes even > more better (of couse I should like that I do)... IMHO if you starting any > public project w/o thoughts 'bout world domination :) you never rich > anything good/great... better to start nothing... :)) > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: Dev-Tiki? Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Dave Sanders <dsanders@st...> - 2003-07-01 12:39 Michael S. Zick wrote: >On Monday 30 June 2003 07:01 pm, Tex wrote: > > >>Do you think it might be a good idea to put up a wiki for the developers? >>as a place to collaboratively sort out priorities, problems, roles, design >>principles and goals? As a starting point for an dev/api documentation? >> >>Maybe it might even make sense for the users too. >> >> >> >Very good suggestion. >It makes a lot of sense for developers also. >Nearly everything mentioned in this thread could be >dealt with in a (tiki-)wiki. > >Doesn't it make sense that the people who write it >should also use it? > >Mike > I wholeheartedly concur. Its come up a couple times on this list in the past month, but I think it would be a really good idea to use Tiki as a collaborative development environment. Luis was afraid, I think, that setting up another infrastructure would consume too many people that could be contributing directly to the development of the project though. I've been thinking about this, and think that maybe there are enough people now that setting up a 3 member "Infrastructure Team" might not be a bad idea. All 3 people would be responsible for setting up and maintaining the dev and demo site infrastructures and prodding everyone else to use it. Having more than 1 person will help make sure that even when someone gets busy, the environment is still being fed and watered... my 2 cents anyway. Part of my reason for this is selfish, because I need just this sort of thing at my work, and am in charge of getting together some process and planning tools to help manage our development processes. I think Tiki would bring a lot to the table, but now I just need to find the time to get it set up. I think that if the dev group used and maintained a tiki for all dev work, discussion, bugs, feature voting, etc that we'd also learn a lot about the shortcomings and bugs that we would find in the day to day, more long term use. Also because I think that SourceForge, for all its goodness and features for the OSS community, is still a pretty immature product as far as the day to day software development project management goes. The trackers are just a hair above pointless in my book. :) Which reminds me: All, I apologize for not enacting the bug categories and getting RFE categories and individual RFE's sorted out. Its annual review time here at work, and I have to write and conduct reviews for 20 odd software developers, so my time recently has been limited. I'm very much shooting for this fourth of july weekend to try to get stuff at least set up so that we can sort everything out, but it may not happen. Trying my best. (would still like some feedback on my email previously about the RFE's and what we should use the "groups" for on them...) man, I hate it when I start out a short email, and it turns into war and peace... sorry. :) D

Re: Dev-Tiki? Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 13:00 On Tuesday 01 July 2003 07:39 am, you wrote: > Michael S. Zick wrote: > >On Monday 30 June 2003 07:01 pm, Tex wrote: > >>Do you think it might be a good idea to put up a wiki for the developers? > >>as a place to collaboratively sort out priorities, problems, roles, > >> design principles and goals? As a starting point for an dev/api > >> documentation? > >> > >>Maybe it might even make sense for the users too. > > > >Very good suggestion. > >It makes a lot of sense for developers also. > >Nearly everything mentioned in this thread could be > >dealt with in a (tiki-)wiki. > > > >Doesn't it make sense that the people who write it > >should also use it? > > > >Mike > > I wholeheartedly concur. Its come up a couple times on this list in the > past month, but I think it would be a really good idea to use Tiki as a > collaborative development environment. Luis was afraid, I think, that > setting up another infrastructure would consume too many people that > could be contributing directly to the development of the project > though. I've been thinking about this, and think that maybe there are > enough people now that setting up a 3 member "Infrastructure Team" might > not be a bad idea. All 3 people would be responsible for setting up and > maintaining the dev and demo site infrastructures and prodding everyone > else to use it. Having more than 1 person will help make sure that even > when someone gets busy, the environment is still being fed and > watered... my 2 cents anyway. > Shouldn't be hard - you don't need a "How to set up for XXXX use" You have all the knowledge of the authors available. Put up anything... Somebody will see the feature they added and point out how it should be optioned to work for this purpose. > Part of my reason for this is selfish, because I need just this sort of > thing at my work, and am in charge of getting together some process and > planning tools to help manage our development processes. I think Tiki > would bring a lot to the table, but now I just need to find the time to > get it set up. I think that if the dev group used and maintained a tiki > for all dev work, discussion, bugs, feature voting, etc that we'd also > learn a lot about the shortcomings and bugs that we would find in the > day to day, more long term use. > Nothing wrong with that - when it gets close to what you need, dump the preference and option settings then import them into yours. > Also because I think that SourceForge, for all its goodness and features > for the OSS community, is still a pretty immature product as far as the > day to day software development project management goes. The trackers > are just a hair above pointless in my book. :) > During the early days of SF, development was rapid - but the "SourceForge Idea" drew should a large number of users - they had to pick some point at which to stablize the user interaction. Instead of API of it as a UPI. > Which reminds me: All, I apologize for not enacting the bug categories > and getting RFE categories and individual RFE's sorted out. Its annual > review time here at work, and I have to write and conduct reviews for 20 > odd software developers, so my time recently has been limited. I'm very > much shooting for this fourth of july weekend to try to get stuff at > least set up so that we can sort everything out, but it may not happen. > Trying my best. (would still like some feedback on my email previously > about the RFE's and what we should use the "groups" for on them...) > > man, I hate it when I start out a short email, and it turns into war and > peace... sorry. :) > No matter. Your comments are all constructive. Not any worse than throwing fuel on a pile of dry leaves only to learn they where covering a smoldering fire. Mike > > D > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

[Tikiwiki-devel] Re: Best Step Fprward [Was About Fish] From: Mark Limburg <mlimburg@ip...> - 2003-07-01 14:02 Howdy, Here at work, we use core business systems. Without them, we die. So, we have three phase systems for business critical systems. We want to adjust something in these systems, then we use three phase system: DEV TEST PRODUCTION We want to implement something, we put it in DEV, and see how it flies .. DEV is a general system .. if it looks good .. then we put it in TEST which is the same as DEV, but with REAL data, as if it's the real world. If it works (with many tests) then it's assessed, signed off, and implemented into PRODUCTION. With backups in action. We should implement this into Tiki .... SOMEHOW .... Ahhh, don't worru about me .. I've had too many glasses of red wine, and I'm still thinking about how Tiki can best rule the world M

Re: [Tikiwiki-devel] Re: Best Step Fprward [Was About Fish] From: Michael S. Zick <mszick@go...> - 2003-07-01 15:53 On Tuesday 01 July 2003 09:04 am, Mark Limburg wrote: > Howdy, > > Here at work, we use core business systems. Without them, we die. So, > we have three phase systems for business critical systems. We want to > adjust something in these systems, then we use three phase system: > > DEV > TEST > PRODUCTION > > We want to implement something, we put it in DEV, and see how it flies > .. DEV is a general system .. if it looks good .. then we put it in TEST > which is the same as DEV, but with REAL data, as if it's the real world. > If it works (with many tests) then it's assessed, signed off, and > implemented into PRODUCTION. With backups in action. > > We should implement this into Tiki .... SOMEHOW .... > Enable the "Workflow Engine" (When available) Mike > > Ahhh, don't worru about me .. I've had too many glasses of red wine, and > I'm still thinking about how Tiki can best rule the world > > M > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Michael S. Zick <mszick@go...> - 2003-07-01 16:32 On Monday 30 June 2003 05:54 pm, you wrote: > On Tuesday 01 July 2003 01:06, mose wrote: > > le Mon, Jun 30, 2003 at 01:22:13PM -0700 par Tony Colley : > > > > There are so many short comings that are based on poor project > > > > planning, leadership, standards, practices - that it will never > > > > succeed as a practical, real-world, application. > > > > It will remain a developers toy of eye-candy and bag of showoff > > > > coding. > > > > > > Actually, I *am* using it as a practical, real-world, application. > > > > - same here. > > I have 2 working servers -- both inside intranet -- and 3 for > tests/development: Internet public, home computer, notebook :) > > > And strong leadership is made for army. In free software we use > > collaboration rather. > > That's right... __BUT__ > # absence of coding standars make source looks like abomination :() -- It > is __real__ clog (at least for me) to read the code... I would suggest using: tiki/lib/webmail/htmlMimeMail.php as a good style to adopt. Mike > I (PHP newbie :) see that PHP have C-like syntax, but have no C-like coding > rules -- PHP code (I saw in TIKI) looks awesome... :) > # absence of API docs force developer reinvent (+ test/debug time) > code/function/classes which is possible already exists in project... so > code reusing among developers == almost __zero__ > # absence of some (even brief) architecture/internals overview prevent new > developers be rapid involved into development cycle... -- it is real hard > to track whats going on in not so small system like TIKI become :) > > to implement 1 and 2 collaboration is highly required :) -- but as KDE team > shows it can be achieved :) -- (2500 members and more than 650M source > code) > > I'm agree that TIKI for most of us is a eye-candy but after some high level > of entropy system should be transformed to next level of order to keep > continuity... Isn't it? :) > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: mose <mose@fe...> - 2003-07-01 17:01 le Tue, Jul 01, 2003 at 07:28:33AM -0500 par Michael S.Zick : > On Tuesday 01 July 2003 06:38 am, Luis Argerich wrote: > > > So compare your project against GNU/GCC - > > > Then decide if you want to build a solid open-source project. > > > It is a matter of choice, all up to the active developers. > > > Mike > > > > Why compare? we don't need to compare Tiki, we do this because we like it > > > Not compare Tiki, > Compare policies, practices, stability of releases, response of developers > to user reported problems, ... > > > and because we > > believe that the effort of many developers can be combined to create an > > application that can > > be useful to some number of people. > > > What number? Small? Large? > What people? Technical background only? > In what environment? Private? Public? Mixed? > Useful? For what? > > The subject here is the Project. > Not the application that it develops. - you mistake heavily. Each of us have project (small, large, private or public), our common point is only the application. mose > > Mike > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are available now. > > Download today and enter to win an XBOX or Visual Studio .NET. > > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > > _______________________________________________ > > Tikiwiki-devel mailing list > > Tikiwiki-devel@... > > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: zaufi <zaufi@se...> - 2003-07-01 17:18 On Tuesday 01 July 2003 20:28, Michael S. Zick wrote: > > I would suggest using: > tiki/lib/webmail/htmlMimeMail.php > as a good style to adopt. > Agree ... at 1st real TABs should be replaced with spaces and count less than 8 :) I'm wondering to see doxygen ready source :))

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Luis Argerich <luis@fu...> - 2003-07-01 17:24 The Galaxia libraries do have Doxygen documentation inlined and the docs can be found in lib/Galaxia/docs ----- Original Message ----- From: "zaufi" <zaufi@...> To: <tikiwiki-devel@...> Sent: Tuesday, July 01, 2003 2:18 PM Subject: Re: [Tikiwiki-devel] Goodbye and thank you for the fish > On Tuesday 01 July 2003 20:28, Michael S. Zick wrote: > > > > I would suggest using: > > tiki/lib/webmail/htmlMimeMail.php > > as a good style to adopt. > > > Agree ... at 1st real TABs should be replaced with spaces and count less than > 8 :) > > I'm wondering to see doxygen ready source :)) > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > Tikiwiki-devel mailing list > Tikiwiki-devel@... > https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel >

Re: [Tikiwiki-devel] Goodbye and thank you for the fish From: Ross Smith <ross@sm...> - 2003-07-01 20:39 Quoting zaufi <zaufi@...>: > I'm wondering to see doxygen ready source :)) http://ez.no/sdk has excellent doxygen generated documentation. You'll need to download the source. -Ross

2 messages have been excluded from this view by a project administrator.

Next Messages