Re: some action

Hello Lukas, Action is good! You know PEAR is becoming somewhat.. dried during last year. =) Some brainstorming on the issue and.. BTW, is there anybody who is able to provide a report what have changed in PEAR for 2004? My preliminary apologizes, since I've noticed that my personal writing style sometimes leads to FUD accusations. Again - this letter is not intended to offend someone and doesn't contain any personal claims. I'm not one of PEAR developers and every "you" in my letters often denotes PEAR in general. Please take this into account. I'm not englishman, so if you would like to teach me - I will gladly help you. =) LS> Once we have the wiki up. We should define rules on how documentation LS> should be written in the wiki. Preferably in a manner that will allow us LS> export to docbook (immediatly or eventually). Perhaps I misunderstood idea again, but this is my general POV on the issue. Organization efforts are good, but since we are all programmers and technicians - it is better to make some technical solutions first for wiki 2 docbook conversion, for example. Rules are rules - they limit creativity and freedom. For major part of people following rules is much harder than to use existing features. From my WikiPedia and TikiWiki experience limiting wiki is not a good idea. Only if you are very strong person. =) And it is very naive to think that others will obey. =) LS> Once we have define this LS> we will make a call in pear-general for "user appreciation" or something LS> like that were we suggest that every user do one of the following for LS> every 3 packages they have used in a project recently: LS> - write a chapter on how to use a particular feature of their favorite LS> package (similar to LS> LS> http://pear.php.net/manual/en/package.database.db.intro-portability.php) LS> - write API documentation for 5 methods You can call for brainstorming, of course, but think about real motivations, what could push people to do this. From my negative side I can't think of any. The same idea but in other words: "user appreciation" will not work because this idea is alive only in the mind of several people. Hence it is dead idea. If you've made such system and nobody uses it, you can, of course, write rules and oblige others to follow it, but you will probably loose contributors that way. Wiki is good without any rules. All you need is to define general guidelines that wiki is used only as easy knowledge base system to collect info for official package documentation. By providing rules you probably limit potential contributors to only one sort of people like yourself. Wiki information refactoring for documentation quality is the job of maintainer and QA team. And because CVS access is limited to PEAR documentation group - it is their job too. :p LS> As documenting things is likely to bring up some questions or even bug LS> reports due to closer examination of special cases this will be followed LS> up by a "developer appreciation" bug hunt. Where developers can adopt LS> packts of 5 open bug reports. The bug packages will be put together by LS> the QA team and should be coherent (either on a specific package, or a LS> specific issue spanning multiple packages etc). Developers are of course LS> free to pick up more bug packs. From that description it seems that vehicle was already invented before us. It is trackers. Otherwise it is not clear for me what is "bug hunt". Again you can call for brainstorming for specific package, but since existing PEAR developers are too busy, you need to redefine rules and principles for PEAR authorship, maintaining and participation to incline towards "community" or "society" than to "individuality" or "ownership". To me you pretty much contradict trying to guard code from "others" (non-developers) and bugfix it with the help of these "others" at the same time. I feel much discomfort as being developer without direct access to CVS and from the need to fix bugs ineffectively through infinite number of bugreports, messages, "patches for the latest version" and you know - it is not very pleasant to hear that there is another dustbin for my efforts. Sad, but true. Some efforts need fast feedback or they die - that's why I think PEAR is stale. Although wiki is good as information storage it is hardly automated to provide notifications, bug status refresh and other things. It is also not a source for trustworthy information, which can be misleading and deprecated. User notes are much better this way. LS> Also lead maintainers are allowed to opt out with their packages. Those LS> who dont opt out allow the person who took up the pack to mess around LS> with the bug report etc. They dont grant that person to mess with CVS LS> though (although they may do so if they wish), so the person handling LS> the bug pack should submit patches inside the bug report. That is more interesting. What if to think about it without wiki? What is "to take bug pack"? Even now users can freely commit patches to bureporting system, where they stored for quite long time before being noticed by some sympathetic person from current PEAR developers. What problems do you want to solve with these "bug packs"? To me problem with opened bugs is in lack of contributors and not in rules deficiency. You can always make changes in separate CVS branch and merge that later. I can't see wiki role in this process. There is no even system to attach patches to bugreports and safely view them. LS> The maintain is then free to apply the patch within the regulations that LS> we set when we founded the QA team. -- anatoly