Re[2]: [PEAR-CORE] Re: [pear-webmaster] Re: cvs: pearweb /public_html/trackback trackback-admin.php

||*()*|| [\..konnichi wa, ogenki desu ka, Greg../] >> HÞ> Are you trying to keep the webmaster team intact or what ? Seriously, we >> HÞ> are not that many that we can just put some month probation on each other, >> HÞ> at the best we are 5 all in all that do anything and it's every now and >> HÞ> then that any one of those 5 actually has time, it's hard enough to get >> HÞ> people to work on PEAR code but the pearweb code, that's almost >> HÞ> impossible, keep that in mind and rethink that policy. >> >> +1 >> >> And in addition I'd suggest not only to rethink _that_ policy, but >> think about _real_ collaborating model of PEAR in comparison to other >> Open Source projects. The best way, Greg, is to start writing report >> excluding all ideologic and promotion PR, and including only bare >> facts about PEAR problems. Attempts to skip them will make the things >> only worse. GB> Anatoly, you are unbelievable. All you do is write ideological crap. Yes. I'm good at this. =) And moreover I believe that this crap can help PEAR a lot, because that is the power what made open source. GB> I proposed a step-by-step method of eliminating the constant issue of GB> worrying about breaking pearweb. What do you propose? I don't see GB> anything but fluff. Try again. Ok. I try to concentrate very hard and not to miss the point. First of all like any developer I do not like my efforts to be wasted and this letter is not an exception. I do not want it to be lost in space of everyday ML traffic and perhaps flag it for someone who is concerned with the same problem. The same thing is true for every effort made by open source developers, since it is the main motivation in the absence of funding - make this world better or ease their everyday programming tasks. Like any deal this activity requires some resources and most precious of it is time. Time is the biggest problem for open source developers and is the main reason of everything negative in open source. Time in open source development can be divided into two major categories: I. Time required to start with the project development II. Time required to keep with development process First category includes reading project startup documentation, setting up build environment, learning current project state. Second consists of learning and using to common practices within the project to carry on with every day development tasks. These practices include ways to communicate, to get/provide support, to release code, to elaborate on decisions and project planning. The big part of this category is support activities. The more complex the project becomes the more resources it needs. Analysis of these factors will help to understand key factors of PEAR ineffectiveness and consider which major changes has to be made to it infrastructure at first to help fostering development. Now take a PEAR as an example and look deeper into the problem. Let's call the above categories of time TimeI and TimeII Current state of business with PEAR is that core PEAR developers are fully at support and the worse that PEAR lacks core contributors. Support is not the thing everybody likes, because it means dealing with the code, which was a mistake at the first place or become a pain over time. PEAR developers made an ambitious task to lift the burden of support and develop infrastructure at the same limited time. PEAR even has a QA team, but is it really useful? Yes, they gained access to everything, they had this helped much? I ask you, because I really do not know and very interested to read a report from that team about the progress being made since it's creation. PEAR core developers are the main and only support power, but at the same time they are the only main HEAD branch developers. TimeI to become core developer includes reading all prerequisites to become a ordinary PEAR developer including package proposal and release, but more than that it includes a tons of code nobody is willing to start maintaining (pearweb), because everybody will prefer to rewrite it from scratch. TimeII requires even more activities connected with support of your package plus active PEAR ML and/or IRC participation. TimeI and can be reduced by providing more visibility in PEAR infrastructure. TimeII can be reduced by providing more visibility into PEAR process. Now you may start to read my previous letters. Everything I need to say further was already mentioned. I bet you do not have time or do not know what to look for. That is what I call poor visibility. TimeI consists of studying information what is obvious to someone who already PEAR developer, but is obscure to newcomers. If this time is bigger than man can allow himself to acquaint with PEAR - he will loose interest until better time or forever. Increasing visibility means reports and articles about PEAR infrastructure in it's current state and in future. Detailed roadmaps and roles of persons involved. Even of the person will decide to became PEAR developer and release a package there will be the moment when the TimeII begins. At this stage (s)he needs to be highly motivated to keep up with support and PEAR infrastructure. (sorry - i'm getting tired for the day and tomorrow i won't be able to finish this letter, so i intentionally left some key moments and moved to bad examples) The main problem at this stage is that it seems that PEAR is not a team, but a bunch of developers, who doesn't have any responsibilities to other team members. It might be wrong, but this isn't visible for people who don't have time to read MLs. Everything above was about the time one needs to become a PEAR developer. Now it will be good to speak about motivations. These are: a. Personal ambitions b. Coding challenges c. Commercial business d. Professional environment Although these make the best effect in combination, to ease with analysis I'll single out only four types of persons. To tell the truth d.motivation is a necessary part for every previous person types, but there are people who are motivated only by the d.factor. (i'll be short from now on) I'm the type a., because I believe there is something in my head that doesn't seems ok for the people, but in proper environment can be more than welcome and good for me. =) Ok, let be serious. My motivation are: - something to prove for myself - experience - fun - appreciation - authorship visibility PEAR limits 3/5 To the person of type b. motivations: - reduce burdens of future work - easy development process - limited user support - experience - appreciation - authorship visibility PEAR limits 3/6 To the person of type c. (Dan C.): - get the name where possible - reduce burdens of future work No PEAR limits. Person of type d. - communication - fun - experience No PEAR limits. To finish this one of the actual problems of PEAR for now is that original authors are not respected as due and maintainers and leads are substituted instead. This letter is rather complete "phase one" in agile development or "full circle" aizen. I hope it will be of interest to consider and provide some ground for further analysis and solutions. =) Some notes for myself about things and their importance I didn't mentioned due to a lack of the precious time and rather tired condition to explain them carefully * lack of feedback as requirements for future work - polls * PEAR restrictions and freedom of open source self-expression * importance of ideal objectives in real world * the border between PR and lies * look from outside * project refactoring problems in PEAR * QA meaning * more about kaizen WBR.techtonik -- (B)uilding, (A)ntenna, (S)pan and (E)arth * terminal velocity - 54m/s, 305m *