On Wed, Feb 26, 2014 at 12:06:19PM +1100, Nathan Hurst wrote:

On Tue, Feb 25, 2014 at 10:24:45AM -0800, Josh Andler wrote:

...

On Tue, Feb 25, 2014 at 10:10 AM, Krzysztof Kosi??ski <tweenk.pl@...155...>wrote:

...

That's true, but the rules for GSoC are quite restrictive when it comes to teamwork - I'm fairly sure that joint applications (e.g. 3 students applying to participate in this model) are not allowed at all.

This is correct. It would definitely not be allowed. They require very clear and obvious separation of work. My guess is that it's to ensure that each student is doing what they are supposed to and that they are not subject to failure due to shortcomings imposed by other students.

That, certainly. Also, whenever there are multiple pieces being developed in parallel it requires a high degree of communication to ensure both projects end up fulfilling their requirements in a compatible fashion.

The whole point of kanban is that each task is self contained. It's easy to assess what each student has done, look at the bzr logs, look at the tasks undertaken, look at their report. Students can't affect each other, because at the frontier all the tasks are independant.

When I was doing development on Launchpad we used Kanban, so I'm reasonably familiar with the process. But it's nothing magical, it is just a way to organize and coordinate sequential interdependent tasks. It still requires a fair bit of upfront planning and coordination. It's like our traditional Roadmap system on steroids (I bet we could even implement Kanban *within* Inkscape with a bit of coding if we wanted.)

The team I was on had only 6 members, and frankly Kanban was a bit overkill for us. I think it's best suited for larger teams. Or maybe teams with finer grained tasks than we had, or that require more intensive team coordination.

So, I would love to play with Kanban more in team coordination, but I think for GSoC even if we did have 2-3 students working together I'm skeptical it would help all that much.

Bryce