Hi, I agree that we have been following a "drive by features" approach.
Maybe with a more detailed road map of what we want in QGIS core, it would be easier to tag features provided by some developer/org as "extra" features or core features. Core features, according to some kind of road map, should be supported by any developer and eventually supported by QGIS.org. All PR related to these should have higher priority. The policy you are suggesting, Nyall, should be for "extra" features, the ones that are nice, but maybe not so important for the majority of users. You are one of the developers with more features introduced. Even if you are suggesting this policy, I think you are not responsible to maintain everything you did. Some are core features that should be backed by any other developer, if you are busy with something else. I think DB Manager is also a good example of something that was taken out of the road map. Developers trying to keep it alive should fix any upcoming errors. Maybe we could take more advantage of github "projects" tool to identify for each upcoming release the core features/priorities. Everybody could discuss, contribute and see what is scheduled and considered priority. QEP has been used for this, but it is a flat list, without any kind of priority and has no distinction between what is core or not. The tool is not important. Changing the drive from "features" to something more broader can improve the project management. Maybe we can work on your early discussion for 4.x to have a clear vision of what we want for QGIS in the short and medium term. In summary, as an alternative or complement to this policy, a clear road map of what we want in QGIS would make this responsibilities more clear. Regards from the virtual hackfest in Den Bosche, Jorge On 10/03/20 22:59, Nyall Dawson wrote: > 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 > J. Gustavo -- Jorge Gustavo Rocha Departamento de Informática Universidade do Minho 4710-057 Braga Gabinete 3.29 (Piso 3) Tel: +351 253604480 Fax: +351 253604471 Móvel: +351 910333888 skype: nabocudnosor _______________________________________________ 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
