Strawman policy on assigning tickets in github.

[evdb]

We seem to have two strategies for managing who's working on which ticket:

1. Assign tickets to the person who is going to work on it and then use the now and next labels to manage.
2. Only assign to yourself tickets when you have started, or are the only person who should do, the ticket.

For projects with several people on 2 seems better so it is what I've proposed. I find the overhead of managing the now and next labels tedious so don't like 1.

[jacksonj04]

I agree with splitting assignment and queueing, and also prefer method 2 as I equally dislike the overhead of tagging and untagging. A couple of thoughts though:

• Might it be worth mentioning something like Huboard as a way to implement a kanban board for projects with multiple people (handles queueing, 'now' and 'next' etc).
• Do things like policies on ticketing belong in coding standards, or in a new "working standards" document?

[BenJam]

I much prefer number two also... I discussed with @davewhiteland the merits (and annoyances) of having non development-orientated ticekts in a repo too which, particularly on volunteer projects, is more than likely to be a confusion and a distraction to the wider community. I'll have a look at HuBoard but I'm quite interested in something that manages to separate the meta (managerial, administrative and discussion based) ticketing from the functional ticketing, but provides a single view. More on this later...

[dracos]

Just to note that I like FixMyStreet's way of handling, which has a separate repository for project-based tickets so as not to interfere with the public tickets. However, again for FixMyStreet I quite like having administrative and discussion tickets in the same place as any functional tickets that arise (or don't) from them, it seems to work okay for that project at least.

[jacksonj04]

I do think there is a fundamental inconsistency in having tickets for a deployment of a site in the same place as tickets for the code of a site. Somebody watching the FMS repository hosting their own code really doesn't care if an issue arises for something which needs doing on fixmystreet.com, but might care if a ticket is opened with a code issue. They may well unwatch the repository based on the high 'noise', then miss an issue they would be able to help with or which affects their deployment.

There's no reason that admin tasks for a deployment can't be raised in one place and development tasks for the central code in another. Indeed, I'd say that's the preferable approach because admin tasks may well involve data we don't want to be made public, but to track that in GitHub would need a ticket basically saying "Go look here for more", which is both a) confusing to external parties looking at the code (since they can't see any more), and b) means whoever is trying to fix it then has to go away and look at another system anyway.

[jacksonj04]

This is now generally solved in Huboard for the purposes of what's happening in any given sprint.