On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote: > [EMAIL PROTECTED] wrote: > >Ron Mayer wrote: > >>>We have not had that many cases where lack of > >>>communication was a problem. > >>One could say too much communication was the problem this time. > >> > >>I get the impression people implied they'd do something on a TODO > >>and didn't. Arguably the project had been better off if noone > >>had claimed the TODO, so if another company/team/whatever needed > >>the feature badly, they could have worked on it themselves rather > >>than waiting in hope of the feature. > > > >This is just perverse. Surely you are not seriously suggesting that we > >should all develop in secret and then spring miracles fully grown on the > >community? > > Of course not. What I'm suggesting is two things. > > (1) That misleading information is worse than no information; and > that speculative information next to TODOs can do as much harm > discouraging others as it the good it does for communication. Perhaps > a name/assignment/claim on a todo might be nice if someone wanted a > private conversation with someone who knows about a feature; but > even there wouldn't a public discussion on the lists likely be better? Yes, a name by itself is pretty useless. Having an idea of the status of that TODO item is a completely different story. If one month after claiming an item the status is "the old patch I thought would work is junk, this will need to be written from scratch, help wanted!" then clearly anyone who's interested in that item and had the ability to help would know that now was the time to step up.
Going one step further, if that item was in a system that allowed people to get emails any time status changed then *everyone* who was interested in that feature would immediately know that help was needed. I fail to see how that's a bad thing. > (2) That much corporate development on BSD projects is indeed > developed in secret. Although may want to be contributed later > either because the company no longer decides it's a trade-secret > or gets tired of maintaining their own fork. Sure, such patches > might need even more discussion and revision than if they were > designed with core - but I think it's a reality that such work > exists. I think this goes way beyond patches... there's got to be dozens of home-grown scripts to handle PITR (for one example). Granted, most of those will be rather specific to an individual environment, but if people would at least share them then someone setting up PITR for the first time wouldn't have to start from scratch. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
