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

[Alessandro Pasotti]

2014-08-21 14:26 GMT+02:00 Nathan Woodrow :
> Hey all,
>
> I would like to raise something I have been considering for a while now. We
> are becoming a large project, in code and users, and there has been some
> recent issues of developers doing work only for there to be disagreements on
> the implementation. I would like resurrect the use of RFCs, or I think would
> should name them QEP (QGIS Enhancement Proposal because that sounds much
> cooler :)
>

Hello Nathan,

thank you for the resurrection :)

I would just stick to RFC instead of QEP: I also like the acronym but
everybody (inside and outside our community) knows exactly what RFC
stands for while almost nobody knows about QEP.

Branding can be useful marketing stuff but I'd avoid it in this
context: we are talking about technical documents, and we have already
enough acronyms to keep in mind, don't we?

Anyway, I would like to write down some notes in a an QEP/RFC about
QGIS Mapserver Python Plugins and I would like to know if and how can
I start from a template: I gave a quick look to
https://github.com/qgis/QGIS-Enhancement-Proposals but it appears to
be empty.

-- 
Alessandro Pasotti
w3:   www.itopen.it
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Andrea Peri]

What mean "the community dont agree" ?
More explain.
If 3 or 4 user community say "no" or "ask different solutions" . It is the
community think ?

I guess the PSC should not ne only a simply executor of the community
think, but  the real director of the project.
Often the community think a thing bit thw more strategic solution is
another.
I guess the server side is always minority on user interest. And often the
user font understand what is a server question.
So the community never choose a server solution.
This mean in the medium time to split the qgis in two distincts products.
Desktop and server.

Every one with its own community.

My 1 ct.
:)
 Il 25/ago/2014 11:35 "Tim Sutton"  ha scritto:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi
>
> On 25/08/2014 07:42, Martin Dobias wrote:
> > On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson
> >  wrote:
> >>
> >> On 23/08/2014 3:33 am, "Even Rouault"
> >>  wrote:
> >>>
> >>> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
>  - Who can vote? PSC only (GDAL) / committers
> >>>
> >>> With GIT, 'committers' can be anyone. You probably meant folks
> >>> who have push rights in official repo ? If you give them voting
> >>> rights, and potentially veto right (not sure how the rules of
> >>> the voting system of QGIS are), then they are defacto PSC
> >>> members, since they can steer the direction of the project.
> >>> Not saying this is bad. Just a consequence.
> >>>
> >>
> >> I'd say neither psc nor commit rights are a good fit. While I
> >> agree that the psc should definitely have a say, not everyone on
> >> the psc is a developer or has c++ coding experience. Similarly,
> >> we have people who have commit rights who are neither developers
> >> nor psc members.
> >
> > 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.
> >
> >
> >> Since a big part of the qep would be commenting on proposed
> >> technical architecture, I think its fairly important that
> >> developers have a good say in the process. But conversely if the
> >> qep process determines the direction of QGIS, then non devs on
> >> the psc should also have a say.
> >
> > Originally I thought that only new functionality would be covered
> > by QEPs, but it is actually quite useful to have one common process
> > for any significant changes in the project - ranging from
> > development stuff through infrastructure changes to organizational
> > changes (like introduction of trademark). So it makes sense to have
> > PSC vote on QEPs.
> >
>
> So my 2c:
>
> - From the PSC point of view the intention is that the PSC facilitate
> teams to work on specific areas e.g. documentation team, UX team etc.
> I think RFC's would probably come under Marco's remit (PSC: Code Manager).
>
> I don't think it is necessary for the whole PSC to be involved unless
> Marco wants help. So the normal modus operandi would be:
>
> * Marco forms an RFC review team
> * People submit RFC's
> * Review team accepts or denies the RFC's
> * PSC is available to resolve any disputes that may arise or aid in
> decision making where review team feels the impact on the project is
> broad.
>
> Regards
>
> Tim
>
> >
> > Regards Martin ___
> > Qgis-developer mailing list Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> - --
> - --
>
> Tim Sutton
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
>  * GIS Training
>  * Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
> - --
> Kartoza is a merger between Linfiniti and Afrispatial
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02
> AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr
> =/Cer
> -END PGP SIGNATURE-
>
> ___
> 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

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

[Nathan Woodrow]

Hey,

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.

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

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.

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.

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.

Nathan
On Aug 25, 2014 7:42 PM, "Vincent Picavet"  wrote:

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

Re: [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 :
> > > 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 im

Re: [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 :
> > 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.
> >> > 

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

[Tim Sutton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

On 25/08/2014 07:42, Martin Dobias wrote:
> On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson
>  wrote:
>> 
>> On 23/08/2014 3:33 am, "Even Rouault"
>>  wrote:
>>> 
>>> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
 - Who can vote? PSC only (GDAL) / committers
>>> 
>>> With GIT, 'committers' can be anyone. You probably meant folks
>>> who have push rights in official repo ? If you give them voting
>>> rights, and potentially veto right (not sure how the rules of
>>> the voting system of QGIS are), then they are defacto PSC
>>> members, since they can steer the direction of the project. 
>>> Not saying this is bad. Just a consequence.
>>> 
>> 
>> I'd say neither psc nor commit rights are a good fit. While I
>> agree that the psc should definitely have a say, not everyone on
>> the psc is a developer or has c++ coding experience. Similarly,
>> we have people who have commit rights who are neither developers
>> nor psc members.
> 
> 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.
> 
> 
>> Since a big part of the qep would be commenting on proposed
>> technical architecture, I think its fairly important that
>> developers have a good say in the process. But conversely if the
>> qep process determines the direction of QGIS, then non devs on
>> the psc should also have a say.
> 
> Originally I thought that only new functionality would be covered
> by QEPs, but it is actually quite useful to have one common process
> for any significant changes in the project - ranging from
> development stuff through infrastructure changes to organizational
> changes (like introduction of trademark). So it makes sense to have
> PSC vote on QEPs.
> 

So my 2c:

- From the PSC point of view the intention is that the PSC facilitate
teams to work on specific areas e.g. documentation team, UX team etc.
I think RFC's would probably come under Marco's remit (PSC: Code Manager).

I don't think it is necessary for the whole PSC to be involved unless
Marco wants help. So the normal modus operandi would be:

* Marco forms an RFC review team
* People submit RFC's
* Review team accepts or denies the RFC's
* PSC is available to resolve any disputes that may arise or aid in
decision making where review team feels the impact on the project is
broad.

Regards

Tim

> 
> Regards Martin ___ 
> Qgis-developer mailing list Qgis-developer@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

- -- 
- --

Tim Sutton
Visit http://kartoza.com to find out about open source:
 * Desktop GIS programming services
 * Geospatial web development
 * GIS Training
 * Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
- --
Kartoza is a merger between Linfiniti and Afrispatial
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02
AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr
=/Cer
-END PGP SIGNATURE-
<>___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Andrea Peri]

Hi Vincent,

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 ?

Surely better could be have a +1 explicit from the PSC menbers on the
docs before start the work.

And how PSC vot need to say that the RFC is accepted ?

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.

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.

A.

2014-08-25 10:54 GMT+02:00 Vincent Picavet :
> 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



-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Vincent Picavet]

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

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

[aperi2007]

Hi,
only for better understanding every details,
there is a list of actual member list of PSC.

And my curiosity is for the affermations:


after all, only 3 out of 7 positions are
meant for developers


I guess a short curriculum of every psc member could help to understand 
the role of everyone.


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 ?

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

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

[Martin Dobias]

On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson  wrote:
>
> On 23/08/2014 3:33 am, "Even Rouault"  wrote:
>>
>> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
>> > - Who can vote?
>> >  PSC only (GDAL) / committers
>>
>> With GIT, 'committers' can be anyone. You probably meant folks who have
>> push
>> rights in official repo ? If you give them voting rights, and potentially
>> veto
>> right (not sure how the rules of the voting system of QGIS are), then they
>> are
>> defacto PSC members, since they can steer the direction of the project.
>> Not
>> saying this is bad. Just a consequence.
>>
>
> I'd say neither psc nor commit rights are a good fit. While I agree that the
> psc should definitely have a say, not everyone on the psc is a developer or
> has c++ coding experience. Similarly, we have people who have commit rights
> who are neither developers nor psc members.

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.


> Since a big part of the qep would be commenting on proposed technical
> architecture, I think its fairly important that developers have a good say
> in the process. But conversely if the qep process determines the direction
> of QGIS, then non devs on the psc should also have a say.

Originally I thought that only new functionality would be covered by
QEPs, but it is actually quite useful to have one common process for
any significant changes in the project - ranging from development
stuff through infrastructure changes to organizational changes (like
introduction of trademark). So it makes sense to have PSC vote on
QEPs.


Regards
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Marco Hugentobler]

On 24.08.2014 11:46, Nathan Woodrow wrote:
On Sun, Aug 24, 2014 at 7:44 PM, Nyall Dawson > wrote:


OK, fair enough. But would non-psc members be able to comment on
proposals?


Everyone should have the right to comment. Just some people will have 
more weight then others.


That's also my opinion. Everyone can discuss, not everyone can vote (and 
my expectation is that controversial RFC/QEP will be very very rare).


Regards,
Marco

--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

On Sun, Aug 24, 2014 at 7:44 PM, Nyall Dawson 
wrote:

> OK, fair enough. But would non-psc members be able to comment on proposals?


Everyone should have the right to comment. Just some people will have more
weight then others.

- Nathan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On 24/08/2014 7:41 pm, "Marco Hugentobler" 
wrote:
>
> Hi Nyall
>
> Having another process to nominate QEP voters sounds too complicated to
me.
>
>
> >not everyone on the psc is a developer or has c++ coding experience
>
> There is a mix of coders and non-coders in the PSC on purpose. Developers
sometimes have a narrow point of view, so it is good that also
non-developers have a say. In the discussion part of the QEP, the
consequences for users can be mentioned. I don't consider that a problem,
even for very technical subjects (and even those usually have somehow an
influence on the users of a software).

OK, fair enough. But would non-psc members be able to comment on proposals?

>
> I'm putting RFC/QEP on the agenda to discuss at the next PSC meeting (
http://hub.qgis.org/wiki/quantum-gis/PSC_Meeting_5_September_2014).

Great to hear - thanks!

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Marco Hugentobler]

Hi Nyall

Having another process to nominate QEP voters sounds too complicated to me.

>not everyone on the psc is a developer or has c++ coding experience

There is a mix of coders and non-coders in the PSC on purpose. 
Developers sometimes have a narrow point of view, so it is good that 
also non-developers have a say. In the discussion part of the QEP, the 
consequences for users can be mentioned. I don't consider that a 
problem, even for very technical subjects (and even those usually have 
somehow an influence on the users of a software).


I'm putting RFC/QEP on the agenda to discuss at the next PSC meeting 
(http://hub.qgis.org/wiki/quantum-gis/PSC_Meeting_5_September_2014).


Regards,
Marco

On 23.08.2014 03:31, Nyall Dawson wrote:



On 23/08/2014 3:33 am, "Even Rouault" > wrote:

>
> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
> > - Who can vote?
> >  PSC only (GDAL) / committers
>
> With GIT, 'committers' can be anyone. You probably meant folks who 
have push
> rights in official repo ? If you give them voting rights, and 
potentially veto
> right (not sure how the rules of the voting system of QGIS are), 
then they are
> defacto PSC members, since they can steer the direction of the 
project. Not

> saying this is bad. Just a consequence.
>

I'd say neither psc nor commit rights are a good fit. While I agree 
that the psc should definitely have a say, not everyone on the psc is 
a developer or has c++ coding experience. Similarly, we have people 
who have commit rights who are neither developers nor psc members.


Since a big part of the qep would be commenting on proposed technical 
architecture, I think its fairly important that developers have a good 
say in the process. But conversely if the qep process determines the 
direction of QGIS, then non devs on the psc should also have a say.


So, I'd say we need a new group for voters. We could have a process like:
- a candidate is nominated & seconded (possibly by psc members only?)
- the candidate gives a short reasoning on why they'd like to be part 
of the group and what skills they have
- after receiving a set number of votes the candidate is accepted into 
the group. (Again, possibly only the psc could vote on candidates?).


Nyall



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On 23/08/2014 3:33 am, "Even Rouault"  wrote:
>
> Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
> > - Who can vote?
> >  PSC only (GDAL) / committers
>
> With GIT, 'committers' can be anyone. You probably meant folks who have
push
> rights in official repo ? If you give them voting rights, and potentially
veto
> right (not sure how the rules of the voting system of QGIS are), then
they are
> defacto PSC members, since they can steer the direction of the project.
Not
> saying this is bad. Just a consequence.
>

I'd say neither psc nor commit rights are a good fit. While I agree that
the psc should definitely have a say, not everyone on the psc is a
developer or has c++ coding experience. Similarly, we have people who have
commit rights who are neither developers nor psc members.

Since a big part of the qep would be commenting on proposed technical
architecture, I think its fairly important that developers have a good say
in the process. But conversely if the qep process determines the direction
of QGIS, then non devs on the psc should also have a say.

So, I'd say we need a new group for voters. We could have a process like:
- a candidate is nominated & seconded (possibly by psc members only?)
- the candidate gives a short reasoning on why they'd like to be part of
the group and what skills they have
- after receiving a set number of votes the candidate is accepted into the
group. (Again, possibly only the psc could vote on candidates?).

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Even Rouault]

Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit :
> Hi Nathan
> 
> Sounds good to me (no strong opinion wheter to call it RFC or QEP). The
> old RFC template is even online
> (http://hub.qgis.org/projects/quantum-gis/wiki/RFC_Template).
> 
> So open questions:
> 
> - What needs to have an RFC?
>  Proposal Martin: >1000 lines of code /  modification to core/gui /
> UI changes

Another good rule of thumb is "if you ask yourself is a change is worth a RFC, 
then it is worth it"

> 
> - Who can vote?
>  PSC only (GDAL) / committers

With GIT, 'committers' can be anyone. You probably meant folks who have push 
rights in official repo ? If you give them voting rights, and potentially veto 
right (not sure how the rules of the voting system of QGIS are), then they are 
defacto PSC members, since they can steer the direction of the project. Not 
saying this is bad. Just a consequence.

> 
> - How long shall the period from RFC/QEP announcement until finish of
> voting period be? Probably it needs a 'remember, you have to vote' mail
> a few days before end of voting period.

You probably have to distinguish two phases :
- a discussion phase. The length might depend on the reactions of the readers, 
if the RFC needs to be reworked, etc... Difficult to put a max length. 
Generally 
it is left to the appreciation of the person who writes the RFC to feel when 
enough concensus has been reached so that the voting phase will approve their 
RFC
- the voting phase. In GDAL/MapServer, motions are to be voted theoretically 
within 2 business days. This might be short however.

> 
> Will be cool if Larry can do the first QEP of the 'modern age'.
> 
> Regards,
> Marco
> 
> On 21.08.2014 14:26, Nathan Woodrow wrote:
> > Hey all,
> > 
> > I would like to raise something I have been considering for a while
> > now. We are becoming a large project, in code and users, and there has
> > been some recent issues of developers doing work only for there to be
> > disagreements on the implementation. I would like resurrect the use of
> > RFCs, or I think would should name them QEP (QGIS Enhancement Proposal
> > because that sounds much cooler :)
> > 
> > My thinking behind this was:
> > 
> > - QGIS is picking up pace in popularity and use so we need something
> > to formalise the future feature set and any improvements for the next
> > version.  Most people know the Python project uses the idea of PEPs in
> > order to document what new major features are coming in X version and
> > to explain the rational, or reasons .  I have found this handy to be
> > able to look at detailed overview of why a feature made it or didn't,
> > or when it might make it, or if ever.
> > 
> > - This is more then just using the bug tracker to log future features.
> > This is something where we can have more detail and then break it down
> > into sub tasks which can live in the bug tracker but linked to the QEP
> > (RFC).
> > 
> > - The QEP should also have formal voting and discussion around the
> > proposal. This should be limited to a small pool of developers.
> > 
> > - The QEP could also list changes the API, or if breaking changes need
> > to be made.
> > 
> > - Things like how the new feature might fit into other future plans.
> > 
> > - QEPs should list as much detail as possible in order to help
> > everyone see the bigger picture with the feature or change.
> > 
> > Another reason I was thinking about this was in order to consolidate
> > major features and collaborate better. Emails are fine but get lost
> > and forgotten very easily, the bug tracker is the same.  The QEP can
> > link to the emails and tickets for future reference.  QEPs should be
> > the central point for the feature linking to everything that is related.
> > 
> > Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I
> > would say we should use that.
> > 
> > Thoughts?
> > 
> > Nathan
> > 
> > 
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Marco Hugentobler]

Hi Nathan

Sounds good to me (no strong opinion wheter to call it RFC or QEP). The 
old RFC template is even online 
(http://hub.qgis.org/projects/quantum-gis/wiki/RFC_Template).


So open questions:

- What needs to have an RFC?
Proposal Martin: >1000 lines of code /  modification to core/gui / 
UI changes


- Who can vote?
PSC only (GDAL) / committers

- How long shall the period from RFC/QEP announcement until finish of 
voting period be? Probably it needs a 'remember, you have to vote' mail 
a few days before end of voting period.


Will be cool if Larry can do the first QEP of the 'modern age'.

Regards,
Marco




On 21.08.2014 14:26, Nathan Woodrow wrote:

Hey all,

I would like to raise something I have been considering for a while 
now. We are becoming a large project, in code and users, and there has 
been some recent issues of developers doing work only for there to be 
disagreements on the implementation. I would like resurrect the use of 
RFCs, or I think would should name them QEP (QGIS Enhancement Proposal 
because that sounds much cooler :)


My thinking behind this was:

- QGIS is picking up pace in popularity and use so we need something 
to formalise the future feature set and any improvements for the next 
version.  Most people know the Python project uses the idea of PEPs in 
order to document what new major features are coming in X version and 
to explain the rational, or reasons .  I have found this handy to be 
able to look at detailed overview of why a feature made it or didn't, 
or when it might make it, or if ever.


- This is more then just using the bug tracker to log future features. 
This is something where we can have more detail and then break it down 
into sub tasks which can live in the bug tracker but linked to the QEP 
(RFC).


- The QEP should also have formal voting and discussion around the 
proposal. This should be limited to a small pool of developers.


- The QEP could also list changes the API, or if breaking changes need 
to be made.


- Things like how the new feature might fit into other future plans.

- QEPs should list as much detail as possible in order to help 
everyone see the bigger picture with the feature or change.


Another reason I was thinking about this was in order to consolidate 
major features and collaborate better. Emails are fine but get lost 
and forgotten very easily, the bug tracker is the same.  The QEP can 
link to the emails and tickets for future reference.  QEPs should be 
the central point for the feature linking to everything that is related.


Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I 
would say we should use that.


Thoughts?

Nathan


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Martin Dobias]

Hi

On Thu, Aug 21, 2014 at 7:52 PM, Even Rouault
 wrote:
> Hi,
>
> I'm mostly an observer of QGIS dev, but I think it would be a nice move to 
> help
> coordination and formalize big changes. GDAL or MapServer have been 
> successfully
> following such a practice for years. See
> http://trac.osgeo.org/gdal/wiki/RfcList or
> http://mapserver.org/development/rfc/index.html for possible ideas for the
> Content table of a RFC (mostly what Nathan suggested)
> The voting is typically limited to PSC members, whereas the discussion phase 
> is
> open to everyone to give their input.

I like the idea of QEPs. I think we could adopt a process very similar
to GDAL RFCs.

@Larry - regarding stuff going through QEP process: I don't think
every small feature needs QEP. We could have a rule of thumb to decide
when QEP is necessary - e.g. new additions to core/gui library or when
a development is going to add a lot of code (>1K lines) or there will
be significant impact to user interface.

Cheers
Martin
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nyall Dawson]

On 21/08/2014 10:27 pm, "Nathan Woodrow"  wrote:
>
> Hey all,
>
> I would like to raise something I have been considering for a while now.
We are becoming a large project, in code and users, and there has been some
recent issues of developers doing work only for there to be disagreements
on the implementation. I would like resurrect the use of RFCs, or I think
would should name them QEP (QGIS Enhancement Proposal because that sounds
much cooler :)
>
> Thoughts?

I'm strongly in favor of this idea, and for formalizing the
commit/development process in general. Like Larry mentioned, we'd need some
guidelines about what kind of changes are OK just to push through without a
QEP.

I'm also curious about time lines, given that often pull requests sit with
no response for many months (years?). Would there be an automatic
acceptance after a set time with no -1s?

On a related note, I'd also like to see some additional rules put in place
around acceptable commits:
- all commits which modify CORE components should be accompanied by unit
tests, unless exemption is granted in advance by the dev list. GUI and app
would be immune due to the difficulties in implementing ui tests
- all api changes should include detailed documentation, including a
description of all variables and their use

This is probably a discussion for another thread though...

Nyall
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Larry Shaffer]

Hi Nathan,

Sorry for top-posting, but I think your idea is very much needed. I was
looking into labeling changes, built upon Nyall's recent work, and found
the new features to be drastic enough to warrant a QEP (I like the acronym
as well).

Question: at what point does a new feature need to go through the QEP
process? (You mentioned 'major features.') Or, are you suggesting all new
features have an accompanying QEP?

This should go a long ways towards ensuring stability is always taken into
consideration, too.

Regards,

Larry


On Thu, Aug 21, 2014 at 6:52 AM, Even Rouault 
wrote:

> Hi,
>
> I'm mostly an observer of QGIS dev, but I think it would be a nice move to
> help
> coordination and formalize big changes. GDAL or MapServer have been
> successfully
> following such a practice for years. See
> http://trac.osgeo.org/gdal/wiki/RfcList or
> http://mapserver.org/development/rfc/index.html for possible ideas for the
> Content table of a RFC (mostly what Nathan suggested)
> The voting is typically limited to PSC members, whereas the discussion
> phase is
> open to everyone to give their input.
>
> Even
>
> > Hey all,
> >
> > I would like to raise something I have been considering for a while now.
> We
> > are becoming a large project, in code and users, and there has been some
> > recent issues of developers doing work only for there to be disagreements
> > on the implementation. I would like resurrect the use of RFCs, or I think
> > would should name them QEP (QGIS Enhancement Proposal because that sounds
> > much cooler :)
> >
> > My thinking behind this was:
> >
> > - QGIS is picking up pace in popularity and use so we need something to
> > formalise the future feature set and any improvements for the next
> version.
> >  Most people know the Python project uses the idea of PEPs in order to
> > document what new major features are coming in X version and to explain
> the
> > rational, or reasons .  I have found this handy to be able to look at
> > detailed overview of why a feature made it or didn't, or when it might
> make
> > it, or if ever.
> >
> > - This is more then just using the bug tracker to log future features.
> This
> > is something where we can have more detail and then break it down into
> sub
> > tasks which can live in the bug tracker but linked to the QEP (RFC).
> >
> > - The QEP should also have formal voting and discussion around the
> > proposal. This should be limited to a small pool of developers.
> >
> > - The QEP could also list changes the API, or if breaking changes need to
> > be made.
> >
> > - Things like how the new feature might fit into other future plans.
> >
> > - QEPs should list as much detail as possible in order to help everyone
> see
> > the bigger picture with the feature or change.
> >
> > Another reason I was thinking about this was in order to consolidate
> major
> > features and collaborate better. Emails are fine but get lost and
> forgotten
> > very easily, the bug tracker is the same.  The QEP can link to the emails
> > and tickets for future reference.  QEPs should be the central point for
> the
> > feature linking to everything that is related.
> >
> > Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I would
> > say we should use that.
> >
> > Thoughts?
> >
> > Nathan
> >
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> 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

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

[Even Rouault]

Hi,

I'm mostly an observer of QGIS dev, but I think it would be a nice move to help
coordination and formalize big changes. GDAL or MapServer have been successfully
following such a practice for years. See
http://trac.osgeo.org/gdal/wiki/RfcList or
http://mapserver.org/development/rfc/index.html for possible ideas for the
Content table of a RFC (mostly what Nathan suggested)
The voting is typically limited to PSC members, whereas the discussion phase is
open to everyone to give their input.

Even

> Hey all,
>
> I would like to raise something I have been considering for a while now. We
> are becoming a large project, in code and users, and there has been some
> recent issues of developers doing work only for there to be disagreements
> on the implementation. I would like resurrect the use of RFCs, or I think
> would should name them QEP (QGIS Enhancement Proposal because that sounds
> much cooler :)
>
> My thinking behind this was:
>
> - QGIS is picking up pace in popularity and use so we need something to
> formalise the future feature set and any improvements for the next version.
>  Most people know the Python project uses the idea of PEPs in order to
> document what new major features are coming in X version and to explain the
> rational, or reasons .  I have found this handy to be able to look at
> detailed overview of why a feature made it or didn't, or when it might make
> it, or if ever.
>
> - This is more then just using the bug tracker to log future features. This
> is something where we can have more detail and then break it down into sub
> tasks which can live in the bug tracker but linked to the QEP (RFC).
>
> - The QEP should also have formal voting and discussion around the
> proposal. This should be limited to a small pool of developers.
>
> - The QEP could also list changes the API, or if breaking changes need to
> be made.
>
> - Things like how the new feature might fit into other future plans.
>
> - QEPs should list as much detail as possible in order to help everyone see
> the bigger picture with the feature or change.
>
> Another reason I was thinking about this was in order to consolidate major
> features and collaborate better. Emails are fine but get lost and forgotten
> very easily, the bug tracker is the same.  The QEP can link to the emails
> and tickets for future reference.  QEPs should be the central point for the
> feature linking to everything that is related.
>
> Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I would
> say we should use that.
>
> Thoughts?
>
> Nathan
>


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Hey all,

I would like to raise something I have been considering for a while now. We
are becoming a large project, in code and users, and there has been some
recent issues of developers doing work only for there to be disagreements
on the implementation. I would like resurrect the use of RFCs, or I think
would should name them QEP (QGIS Enhancement Proposal because that sounds
much cooler :)

My thinking behind this was:

- QGIS is picking up pace in popularity and use so we need something to
formalise the future feature set and any improvements for the next version.
 Most people know the Python project uses the idea of PEPs in order to
document what new major features are coming in X version and to explain the
rational, or reasons .  I have found this handy to be able to look at
detailed overview of why a feature made it or didn't, or when it might make
it, or if ever.

- This is more then just using the bug tracker to log future features. This
is something where we can have more detail and then break it down into sub
tasks which can live in the bug tracker but linked to the QEP (RFC).

- The QEP should also have formal voting and discussion around the
proposal. This should be limited to a small pool of developers.

- The QEP could also list changes the API, or if breaking changes need to
be made.

- Things like how the new feature might fit into other future plans.

- QEPs should list as much detail as possible in order to help everyone see
the bigger picture with the feature or change.

Another reason I was thinking about this was in order to consolidate major
features and collaborate better. Emails are fine but get lost and forgotten
very easily, the bug tracker is the same.  The QEP can link to the emails
and tickets for future reference.  QEPs should be the central point for the
feature linking to everything that is related.

Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I would
say we should use that.

Thoughts?

Nathan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer