<p dir="ltr">Hey,</p>
<p dir="ltr">I am still of the opinion that the PSC doesn't need to be involved in the vote unless there is a split. Most QEPs will be at a technical level and might take a bit to parse, others might not be. </p>
<p dir="ltr">It might be best to have categories or QEPs so that different groups have different votes. A QEP for say changing the bug tracking system could be voted by the PSC for example (example only).</p>
<p dir="ltr">A QEP should come after some discussion on the mailing list. Consider it a formal proposal rather then a 'what do you think of this idea'. If you are funding a project then mailing list discussion is highly recommend because creating a QEP even if you have money and a developer is no guarantee that it will be accepted. </p>
<p dir="ltr">The whole point of a QEP is to see the full idea of a proposal in one place and to make sure it will fit with the best interests of the project. Having 10 ways to do X is not and doesn't help our users.</p>
<p dir="ltr">Having QEPs might slow development in the sense that you can no longer just fund something and have it go in without objection or discussion. </p>
<p dir="ltr">Nathan</p>
<div class="gmail_quote">On Aug 25, 2014 7:42 PM, "Vincent Picavet" <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hell,<br>
<br>
> You speak of discussion with community.<br>
> This is agreement, but the only important to be sure of the work is the<br>
> PSC agreement.<br>
> If after 2 weeks the PSC say nothing one could start with a contract<br>
> for the development ?<br>
<br>
As Marco said, and as it always has been the case in the QGIS project, the PSC<br>
vote should only be a confirmation of the community advice.<br>
If the PSC vote is contrary to the general community agreement, then we have a<br>
problem with the PSC itself. It never has been the case AFAIK.<br>
If the community do not generally agree, then there is a problem with the QEP,<br>
and it has to be either refined, or changed.<br>
<br>
> Surely better could be have a +1 explicit from the PSC menbers on the<br>
> docs before start the work.<br>
The PSC is there to validate the community advice, based on the expertise of<br>
the latter. If you want to have a sense of agreement before writing a RFC,<br>
then ask the community.<br>
<br>
> And how PSC vot need to say that the RFC is accepted ?<br>
I think the QEP should be officially proposed to the PSC by the original author,<br>
and the PSC will have a certain amount of time (say 1 week ?) to vote.<br>
This vote should reflect the community advice.<br>
A lack of vote in the given time should lead to QEP validation.<br>
<br>
> Please note also that a community discussion could bring far from the<br>
> objective of the RFC.<br>
> And forgot that only the PSC vote are relevant to say the RFC is<br>
> accepted or not.<br>
><br>
> Another question is:<br>
><br>
> actually 4/7 of PSC are not technical.<br>
> This mean that a RFC could be approved without that any one of<br>
> technical comptents are say :<br>
> "ok it is compatible with actual QGIS, it don't break anything".<br>
> Or evalute if what is potentially breakable is reasonable or not.<br>
<br>
Once again, the PSC vote should only be a validation of the general community<br>
advice. The required technical competences are in the community at large, and<br>
the PSC knows to trust the community.<br>
<br>
> My dubt is infact. A compatibility break is a technical question ?<br>
> I guess potentially no, because it is more on QGIS usability , but is<br>
> technical when start to say:<br>
><br>
> hey using this solution you break the past, instead if you use this<br>
> other solution you don't break the past.<br>
><br>
> Is not simply to evaluate this question, and without a QGIS developer<br>
> expert is not easy to follow a RFC for a funder.<br>
<br>
Then the funder hires a QGIS developer to follow the RFC and make report.<br>
That's my scenario 3.<br>
<br>
Hope this clarify your questions. Others, do not hesitate to fix my<br>
understanding of the process if I am mistaken.<br>
<br>
Vincent<br>
<br>
><br>
> A.<br>
><br>
> 2014-08-25 10:54 GMT+02:00 Vincent Picavet <<a href="mailto:vincent.ml@oslandia.com">vincent.ml@oslandia.com</a>>:<br>
> > Hi Andrea,<br>
> ><br>
> > First of all, I tend to agree with Marco, where QEP should be voted when<br>
> > there is a general agreement on them. The PSC voting should therefore be<br>
> > enough.<br>
> ><br>
> > As for you question about QEP vs funders.<br>
> ><br>
> > Le lundi 25 août 2014 08:41:29, aperi2007 a écrit :<br>
> > [snip]<br>
> ><br>
> >> Also, AOAIK an important question is undrstand the limit of a RFC.<br>
> >> Infact don't forget that the main enhancement are always covered by one<br>
> >> or more funders.<br>
> >><br>
> >> Tipically they ask an enhancement with some request themself.<br>
> >><br>
> >> This RFC in the QGIS world is obviously after the real fund phase where<br>
> >> the funders find the developer and contract him.<br>
> >> So what mean that the RFC is submittable to the PSC ?<br>
> >> If the PSC to accept the RFC required more changeables and these<br>
> >> changeable require more fund, what happened ?<br>
> >><br>
> >> Or this RFC could be submitted before to find the developer and fund him<br>
> >> ?<br>
> >><br>
> >> In this second situation, the RFC should be submited from the funders ?<br>
> ><br>
> > What should happen is one of the three following scenarii :<br>
> ><br>
> > * The funder works with a contractor which knows QGIS and the QEP process<br>
> > well enough to guarantee to the funder that the QEP will pass as-is, for<br>
> > the originally proposed amount. In this case, the contractor takes the<br>
> > risk.<br>
> ><br>
> > * The funder provides the QEP and makes the discussions with the<br>
> > community until a general agreement is reached. Then the funder finds a<br>
> > company/developer to pass a contract for the development phase.<br>
> ><br>
> > * The funder makes a first contract with a company/developer, to write<br>
> > the QEP and reach an agreement (or not). Once the QEP status is set<br>
> > (voted as is, voted modified, deferred, rejected), the funder can pass<br>
> > another contract with this company/developer (or another) to implement<br>
> > the QEP.<br>
> ><br>
> > Vincent<br>
> ><br>
> >> Thx,<br>
> >><br>
> >> Andrea.<br>
> >><br>
> >> Il 25/08/2014 07:42, Martin Dobias ha scritto:<br>
> >> > I had the same impression as Nyall. PSC is meant to steer direction of<br>
> >> > the whole project, not to deal with technical details of<br>
> >> > implementations in QEPs - after all, only 3 out of 7 positions are<br>
> >> > meant for developers. At the same time I understand that creating<br>
> >> > another "developer" committee would make things more complex.<br>
> >> ><br>
> >> ><br>
> >> > I think that voting on QEPs could be started when the QEP's author has<br>
> >> > impression that enough consensus was reached. Most projects also allow<br>
> >> > their RFCs to go to 'deferred' state if the proposal is too<br>
> >> > controversial.<br>
> >><br>
> >> _______________________________________________<br>
> >> Qgis-developer mailing list<br>
> >> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> >> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>