Hi, Now, it is clear how Qooxdoo product is managed, thanks to previous clarification. I think it has to be done.
If I go back to my first participation on that thread, I said I would like user base to increase and try to propose some points to do that. If I understood correctly what Thomas said, your pretty much satisfied with 1&1 internal demand. So, user base won't really increase. What can I do ? Nothing more I'm afraid. Nothing to add on that point which is my main concern about Qooxdoo. On the user participation, one could think that including more user to the decision (make them feel they are part of the game) might increase participation but I'm not sure. As a counter example, there already contrib. Also, there may be a more general phenomenon : I choose Qooxdoo for not having to handle HTML and browser by myself. This is possible only because Qooxdoo do it for me, which I think is one main Qooxdoo goal. This has a consequence : to participate to Qooxdoo core, I need to know what I try not to know. That may explain lack of certain type of participation. Participation need to be split : 1. core : do not expect big participation here for the reason given before 2. help : help on mailing list, help on doc, wiki, bugbase, ... this maybe could be improved, I don't know how ... [There was a 3. marketing but I cut it to shorten the email] ;-) 4. contrib : help by giving code to Qooxdoo community. This could be improve by organizing contribs, creating a committee where people is in charge or sorting out contribs, attach to them a state (mature to young), test (does it work with latest Qooxdoo version, ...) I think this committee should not be 100% 1&1. Maybe 50% 1&1 and 50% community. That CC (Contrib Committee) should also be structured in area of expertise of its member. * area1 : widgets (HTMLArea and others, ...) * area2: : build, IDE, ... (qxbuild, qxtransformer, ...) * area3 : backends * area 3 subareas by techno : PHP, js, Lisp, Java, ... I'm volunteer for area 3 Java subsection. CC would also need : * a specific mailling list * a decision process (like Apache incubator -> ... -> ... -> main validated project) * 3 to 5 people taken from CC and maybe elected by CC members for 1 year. There need to be some people "in charge" if that has to work efficiently. On a more technical point of view, including a contrib is still too complicated and risky for users : * what happen when Qooxdoo deliver a new version ? * how do I know a new contrib version is done ? => something like linux apt for contrib would be great. * contrib state (working, experimental, ...) , what a contrib is doing, lack of doc, ... can be hande by contrib committee. My 6 cents :-) Qooxdoo power, JBB. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
