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

[Toby Dacre]

On 14 February 2013 16:04, Sean Hammond <sean.hammond at okfn.org> wrote:

> > > 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
>
> ah but you can to an issue and the issue can be a pull request (who
created this madness - this is where rapid prototyping takes you)

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].
>

This is true, but part of the reason for the label is so people like ira
can see that the issue is awaiting review ie has been done but not merged.


>
> > 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.
>

yes this is why I'm keen for pull requests to be linked to issues to keep
the numbers down - but that's a different issue
we are nearing the point of issue chaos IMHO keeping the numbers at a
reasonable issue should be a high priority for the dev team


>
> 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..
>
>
Yeah, I think this is all quite important especially having a dev 'own' the
issues.  Having one person who knows all the issues and helping to get them
prioritised would be really useful and I think is also very important for
team moral etc. Having this role might also help with comunication between
the devs and the `clients` needs

We also need to fight for the time to do our job properly and get things
like code review time recognised as vitally important not some nice to have.

tobes



> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130214/ba16e3a0/attachment-0001.html>