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
