-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi
On 25/08/2014 07:42, Martin Dobias wrote: > On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson > <[email protected]> wrote: >> >> On 23/08/2014 3:33 am, "Even Rouault" >> <[email protected]> wrote: >>> >>> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit : >>>> - Who can vote? PSC only (GDAL) / committers >>> >>> With GIT, 'committers' can be anyone. You probably meant folks >>> who have push rights in official repo ? If you give them voting >>> rights, and potentially veto right (not sure how the rules of >>> the voting system of QGIS are), then they are defacto PSC >>> members, since they can steer the direction of the project. >>> Not saying this is bad. Just a consequence. >>> >> >> I'd say neither psc nor commit rights are a good fit. While I >> agree that the psc should definitely have a say, not everyone on >> the psc is a developer or has c++ coding experience. Similarly, >> we have people who have commit rights who are neither developers >> nor psc members. > > I had the same impression as Nyall. PSC is meant to steer direction > of the whole project, not to deal with technical details of > implementations in QEPs - after all, only 3 out of 7 positions are > meant for developers. At the same time I understand that creating > another "developer" committee would make things more complex. > > > I think that voting on QEPs could be started when the QEP's author > has impression that enough consensus was reached. Most projects > also allow their RFCs to go to 'deferred' state if the proposal is > too controversial. > > >> Since a big part of the qep would be commenting on proposed >> technical architecture, I think its fairly important that >> developers have a good say in the process. But conversely if the >> qep process determines the direction of QGIS, then non devs on >> the psc should also have a say. > > Originally I thought that only new functionality would be covered > by QEPs, but it is actually quite useful to have one common process > for any significant changes in the project - ranging from > development stuff through infrastructure changes to organizational > changes (like introduction of trademark). So it makes sense to have > PSC vote on QEPs. > So my 2c: - From the PSC point of view the intention is that the PSC facilitate teams to work on specific areas e.g. documentation team, UX team etc. I think RFC's would probably come under Marco's remit (PSC: Code Manager). I don't think it is necessary for the whole PSC to be involved unless Marco wants help. So the normal modus operandi would be: * Marco forms an RFC review team * People submit RFC's * Review team accepts or denies the RFC's * PSC is available to resolve any disputes that may arise or aid in decision making where review team feels the impact on the project is broad. Regards Tim > > Regards Martin _______________________________________________ > Qgis-developer mailing list [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > - -- - ------------------------------------------------------ Tim Sutton Visit http://kartoza.com to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net Tim is a member of the QGIS Project Steering Committee - ------------------------------------------------------ Kartoza is a merger between Linfiniti and Afrispatial -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02 AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr =/Cer -----END PGP SIGNATURE-----
<<attachment: tim.vcf>>
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
