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




--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon