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

[Andrea Peri]

Hi Vincent,

You speak of discussion with community.
This is agreement, but the only important to be sure of the work is the
PSC agreement.
If after 2 weeks the PSC say nothing one could start with a contract
for the development ?

Surely better could be have a +1 explicit from the PSC menbers on the
docs before start the work.

And how PSC vot need to say that the RFC is accepted ?

Please note also that a community discussion could bring far from the
objective of the RFC.
And forgot that only the PSC vote are relevant to say the RFC is
accepted or not.

Another question is:

actually 4/7 of PSC are not technical.
This mean that a RFC could be approved without that any one of
technical comptents are say :
"ok it is compatible with actual QGIS, it don't break anything".
Or evalute if what is potentially breakable is reasonable or not.

My dubt is infact.  A compatibility break is a technical question ?
I guess potentially no, because it is more on QGIS usability , but is
technical when
start to say:

hey using this solution you break the past, instead if you use this
other solution you don't break the past.

Is not simply to evaluate this question, and without a QGIS developer
expert is not easy to follow a RFC for a funder.

A.

2014-08-25 10:54 GMT+02:00 Vincent Picavet <vincent.ml at oslandia.com>:
> Hi Andrea,
>
> First of all, I tend to agree with Marco, where QEP should be voted when there
> is a general agreement on them. The PSC voting should therefore be enough.
>
> As for you question about QEP vs funders.
>
> Le lundi 25 août 2014 08:41:29, aperi2007 a écrit :
> [snip]
>> Also, AOAIK an important question is undrstand the limit of a RFC.
>> Infact don't forget that the main enhancement are always covered by one
>> or more funders.
>>
>> Tipically they ask an enhancement with some request themself.
>>
>> This RFC in the QGIS world is obviously after the real fund phase where
>> the funders find the developer and contract him.
>> So what mean that the RFC is submittable to the PSC ?
>> If the PSC to accept the RFC required more changeables and these
>> changeable require more fund, what happened ?
>>
>> Or this RFC could be submitted before to find the developer and fund him ?
>>
>> In this second situation, the RFC should be submited from the funders ?
>
> What should happen is one of the three following scenarii :
>
> * The funder works with a contractor which knows QGIS and the QEP process well
> enough to guarantee to the funder that the QEP will pass as-is, for the
> originally proposed amount. In this case, the contractor takes the risk.
>
> * The funder provides the QEP and makes the discussions with the community
> until a general agreement is reached. Then the funder finds a company/developer
> to pass a contract for the development phase.
>
> * The funder makes a first contract with a company/developer, to write the QEP
> and reach an agreement (or not). Once the QEP status is set (voted as is,
> voted modified, deferred, rejected), the funder can pass another contract with
> this company/developer (or another) to implement the QEP.
>
> Vincent
>
>>
>> Thx,
>>
>> Andrea.
>>
>> Il 25/08/2014 07:42, Martin Dobias ha scritto:
>> > 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.
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------