[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 <even.rouault at spatialys.com>
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 at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140821/e407c89a/attachment.html>