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

[Vincent Picavet]

Le lundi 25 août 2014 11:42:12, Vincent Picavet a écrit :
> Hell,

I meant "Hello", of course, no offence :-/
v.

> 
> > 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
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer