Assigning issues/PRs to (other) people ...

If you aren't _interested_ in "Process", please _ignore_ this. 👍

> _Process_ discussions are for people who _want_ work in _systematic/sustainable/scalable_ organisations that don't cave in under the weight of their technical/process debt the _moment_ a new person joins the team ... most "startups" don't have "time" to think about this kind of stuff. That is, they don't have "_time_" until they _realise_ how _much_ time they are _wasting_ by _not_ having clearly defined/agreed processes... ⌛️ 🔥 💸 😭

Assigning issues (_and pull requests_) to someone specific is a _good_ way of communicating with that person that you want them to take on the task, but _sadly_ that often not "enough".

Not "picking" on anyone in particular, but just for _illustration_ purposes @jrans has **18 Open Issues** which are **_Assigned**_ to him: [https://github.com/**issues**?q=**assignee**%3A**_jrans**_+is%3A**open**](https://github.com/issues?q=assignee%3Ajrans+is%3Aopen)


Its _really_ unclear which issue(s) someone is _currently_ working on when others can assign issues _to_ them... so when that person goes on holiday it can be difficult to know what is "_done_" if the issue is still open.

> I prefer the scenario where each person is _only_ working on _one_ thing at a time...

But I'm _absolutely_ guilty of having _way_ too many issues assigned to myself ...
Maybe I should tidy up my list before bringing up this discussion... 😉
## The Ticking Clock

This will only "work" once we have "Time" working.
Time will use the GitHub API to check which issues have been assigned to you and start counting as soon as something is assigned. That way we have "passive" time tracking.

> We need some _thought_ as to how this will work. e.g. we could still allow people to assign issues, but only when the person to whom the issue is assigned adds the `in-progress` label, the timer starts...