Hi all,
I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should.
Random example from current sprint board: "Anon users can access public view from main menu" with the associated description being "When anonymous and I click collections I am taken to the public view." Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard).
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".
Thoughts?
I've always used "enhancement" for this purpose -- does phabricator actually support this?
On Mon, Jun 8, 2015 at 10:33 AM, Gergo Tisza gtisza@wikimedia.org wrote:
Hi all,
I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should.
Random example from current sprint board: "Anon users can access public view from main menu" with the associated description being "When anonymous and I click collections I am taken to the public view." Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard).
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".
Thoughts?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Mon, 2015-06-08 at 10:36 -0700, Toby Negrin wrote:
I've always used "enhancement" for this purpose -- does phabricator actually support this?
Used where? Bugzilla, Mingle, Trello? :)
What is the underlying need to mark a task as enhancement? Corey filed https://phabricator.wikimedia.org/T93499 to "Add support for task types" and listed some reasons for differentation there. And I'm waiting for some Team Practices Group input on that task...
We discussed having a "Severity" or "Impact" field before migrating Bugzilla to Phabricator in T102 (as Bugzilla's Severity field offered a value called "enhancement"). In the end we decided to not have that.
In general this might be a discussion to have on the teampractices mailing list. I see nothing really mobile-specific in this discussion and I'm usually concerned that teams end up discussing their needs in their silos without the bigger picture and potentially finding a good solution across teams, assuming that other teams have similar needs. (And I hope this doesn't come across a rude or too blunt - I just can't find a better wording in English language on this morning. Sorry.)
Cheers, andre
On Tue, Jun 9, 2015 at 3:53 AM, Andre Klapper aklapper@wikimedia.org wrote:
What is the underlying need to mark a task as enhancement? Corey filed https://phabricator.wikimedia.org/T93499 to "Add support for task types" and listed some reasons for differentation there. And I'm waiting for some Team Practices Group input on that task...
I've add my 2 currency units to the task :)
+1, also any bugs should have clear repro steps in description and wanted features should have a clear UX path/outlined steps.
Thanks,
Jeff Hobson On Jun 8, 2015 1:33 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:
Hi all,
I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should.
Random example from current sprint board: "Anon users can access public view from main menu" with the associated description being "When anonymous and I click collections I am taken to the public view." Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard).
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".
Thoughts?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Good call, Gergo, and for calling out crap when you see it. I know I am to blame on a lot of these (including the above example). I think the language solution you described is pretty good.
restating suggested rules for those who don't read prose:
- bugs-->explain bad state in present tense (and desired state in description if nec). "Users screen goes blank" - enhancement-->explain desired state as imperative "Make it so users can.." or "Users should be able to..."
I think we could go a step further and call out bugs with the prefix "bug:" for more clarity.
-J
On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhobson@wikimedia.org wrote:
+1, also any bugs should have clear repro steps in description and wanted features should have a clear UX path/outlined steps.
Thanks,
Jeff Hobson On Jun 8, 2015 1:33 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:
Hi all,
I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should.
Random example from current sprint board: "Anon users can access public view from main menu" with the associated description being "When anonymous and I click collections I am taken to the public view." Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard).
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".
Thoughts?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
It might be easier to tag enhancements with enh: given that anyone can create tasks and will not necessarily adhere to our standards. This would at least solve confusion in whether things are bugs or enhancements.
On Mon, Jun 8, 2015 at 10:52 AM, Jon Katz jkatz@wikimedia.org wrote:
Good call, Gergo, and for calling out crap when you see it. I know I am to blame on a lot of these (including the above example). I think the language solution you described is pretty good.
restating suggested rules for those who don't read prose:
- bugs-->explain bad state in present tense (and desired state in
description if nec). "Users screen goes blank"
- enhancement-->explain desired state as imperative "Make it so users
can.." or "Users should be able to..."
I think we could go a step further and call out bugs with the prefix "bug:" for more clarity.
-J
On Mon, Jun 8, 2015 at 10:38 AM, Jeff Hobson jhobson@wikimedia.org wrote:
+1, also any bugs should have clear repro steps in description and wanted features should have a clear UX path/outlined steps.
Thanks,
Jeff Hobson On Jun 8, 2015 1:33 PM, "Gergo Tisza" gtisza@wikimedia.org wrote:
Hi all,
I would like to recommend a naming convention that clearly differentiates between existing and wanted behavior. This is something that has been confusing for me for a while - bugs and tasks are both in the indicative so I often have trouble deciding whether a ticket describes a situation that exists but should not or one that does not exist but should.
Random example from current sprint board: "Anon users can access public view from main menu" with the associated description being "When anonymous and I click collections I am taken to the public view." Does this mean that anonymous users should not be able to access the public view but somehow they can, or is this the description of a wanted feature? I can figure it out by digging up context, of course, but that takes time; ideally, this should be clear from just the task title (which I might be seeing in a list or on a workboard).
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".
Thoughts?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 8 jun. 2015, at 19:52, Jon Katz jkatz@wikimedia.org wrote: I think we could go a step further and call out bugs with the prefix "bug:" for more clarity.
-J
Please also discuss such a thing with Andre and other Phab people. We only just got rid of prefixes since we dumped bugzilla. It might be wise to make sure a sustainable route is chosen for any new conventions.
DJ
We made a bug ticket template that clearly asks for both “Actual Results” and “Expected Results” to help with this.
T98466 https://phabricator.wikimedia.org/T98466
On Mon, Jun 8, 2015 at 2:25 PM, Derk-Jan Hartman < d.j.hartman+wmf_ml@gmail.com> wrote:
On 8 jun. 2015, at 19:52, Jon Katz jkatz@wikimedia.org wrote: I think we could go a step further and call out bugs with the prefix
"bug:" for more clarity.
-J
Please also discuss such a thing with Andre and other Phab people. We only just got rid of prefixes since we dumped bugzilla. It might be wise to make sure a sustainable route is chosen for any new conventions.
DJ
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
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.