What mean "the community dont agree" ? More explain. If 3 or 4 user community say "no" or "ask different solutions" . It is the community think ?
I guess the PSC should not ne only a simply executor of the community think, but the real director of the project. Often the community think a thing bit thw more strategic solution is another. I guess the server side is always minority on user interest. And often the user font understand what is a server question. So the community never choose a server solution. This mean in the medium time to split the qgis in two distincts products. Desktop and server. Every one with its own community. My 1 ct. :) Il 25/ago/2014 11:35 "Tim Sutton" <[email protected]> ha scritto: > -----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----- > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
