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

[Vincent Picavet]

Hell,

> 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 ?

As Marco said, and as it always has been the case in the QGIS project, the PSC 
vote should only be a confirmation of the community advice.
If the PSC vote is contrary to the general community agreement, then we have a 
problem with the PSC itself. It never has been the case AFAIK.
If the community do not generally agree, then there is a problem with the QEP, 
and it has to be either refined, or changed.

> Surely better could be have a +1 explicit from the PSC menbers on the
> docs before start the work.
The PSC is there to validate the community advice, based on the expertise of 
the latter. If you want to have a sense of agreement before writing a RFC, 
then ask the community.

> And how PSC vot need to say that the RFC is accepted ?
I think the QEP should be officially proposed to the PSC by the original author, 
and the PSC will have a certain amount of time (say 1 week ?) to vote.
This vote should reflect the community advice.
A lack of vote in the given time should lead to QEP validation.

> 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.

Once again, the PSC vote should only be a validation of the general community 
advice. The required technical competences are in the community at large, and 
the PSC knows to trust the community.

> 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.

Then the funder hires a QGIS developer to follow the RFC and make report. 
That's my scenario 3.

Hope this clarify your questions. Others, do not hesitate to fix my 
understanding of the process if I am mistaken.

Vincent

> 
> 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