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