Hi, Thanks for bringing this up Nyall.
From my side, this survey would have had ticks in every of the available options over time.
And I'd have mentioned in the "feedback" part of the survey that some relevant information to answer the core question was missing because the question only targets feature pull requests:
- [ ] I spent the time to fix this bug instead of writing a new feature because the task was well defined and a reachable goal.
- [ ] 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.
- [ ] 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.
- [ ] 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.
- [ ] 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@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
