[QGIS-Developer] A plea: "fixes" vs "features"

Nyall Dawson nyall.dawson at gmail.com
Sun Aug 4 16:06:47 PDT 2019


On Fri, 2 Aug 2019 at 20:55, Matthias Kuhn <matthias at opengis.ch> wrote:
> - [ ] I did not open a pull request because while the feature was
> actually working for me, the quality was not deemed high enough to be
> acceptable, so it's still rotting somewhere in my repository in a
> meanwhile unmergeable state.

Oh gosh - yes, this one. I've some 100+ rotting features/bug fixes
sitting in git branches in various states. Some because the result
didn't turn out as useful as I first thought, some because the funding
died before the work was finished, some because what I first thought
was going to be an easy fix turned out to be insanely complicated...
This one hits home too hard!

and now we need another category:

[ ] I opened this PR only because I had a rotting branch sitting in
git and my internal sense of completion-ism wouldn't allow me to rest
until this was fixed and merged

;)

> - [ ] While I worked on a feature I noticed a bug, so I fixed and
> backported it to LTR. The next day someone showed me a workflow and I
> realized that 50% of the time was spent to work around the bug.

Yep, I'll be ticking this one too...

> - [ ] It would have been easier to write a band aid for a bug, but
> instead I decided to spend the time to write this feature which also
> fixes the bug, but does so properly.

And this one...

Nyall
>
> - [ ] Others (like Skiing, spending time on discussions on open source
> and sustainability, writing grant proposals, bug triaging, answering
> questions on gis.se, reviewing pull requests). Write in the comment
> section below.
>
>        Comments:
>
>         ____________________________
>
>
> Matthias
>
>
> On 8/2/19 12:39 AM, Nyall Dawson wrote:
> > Hi list,
> >
> > This is something which has been on my mind a lot lately. Whenever a
> > question comes up about regressions or stability, the argument is
> > often thrown around that developers are writing "fun new features, not
> > fixes".
> >
> > I personally think this argument is a red herring. At best, it's a
> > misleading argument. At worst, it's side-tracking difficult and
> > important discussions with a point which has no corroborating
> > evidence, and offending contributors to the project.
> >
> > Has anyone actually tested this argument? My gut feeling is that it
> > would not hold up to any form of statistical testing in any way, and
> > that the mutually exclusive choice between writing a feature or a fix
> > NEVER comes up in reality.
> >
> > Can we PLEASE drop this argument, at least until someone does a survey
> > targeting the developers behind feature PRs, e.g.
> >
> > "
> > If you weren't spending time writing this feature, would you have instead:
> >
> > [ ] Just done my original task using alternative software or lengthy
> > workarounds instead, knowing that I'll have to repeat those
> > workarounds in future tasks
> >
> > [ ] Ignored the issues with my mapping product caused by the missing
> > feature and supplied it to clients as is
> >
> > [ ] Gone to bed early, and got a good night's sleep
> >
> > [ ] Gone for a hike in the mountains, re-invigorating my soul with the
> > beauty of nature
> >
> > [ ] Thought about going for a hike, but spent the time scrolling
> > endlessly through Twitter and feeling guilty and lazy
> >
> > [ ] I was being paid to work on this feature only, and would not have
> > been contributing to the project in any alternative way instead
> >
> > [ ] I had a mutually exclusive choice between writing this feature or
> > fixing bugs, and I explicitly choose to write a feature instead
> > because it was more enjoyable.
> > "
> >
> > Until we have evidence that this argument is valid, I think it's
> > actually causing much more harm to the community than good. (It can
> > easily be mis-interpreted as "you wasted your time volunteering this
> > contribution, you should have fixed #xyz instead.")
> >
> > Thanks for the consideration!
> > 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


More information about the QGIS-Developer mailing list