On Tue, 10 Mar 2020 at 20:30, Régis Haubourg <[email protected]> wrote: > > Hi Nyall, > this sounds reasonable indeed, can we have a bit more background or pointers > to real cases?
There's been a lot of "drive by features" over the last 12 months, where we see work merged and then the original developer disappears. A decent number of these have been first time QGIS developers. I'd rather not point to individual cases if that's ok! > One issue we faced these past months is that he exponential trafic on the > issues and PR makes it harder to follow issues and just have the information > that we could possibly be at stake somewhere. > Last year I was able to follow +/- 80 % of the discussions. I must admit that > lastly it became nearly impossible unless to work mostly on QGIS bug triaging > or coding. Yep, I hear you here! The PR queue is really stacking up again now and stressing me out... Nyall > > I really don't know how we could improve our communication channels. Any hint > welcome. > > Best regards > Régis > > Le lun. 9 mars 2020 à 23:14, Nyall Dawson <[email protected]> a écrit : >> >> Hi list, >> >> I'm after feedback on whether or not others think an explicit >> policy/contract regarding bug fixing responsibilities for new features >> is a good idea or not. >> >> I would like to see something like this added to the developer guidelines: >> >> "Following any new feature development, it is the original developer's >> (or organisations) SOLE responsibility to implement bug fixes relating >> to the new feature (or regressions to other parts of QGIS which have >> resulted from its development). This extends up to the next major QGIS >> release following the feature being merged*. It is NOT acceptable to >> use QGIS.org sponsored bug fixing efforts to implement these fixes. >> Failure to provide fixes to all reasonable bug reports raised for a >> new feature may lead to that feature being reverted prior to release." >> >> *i.e. currently 3.14 >> >> Personally, I think having this as part of our developer agreement >> would help clear up some ambiguity and source of frustration/conflict >> between developers. >> >> Thoughts? >> >> Nyall >> _______________________________________________ >> QGIS-Developer mailing list >> [email protected] >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
