-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forking the thread into something resembling what I'd like to talk about...
On 11/12/2010 06:54 PM, Thiago Macieira wrote: >>> After discussing a bit with Cristy, we also have a plan on how to keep >>> the legal obligations satisfied without interfering too much in the >>> daily workflow. >> >> Can you please elaborate on this? > > I don't want to elaborate too much until we sit down together and check the > details. But it appears that we could work entirely in the open provided that > all the repositories and all the source code live in servers hosted by a > third > party. And that there's a way to manage the code server-side. > > Trolls and Nokians would contribute patches only, just as everyone else. That makes me happy to hear, it sounds like an ideal solution really. >> OK. I've already reopened the release thread. Are there any other areas >> you'd like to discuss in more detail? > > Any areas that didn't get enough discussion. For example, what will the power > structure be (reviewers, maintainers, admins, dictator)? We'll probably have > to have a "conflict resolution" and "tie-breaking" board, so who will be in > it? > How many? How does one get to go in there? How does someone go out of it? I'm > sure someone will suggest elections, but so who gets to vote? I think a bit more information on how you currently handle structural decisions and conflicts, etc, would probably be useful. If I personally had to set something like this up, it'd be as flat as is possible without getting horizontal. Theory being the less heirachy you involve, the less disagreements you can get, and the less overhead you have on technical decisions. I'd probably have three real 'roles' in the process: * contributor (can send patches to ML/whatever, can review) * committer (contributor, + can push reviewed patches) * facilitator (committer, + acts as a technical 'lead' for their area) the 'area' of a facilitator is something I'm not sure about but would probably be at the subsystem or module level (e.g. unicode handling or QtCore). To clarify, a facilitator would have the ability to veto decisions made in their 'area'. I really wouldn't like to include more conflict resolution than that, because I like to think that everyone contributing would be sane, and mature enough to know that they need to act in Qt's best interests. Assume good faith. If you *really* must include some bureaucracy, then maybe include a per-module 'facilitator' who can resolve conflict for their module. I don't think you need it to go further, myself. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM3ZTTAAoJEL09WxvSn7p93uMH/jMVEn0hxxuuRmy86FI35HaI 01Vd5ElepY6ht0ljekb33qk3jAiUXG6wwHjTUWpdgi8mG9c23LBCp60LD7HvtnsH PYS/bvFTrsTDPDBstfYxMVbs2BAiIGp7mCUkduVcO0Ii+e3J9gRggjJ/7GfZAONG ji5rDz89O9B9irFAQyiemFQ8egMZpc1MBHvYWHTaIUsqmbeKXBvGIdrJExYRtK1T 9rHUuQKQk7IvK8wxkXw8ccyKiDa3OgumPsNa36DpXGjo51EODQmlWcjSRtQfLB6D QeHRAOqvlB5fqoGTbazgH1NPETb6acMBal/qVNAinMQMA1nMAh4WakHc8otiMlw= =VRek -----END PGP SIGNATURE----- _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
