[QGIS-Developer] Explicit policy re bug fixing responsibilities after new features

Tue Mar 10 18:07:09 PDT 2020

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 <regis.haubourg at gmail.com> 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 <nyall.dawson at gmail.com> 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
>>>> QGIS-Developer at lists.osgeo.org
>>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> 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