A pull system means never assigning

[mike-burns]

This introduces a new communications section for describing how best to
communicate like a thoughtbotter.

Up first: tickets. We use Trello right now, but the principles of how we
use it are the same as when we used Pivotal Tracker, JIRA, Trajectory,
GitHub Issues, and everything else. Therefore I've left it as just
"tickets."

We follow a pull system, which breaks down like this:

• For client projects, the next designer or developer takes the ticket
  with top priority.
• For discussion topics, such as happens on the Research board, people
  subscribe to tickets they are interested in.

Assigning people to a ticket defeats this and causes confusion.
Therefore, we don't do that.

[drapergeek]

Maybe add a 'without their knowledge'? I've often asked people to assign me to things or had people ask me to do this for them because that way they knew what I was asking about.

Not sure if the clause is necessary, just a thought.

[mjankowski]

Is this a general rule, or is it specific to the assignment of tasks/stories/etc for which there is a very concise definition, and it's just a matter of putting them in a queue for developers/designers to pick off of?

Because in that scenario, I agree.

But, for the larger case which potentially includes ad-hoc conversation or tasks where we really do need one specific person (or one role on the project) to do something, I think it's fine to assign.

Example: we need to create a new subdomain and only one person can do that and we all agree on who that is; shouldn't we assign a task to them?

[mike-burns]

@mjankowski under Trello, no: just at-mention them.

[mjankowski]

If they miss that first mention though, that doesn't give them a mechanism to find things that they specifically must do. Whereas assigning to them and allowing them to q the boards on the card and filter to theirs would do so.

[derekprior]

If it's something a specific person must do then it probably makes sense to assign and ping like crazy, right?

[mike-burns]

The inspiration for this diff is the Research board, where I often find myself assigned to new cards. Phrasings that stop this from happening are welcome.

[derekprior]

I'm actually fine with the current phrasing. I know enough to decide when it's appropriate for me to break this rule.

[mjankowski]

What about two bullets:

• For well-defined tasks that need to be done, we prefer a queue of prioritized tickets and a "pull" system where team members take things off the top. Don't assign things to other team members.
• For open tasks and discussions which would benefit from the inclusion of specific people, loop them in via at-mentions or ticket assignment.

[mike-burns]

That second bullet point still gets people assigning me to Research cards, though. How about:

• When in doubt, do not assign a ticket to someone.

[croaky]

What is the downside to assigning someone? Can you include the "why" in the commit message and PR summary?

[mike-burns]

I've added a shorter, simpler rewrite and a longer, more detailed commit message.

[jferris]

The latest version reads well to me.

Are there any objections to merging this?

[gabebw]

I like it.

[teoljungberg]

I concur