<p dir="ltr">What mean "the community dont agree" ?<br>
More explain.<br>
If 3 or 4 user community say "no" or "ask different solutions" . It is the community think ?</p>
<p dir="ltr">I guess the PSC should not ne only a simply executor of the community think, but  the real director of the project.<br>
Often the community think a thing bit thw more strategic solution is another.<br>
I guess the server side is always minority on user interest. And often the user font understand what is a server question.<br>
So the community never choose a server solution.<br>
This mean in the medium time to split the qgis in two distincts products.<br>
Desktop and server.</p>
<p dir="ltr">Every one with its own community.</p>
<p dir="ltr">My 1 ct.<br>
:)<br>
</p>
<div class="gmail_quote">Il 25/ago/2014 11:35 "Tim Sutton" <<a href="mailto:tim@kartoza.com">tim@kartoza.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi<br>
<br>
On 25/08/2014 07:42, Martin Dobias wrote:<br>
> On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson<br>
> <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br>
>><br>
>> On 23/08/2014 3:33 am, "Even Rouault"<br>
>> <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>
>>><br>
>>> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :<br>
>>>> - Who can vote? PSC only (GDAL) / committers<br>
>>><br>
>>> With GIT, 'committers' can be anyone. You probably meant folks<br>
>>> who have push rights in official repo ? If you give them voting<br>
>>> rights, and potentially veto right (not sure how the rules of<br>
>>> the voting system of QGIS are), then they are defacto PSC<br>
>>> members, since they can steer the direction of the project.<br>
>>> Not saying this is bad. Just a consequence.<br>
>>><br>
>><br>
>> I'd say neither psc nor commit rights are a good fit. While I<br>
>> agree that the psc should definitely have a say, not everyone on<br>
>> the psc is a developer or has c++ coding experience. Similarly,<br>
>> we have people who have commit rights who are neither developers<br>
>> nor psc members.<br>
><br>
> I had the same impression as Nyall. PSC is meant to steer direction<br>
> of the whole project, not to deal with technical details of<br>
> implementations in QEPs - after all, only 3 out of 7 positions are<br>
> meant for developers. At the same time I understand that creating<br>
> another "developer" committee would make things more complex.<br>
><br>
><br>
> I think that voting on QEPs could be started when the QEP's author<br>
> has impression that enough consensus was reached. Most projects<br>
> also allow their RFCs to go to 'deferred' state if the proposal is<br>
> too controversial.<br>
><br>
><br>
>> Since a big part of the qep would be commenting on proposed<br>
>> technical architecture, I think its fairly important that<br>
>> developers have a good say in the process. But conversely if the<br>
>> qep process determines the direction of QGIS, then non devs on<br>
>> the psc should also have a say.<br>
><br>
> Originally I thought that only new functionality would be covered<br>
> by QEPs, but it is actually quite useful to have one common process<br>
> for any significant changes in the project - ranging from<br>
> development stuff through infrastructure changes to organizational<br>
> changes (like introduction of trademark). So it makes sense to have<br>
> PSC vote on QEPs.<br>
><br>
<br>
So my 2c:<br>
<br>
- From the PSC point of view the intention is that the PSC facilitate<br>
teams to work on specific areas e.g. documentation team, UX team etc.<br>
I think RFC's would probably come under Marco's remit (PSC: Code Manager).<br>
<br>
I don't think it is necessary for the whole PSC to be involved unless<br>
Marco wants help. So the normal modus operandi would be:<br>
<br>
* Marco forms an RFC review team<br>
* People submit RFC's<br>
* Review team accepts or denies the RFC's<br>
* PSC is available to resolve any disputes that may arise or aid in<br>
decision making where review team feels the impact on the project is<br>
broad.<br>
<br>
Regards<br>
<br>
Tim<br>
<br>
><br>
> Regards Martin _______________________________________________<br>
> Qgis-developer mailing list <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
<br>
- --<br>
- ------------------------------------------------------<br>
<br>
Tim Sutton<br>
Visit <a href="http://kartoza.com" target="_blank">http://kartoza.com</a> to find out about open source:<br>
 * Desktop GIS programming services<br>
 * Geospatial web development<br>
 * GIS Training<br>
 * Consulting Services<br>
Skype: timlinux Irc: timlinux on #qgis at <a href="http://freenode.net" target="_blank">freenode.net</a><br>
Tim is a member of the QGIS Project Steering Committee<br>
- ------------------------------------------------------<br>
Kartoza is a merger between Linfiniti and Afrispatial<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
<br>
iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02<br>
AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr<br>
=/Cer<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div>