Hi there, as my department integrates more into Asana, I’m looking to develop some Asana Conventions as described in this guide and elsewhere.
Things that come to mind are - when to use conversations, should there be consistent title/naming conventions, custom field changes, etc.
The guide is a great starting point, but I’m interested in what conventions other people use and what they deem is important to outline for their organization vs not.
My favorite convention that we use here at Asana is clicking 
to acknowledge that I’ve seen a task or comment. Hearting tasks and comments to acknowledge receipt saves me lots of time. It’s often unnecessary to reply to every single task update, so this lets me speed through my inbox and also empowers my teammates to forge ahead knowing we’re all on the same page. I also feel a lot of comfort when my manager hearts something because it tells me she knows what I’m working on and what I’ve accomplished.
I discuss a number of conventions in the “Guide to Defining Asana Conventions” of the Asana Training Masterclass. A couple I think are important are:
1) What should go in the project description? I think this is a really good spot to cover high-level goals of the project, metrics to help define what the “win” is, as well as key people.
2) Are you going to rely on project owners to provide status updates, and if yes how often are they expected to do so? A lot of people don’t understand that the dashboards really don’t have much value unless you are really on top of assigning project owners who report on project. Asana has reminders for once a week on Fridays built-in, but that might not work for everyone so you can use a recurring task as a reminder instead.
3) Who is allowed to invite guests into Asana? Some businesses have more confidentiality issues at play than others.
A few conventions that come to mind:
We put “----->” at the end of a task or subtask name to call attention to the fact that there’s more “behind” the item like a description or subtasks. The “>” indicator Asana uses for this is very subtle and easy to miss.
Agreeing on whether to capitalize all words or just the first word in a task/subtask and whether to start each with a verb will make your lists look much cleaner (at least for type-A teams like ours).
We use Google Docs to draft and stage content, and we have a Google Doc at the root level of the team folder that explains file and folder naming conventions.
oh my word that is very ‘Type A’! But it’s small things like that that can help make things (more) organized. I sometimes find myself waffling between putting an action verb at the beginning of the task title or just saying the item/etc. like “draft xyz” vs “xyz draft” or something of that sort.
I think it depends on the project, as some projects serve as a directory of items and some are projects that require action.
Sorry to sound like a noob here but what’s a “Type A team” ??
@Prathamesh, Actually, it’s not an Asana/Team thing! (Or maybe it is 
):
Larry
Type B (mostly; some A because of use of semi-colons and parentheses, etc.)
PS @Marie, Please request all product and development team to add a Type A / Type B radio button set to the Team settings dialog asap!!!