Hi Everyone, I haven't contributed to the discussion on this list yet. But I think Stephen's new approach is more promising than the one we had before (if there was one beyond Stephen writing P5EE::Blue and driving the discussion on this list; I don't mean to offense anyone, just seems like this to me as an innocent bystander).
> >What do you think that can be achieved in smaller groups that can't be > >achieved in this group. What problem(s) do you think the smaller > >groups fix that this group has? I'd appreciate a one or two paragraph > >answer on this. > Q. What problem(s) do you think the smaller groups fix? > A. Smaller groups can reach the level of unity necessary to get > something (anything!) done. Although I agree to Greg, that enterprise perl development could use some more marketing, I think that smaller groups are more efficient when it comes to a P5EE system or framework, and would produce solutions faster, as their problem space is smaller. Maybe if the people in these groups would just have to provide a simple wrapping layer, then there would be some work done. Nobody has copious free time to drive P5EE development. So if the amount of work would be small, by having to maintain only a small codebase and having to support only a very specialized user community, I think more people would commit time to P5EE development. But instead of just asking, who wants to form or start such a small group, we could work out some "starting" groups. They should go further than just mapping to one component from the component page (http://www.officevision.com/pub/p5ee/components.html), as "outsiders" would still ask the question: "how does this all fit together?" Although I must confess, that I don't have an idea how groups could be formed. Benjamin
