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.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/