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