[Koha] Proposal to form Koha Technical Committee

[MJ Ray]

Paul Poulain wrote:
> * about the timing and the discussion : I made this discussion happend.
> I started to speak of our problems/questions/doubts/fears/needs/feelings
> on koha-devel mailing lists months ago (see "BibLibre strategy for Koha
> 3.4 and next version" thread, june, 2nd), tried many times to start
> (maybe I missed to be clear enough), and was really thinking that
> kohacon was THE place to speak of this, because we all would be here.

http://lists.koha-community.org/pipermail/koha-devel/2010-June/034106.html
I saw that thread and decided, ultimately, that it was not my place to
comment on BibLibre's strategy.  I wouldn't run a business that way,
but it's up to you.

Koha 3.4 strategy is in Chris C's capable hands, so I didn't comment
on the initial post at all.  Even if I think it's not really up to
BibLibre to try to tell the RM what that strategy should be, I'm sure
it's better if I don't post it in my usual colourful language ;-)

I didn't understand that "we must have a heavily organised team"
actually meant adding more committees too, else I would have made a
counter-proposal: let's try this lean time-based release before going
to the other extreme and festooning koha-community with committees.

Past RMs trying to disempower the new Release Managers so early in
favour of a technical committee seems a bit unkind.  It's never good
if a release date slips, but it's not unique to the last release and I
think the last two BibLibre RMs didn't give 100% accurate roadmaps and
release dates either (for example, Koha 2.2.0 was announced for Sep
2004 but actually released Jan 2005) and the rest of us had to deal
with that, although it did get worse afterwards.

> [...] No shadow or hidden or anything bad (frankly speaking MJ, your
> suspiciousness is really <<don't know which word to say here. Don't want
> to offend, but let me just say it's hard to feel like guilty of
> something bad>>)

Consider this: the topic had been raised with me in private and I
explained that I felt much already was in the power of the RM, that
it's unreasonable to expect decisions to be irreversible, and that the
hackfest was a bad place to hold such a non-hacking discussion.  Then,
the day after I left, the discussion happens anyway.  I'm not saying
it was subterfuge, but you probably couldn't make it look more like
subterfuge without it actually being it.  It smells very rotten.

If you don't want people to be suspicious, don't walk softly behind
them with knives, even if you're just making sandwiches.  If you want
to be obviously honest, tell them you're going to make sandwiches
beforehand.

> * about the content of the discussion : what I/BibLibre want(ed) to
> point was that WE (the community) HAVE A PROBLEM. Believe me or not, but
> we have one, and we must deal with it !

What is that problem?  I know what problem was suggested to me, but is
it low-comment RFCs, long-term technical decisions, or something else?
This seems like an ill-framed discussion where each participant thinks
it is trying to do something slightly different.  Identify the problem
clearly at the outset, not after random examples, and then maybe some
solutions will become obvious to people.

> Let me explain what I think by taking some examples:
> * on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new
> features on circulation & announcing RFCs. NO-ONE, answered this mail.
> NO-ONE argued. We had/have a contract. So we did the job. That's a
> problem : all our customers are now live with those features. But we
> don't know if they will be accepted in the main trunk, because no-one
> said "ok, let's do it, from a strategic/feature/technical point of view,
> it's where the Koha project want to go".

http://lists.koha-community.org/pipermail/koha-devel/2009-October/032987.html

People were asked to answer on the wiki instead of the mail, so why
are you surprised no-one answered the mail?

If you've deployed a private fork with those enhancements to all your
clients, then I think that's a basic error, but you're very successful
while the co-op is still looking for more clients, so who am I to
criticise not selling real koha?  Maybe I should sell our notorious
one-library fork to clients instead of real koha?

> * last month, we sent a mail about moving to solR. Another sponsored
> work (thanks St Etienne). Some have answered. BUT : no decision has been
> taken. I don't mean here saying "ok, BibLibre, we will integrate your
> work without looking at how you did it", but no-one has said "OK,
> BibLibre, it's where the project want to go, your arguments are fine,
> there is only one problem with z3950 server that seems to be solvable.
> If it is solved, this streategic decision is taken". We have to go
> ahead, and now, if it's not accepted by the community, our only option
> will be to fork !

Maybe you didn't notice, but last month many of us were at a
conference on the other side of the world!  BibLibre may be a large
operation and able to undertake two large community efforts while
serving all its client contracts, but if I'm spending weeks away, that
means the rest of the co-op is probably working almost exclusively for
clients.  Be reasonable.

I still have the thread to review, but there are numerous questions,
some of which may be stupid (for example, what's a POC? Piece Of Cake?
Piece of Code?) and it looks like something for 4.0 rather than 3.4.

But again, you've got the contract, so ultimately, what is the
incentive for most other developers to comment now, rather than
waiting and seeing if it's any good and adaptable for mainline?

> * Last week, I wrote many mails on koha-devel to announce all our
> underway RFCs. Maybe you can argue there's something wrong with what I
> wrote. The problem is that, once again, no-one has said anything ! So,
> what must we do next ?

Maybe you didn't notice, but last week many of us were travelling
back from a conference on the other side of the world!

Have you tried leading discussions about the RFCs, instead of flooding
koha-devel with announcement emails?  I don't remember the recent
flood, so I've probably not read them yet, but a discussion is more
than an announcement with "Comments welcome" on the end.

[...]
> SO: we (BibLibre) don't want a "technical commitee", what we want is to
> have a working workflow to manage how things evolve/are improved/...
> Our workflow works quite well ... if it goes to the end. But nothing
> prevents us from having something falling in a black hole (frenchism
> suspected). And we (BibLibre) can't accept/deal with that.

Well, where are the black holes?  The main one mentioned so far is at
the discussion stage, which I think means either:

  a. it's not important to anyone else, so it's between developer and RM
to take it forward or kill it;

  b. the discussion is being led badly, which is up to the developer to
remedy, or any interested party if they wish.

If the developer does not take it forward, or does not remedy the bad
discussion, then I feel they have effectively moved it to the "dead"
state and it's just taking the process a while to catch up with that.

> Our (community) two problems may be summarised by :
> * short term problem : our workflow to deal with proposed
> contributions/features

The Koha Community side is explained at
http://wiki.koha-community.org/wiki/Category:RFCs
The rest seems like BibLibre's problem.  Why should we fix BibLibre?

> * long term problem : the strategic/major orientations of the project

I don't really see a problem with this.  To an extent, we go where
libraries and technology take us, where seems obvious and where
people are willing to try taking us.

> [...] Maybe a subset reporting to "community" could be better.
> Maybe the community can decide everything (but : who is member of "the
> community" ?).

Please don't reopen that discussion.  Koha Community was defined in
the HLT Committee setup talks.  I'm sure it's on the website.  Yep,
here it is:

  "Koha Community means those individuals and entities with a present
  active interest in the Koha Software or the Koha Project."
  http://koha-community.org/koha-project-organization/horowhenua-library-trust-koha-committee-rules/

[...]
> > an RFC Wrangling Committee, which would meet minimum once a month [...]
> Sounds like a great idea ! (and I immediatly volunteer to be a member of
> this RFC wrangling committee !)

Oh good grief.  Another committee?  If you want to wrangle RFCs,
please just get on and do it.  It would be very welcome to organise
them better, such as the "abandoned" ones attributed correctly and
those and the 3.0 and 3.2 ones being marked as done, obsolete or for
future consideration.

So could we try a time-based release and identify/remedy the problems
with the RFC process as best we can now, rather than create committees?

Thanks,
-- 
MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op.
Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster.
In My Opinion Only: see http://mjr.towers.org.uk/email.html
Available for hire for Koha work http://www.software.coop/products/koha