[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 at 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.hugentobler at sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140822/a2fdcd2b/attachment.html>