[Koha-devel] KohaCon11 hackfest: discussion

MJ Ray mjr at phonecoop.coop
Tue Mar 22 12:27:34 CET 2011


Paul Poulain wrote:
> I proposed during the first IRC meeting to split the hackfest in 2
> sub-parts, each of them dealing with one goal:
> * Hackfest part 1 = "become a Koha developper"
> * Hackfest part 2 = "do some hacking".
> We could say part1 is about theory, and part2 is about practising what
> we've learned on part1 ;-) (and of course, ppl coming for part1
> would/should/could stay for part2 !)

I think splitting it would be helpful, especially if the two parts
could take place in parallel somehow.

[...]
> How long could/should it last ? There are 2 opinions here:
> - staying & taking time is expensive, so not too long
> - once you're here, we must make the trip worth, so as long as possible
> What's your opinion on this matter ? Mine is that once we're here, we
> must stay as long as possible, those meetings are precious.

Wow, way to misrepresent the other opinion! :-( I feel most people
agree that once we're there, we must make the trip worthwhile, so
spend as long as *reasonable*.

The difference in opinion is really: what is reasonable?

It's *possible* for an Englishman to spend something like 6 months in
India, so that's "as long as possible" - would anyone argue for a 6
month KohaCon and hackfest?  I think kmkale would get bored with us!

Every extra day is extra cost for the Koha libraries which fund that
developer and it's probably even more costly than our usual community
participation.  I'm pretty sure that several developers were working
silly hours while in NZ so that they could continue to support their
libraries without reducing their participation - that's unhealthy and
not to be encouraged IMO; while some were being a burden on colleagues
who did/ could not attend because someone was left at home to "watch
the shop".

As many of us are painfully aware, there are some Koha support
companies which are not participating in these events at all.  How do
we avoid handing them an advantage?

In the surveys I've seen and done, most libraries don't care whether
or not suppliers take part in hackfests.  I wish it wasn't so, but
that's how it seems to be.  (Anyone got evidence to contradict it?)

A basic question is: what is in the hackfest for developers?
My biggest limitation is spare time to hack and having a hackspace
full of people talking all day doesn't increase that time at all.
I feel guilty if I'm in the room but ignoring someone giving a talk!

So, change 1: ditch most of the talks, or move them out of the main
hackspace, or only have a short one at the start of each session.

Change 2: pick themes for at least some sessions.  There were a few
good possibilities for KohaCon10 hackfest (persistance, template
toolkit and 3.6 features would have been my favourites) but I didn't
really get time to hack on any of those.  It felt like someone stood
up with a new theme as soon as one person sat down.  Maybe it got less
hectic in later days, but that goes back to my earlier points: I feel
guilty if I don't watch talks and extra days are expensive.  (And in
my case in NZ, impossible - because of other constraints, I couldn't
take extra days then and I *really* wanted to see Marlborough.  I
didn't even get to see some stuff in Wellington I wanted to. :-/ )

Thirdly, Change 3: I'd label some of the veteran devs "roamers" for
each session and introduce them at the start.  Roamers would go from
desk to desk, offering helps and seeing what's being hacked, to
summarise in a lightning talk at the close.  Then those developers are
not expecting to hack in that session and there's people who new
hackers know they can interrupt without disrupting.

I'll stop here for now (having just lost more hacking time) but let
me know if anyone likes those change suggestions.

Hope that helps,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
http://koha-community.org supporter, web and LMS developer, statistician.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha


More information about the Koha-devel mailing list