||*()*|| Hi, Sean. >> GH> Project map about what projects? >> >> Project: PHPDOC >> Subprojects: PHPDOC TOOLS, LIVEDOCS, DOCWEB, USERNOTES >> >> Project: PEAR >> Subprojects: PEARDOC, PEARDOC TOOLS, PEARWEB, PEAR AUTOMATION >> >> Project: PHP.NET >> Subprojects: DEV-MASTER-WEB, DEV-BUGTRACK, SYSTEMS-MIRRORS, SYSTEMS-CVS, >> SYSTEMS-ML, PHP-WEB, PHP-NEWS, PHP-NET-AUTOMATION or PHP-NET-TOOLS >> >> Project: PHP >> Subprojects: PHP4, PHP5, PHP6, PHP-EXTENSIONS-CORE, PHP-EMBED, >> PHP-ISAPI or PHP-INTEGRATION
+ PHP-GTK =) >> 1. Developers are not enough motivated SC> not true. SC> Developers work on what we WANT to work on, WHEN we want, unless someone SC> is paying them to work on something specific. Yep. I'd like to test second approach. SC> My instant livedocs, for example, has not evolved, primarily because: SC> lack of expressed interest from anyone but me and Goba, I haven't SC> received much feedback, I got hung up on a bug SC> (http://bugs.php.net/bug.php?id=33608), and: I've seen livedocs, but didn't understand how it works. It looks rather complicated with these shell scripts and I'm working on a windows platform. I was not sure it will work on cygwin, because I have separate locations for wwwroot, phpdoc repository and cygwin root. Me too doen't have time to read these 130k just to find out it should fill sqlite database somewhere, but that doesn't happen, because the package is still alphabuggy and cygwin/win uncompatible. You bug is a hard to solve, because it is logical mistake, but the parsing logic is unknown for me and others and we are not able to check it. There is no draft, no concept, no model, not even a glue about it - only raw PHP code. Everybody who want to help should do full logic reversing first or start from scratch. The last is what I've done with XSLT stylesheets, but I was highly motivated by new knowledge I gained about XML. >> 2. Developers don't have enough time SC> That's the big one. I'm tasked at 100% right now, with working, working SC> [sic], raising a kid, and having a new house that needs care. The same conflict I'm trying to resolve. I'd like to be more financially independent and work on PHP.NET issues at the same time, but this seems to be unreal. That's why for last half of year almost no progress has been done with CHM bugs and ToDo's. SC> A roadmap won't help, here. We'll just miss deadlines, and become MORE SC> discouraged. SC> Unless, of course, you've got a few hundred thousand dollars to start a SC> foundation and hire people to be your roadmap-deadline-meeting minions. SC> If that's the case, by all means, start it up, and recruit developers! Roadmap != deadlines. It is a list of features/bugs that should be completed before release. It gives answers to question "when livedocs will be available?" in a manner "after this, this and this bug will be fixed". It also tells what "this bug is not so important and it is planned on a next livedocs rewrite". So it is a way to map bugs and features to releases and give others possibility to check box on this buglist to speed up the release. No deadlines here. It just increases visibility of the process. This bug and feature (issue) list can be extended to include other relevant information about arising problems, provide issue-dependency links. Issue != bugreport. SC> (the foundation scenario is why roadmaps work for projects like Mozilla) SC> One thing I HAVE noticed, however, is the project-momentum phenomenon. SC> DocWeb is a perfect example. We go through commit-sprees -- someone SC> commits some changes, and then within a few days we see dozens of SC> commits.. a week later, the list is dead. Because project became too complicated and hard to maintain. The lack of planning makes further work painful patching and bugfixing leading to totally unmaintainable code. If you have a clear vision of project structure then you can always think about "how to avoid the problem in the future" in addition to "how to fix this bug right now". Given structure of the project and some basic lifecycle procedures you can - no matter how it works - you can rewrite this project in a more clear way. And collected issues can help to optimize this structure and design new approach to old problems. This is called software engineering IIRC. SC> The best way to lead, here, is to step up, do some work, and rally the SC> troops, socially. If people are motivated, and they have time, they'll SC> jump on the project and contribute. t --
