[Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)

[Tim Sutton]

-----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
> <nyall.dawson at gmail.com> wrote:
>> 
>> On 23/08/2014 3:33 am, "Even Rouault"
>> <even.rouault at spatialys.com> 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 Qgis-developer at lists.osgeo.org 
> 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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tim.vcf
Type: text/x-vcard
Size: 213 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140825/3c8aafb3/attachment-0001.vcf>