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