On Mon, 2015-06-08 at 10:33 -0700, Gergo Tisza wrote:
I think it would be clearer if the title of the task would always reflected the situation at the time of creating the task, and titles describing a wanted but not currently existing state were phrased as imperatives. So if anons can see the public view right now and that's a bug the title would say "anons can access public view"; if they cannot access it currently but that's a feature we want, the title would say "anons should be able to access public view" or "make anons able to access public view".
Refering to the flaws of human language, there has been some Natural Language Processing research on language used in tasks / bug reports. In short: Terms such as ”crash”, ”critic”, ”broken”, ”when” indicate a bug. ”should”, ”implement”, ”support”, ”provid”, ’add” a non-bug. [1]
When triaging I personally rephrase task summaries like "Add/provide option to X", "Allow X" or "X should do Y".
On Mon, 2015-06-08 at 10:52 -0700, Jon Katz wrote:
I think we could go a step further and call out bugs with the prefix "bug:" for more clarity.
On Mon, 2015-06-08 at 11:03 -0700, Jon Robson wrote:
It might be easier to tag enhancements with enh: given that anyone can create tasks and will not necessarily adhere to our standards.
...if developers and maintainers triage tasks and add any such marker consistently which requires commitment and manpower. I'm not saying this to demotivate; I'm saying this because Wikimedia Phabricator is open to any contributors. Enforcing rules on expected provided information (other examples: "Expected Outcome", "Actual Outcome", "Reproducibility", "Hardware and OS") is way easier in a closed system (employees only) who are supposed to follow company rules. Volunteers can just decide to not contribute to your project by not reporting a problem if there are too many fields to fill out in some 'confusing' task reporting form.
Note that the ability of an average reporter (not part of some development team) to mark enhancements as such is low. [2] And „what reporters described as bugs or requests may not correspond to the developers’ perspective, because opinions are likely to differ on what the software’s intended behavior is or should be.“ [3]
This would at least solve confusion in whether things are bugs or enhancements
I currently don't believe that differentiating feature reqs and bugs make much sense because it's often impossible to draw the line. [4] But that's only the aspect of reporters and developers; I am pretty unaware of differentiation needs of Sprint projects when it comes to planning and reviewing points in a sprint. So I'm happy to revise.
Based on experience in other projects I also expect any way to mark an enhancement to not get systematically used by maintainers. [5] But maybe I am too much after consistency across projects which might not necessarily be needed.
In both cases (differentiation needs for sprints and consistent application), the Teampractices Group should know way better. Their mailing list sounds like a good venue to bring up this topic.
Cheers, andre
[1] page 313 in Giuliano Antoniol, Kamel Ayari, Massimiliano Di Penta, Foutse Khomh, and Yann-Gaël Guéhéneuc. Is it a bug or an enhancement?: a text-based approach to classify change requests. In Proceedings of the conference of the center for advanced studies on collaborative research: meeting of minds, CASCON ’08, pages 23:304–23:318, New York, USA, 2008. ACM. [2] page 396 of Kim Herzig, Sascha Just, and Andreas Zeller. It’s not a bug, it’s a feature: how misclassification impacts bug prediction. In Proceedings of the 35th International Conference on Software Engineering, ICSE ’13, pages 392–401, Piscataway, USA, 2013. IEEE. [3] page 132 of Andrew J. Ko, Brad A. Myers, and Duen Horng Chau. A linguistic analysis of how people describe software problems. In Proceedings of the Visual Languages and Human-Centric Computing, VLHCC ’06, pages 127–134, Washington, USA, 2006. [4] page 453 of Luis Villa. Large free software projects and Bugzilla: Lessons from GNOME project QA. In Proceedings of the Linux Symposium, pages 447–456, Ottawa, Canada, 2003. [5] page 227 of Kamel Ayari, Peyman Meshkinfam, Giuliano Antoniol, and Massimiliano Di Penta. Threats on building models from cvs and bugzilla repositories: The mozilla case study. In Proceedings of the Conference of the Center for Advanced Studies on Collaborative Research, CASCON ’07, pages 215–228, Riverton, USA, 2007. IBM Corp.