[ckan-dev] 'Awaiting review' tag on github issues

Thu Feb 14 16:04:47 UTC 2013

> > Do we need this, doesn't the existence of a pull request (without WIP in
> > its title) mean that something is awaiting review?
> >
> >
> we'll my though on creating it was that it was a sign that it was ready to
> be merged reviewed etc.  maybe we don't need this. but we do seem to have
> regular issues with 'stuck' pull requests.

If my eyes don't deceive me, you cannot add a label to a pull request on
github, e.g.:

https://github.com/okfn/ckan/pull/295

Although you can add them to a milestone.

It could be that issues with code attached can be labelled, but
standalone pull requests cannot.

Another seemingly random github issues limitation.

Anyway, for this reason I'd suggest we assume all pull requests are code
awaiting review unless their title starts with [wip].

> I think the real solution is for one of the devs to be the owner of the
> issue tracker and 'shout' at people to get merges done/fix issues if they
> are being ignored etc.  also the whole gatekeeping qa etc

We've been going through the (non-wip) pull requests on skype together
every Tuesday and assigning them each to someone. There was talk about
doing the same with the issues. The trouble is that 31 open pull
requests is bad enough, 97 open issues represents quite a lot of dev
work to be done.

As discussed we need each dev to have scheduled time each sprint to work
on pull requests and issues unhindered by priorities and client requests
etc. I'd suggest 3 days per dev per sprint as a basic minimum. But we
should also probably have a dev meeting before each sprint planning
meeting to decide how many core days we need for the next sprint, if we
need extra core time because there are a lot of pull requests and
issues, that needs to be taken into account when project managers get
together and assign work to each dev for the sprint. This is equivalent
to the meeting I have with my project manager for LOD2 before each
sprint, where we decide together what issues we want to tackle and how
many days we want to ask for for LOD2 in the next sprint. Essentially,
we need to treat Issues & Pull Requests as another project/client, on
equal footing. Someone from the dev team should act as project manager
for Issues & Pull Requests and go to the project manager meeting to
represent. I think something like this is kind of happening already but
maybe we need to solidify it a little..