Hi, I forgot to mention that https://github.com/qgis/qgis4.0_api/issues is collecting wishes for 4.x and should be considered, when discussion what is core and what is not.
Regards, Jorge On 11/03/20 00:57, Jorge Gustavo Rocha wrote: > 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 > 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
