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

Thu Feb 14 17:02:07 UTC 2013

A lot of the current issues will be closed once their respective pull
requests are reviewed and merged - so this will help. I still think having
a meeting to review issues (e.g. after Monday standup) is good practice to
ensure there's a time to discuss and parcel things out.

For sprint planning, we are trying to ensure there is time allocated each
sprint for core work - but having a representative to negotiate priorities
for core dev will help.

I want to have a roadmap meeting where we're not just reactively fixing
things / reviewing bugs, but planning and moving stuff forward. For example
I'm putting together a spec for more coherent data explorer functionality
and ability for admins to 'invite' users - i.e. create user account and
assign them roles. Presumably just adding this as a github issue creates
noise. We need to review the roadmap trello board and put things forward
into sprints (and give people a chance to sponsor work to ensure it happens
and gets prioritised).

Ira

On 14 February 2013 16:21, Toby Dacre <toby.okfn at gmail.com> wrote:

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

-- 

Irina Bolychevsky
CKAN Product Owner

The Open Knowledge Foundation (http://www.okfn.org)
**

More information on CKAN: http://ckan.org/

Follow me on Twitter: http://twitter.com/shevski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130214/0697b855/attachment-0001.html>