Re: [WikimediaMobile] Task/bug naming conventions
On Tue, Jun 9, 2015 at 3:53 AM, Andre Klapper aklap...@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 :) -- Arthur Richards Team Practices Manager [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
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 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
I've always used enhancement for this purpose -- does phabricator actually support this? On Mon, Jun 8, 2015 at 10:33 AM, Gergo Tisza gti...@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
Re: [WikimediaMobile] Task/bug naming conventions
On 8 jun. 2015, at 19:52, Jon Katz jk...@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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
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 jhob...@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 gti...@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
Re: [WikimediaMobile] Task/bug naming conventions
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 jk...@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 jhob...@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 gti...@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 -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] Task/bug naming conventions
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...@gmail.com wrote: On 8 jun. 2015, at 19:52, Jon Katz jk...@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 -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
