[Koha-devel] Release Manager 3.6

[Tomas Cohen Arazi]

On Wed, May 11, 2011 at 2:01 PM, Chris Cormack <chris at bigballofwax.co.nz> wrote:
> Hi All
>
> Recently I have been having a crisis of confidence. I have, I hope,
> always tried to do what I think is best for the project. Often I do
> make mistakes, a notable one happened in 2007, which I hope I in part
> was rectified in 2008. But my underlying motivation with Koha has
> always been to do the best for the users of the software.
> In my role as Release Manager for 3.4 (and again for 3.6) what I felt
> was best for the software users was a stable and well tested release.
> This is something I made clear in my proposal, and which I had assumed
> was understood (but you know what they say about assumptions ;)). With
> the huge amount of work put in by over 80 people, I think we managed
> to achieve some measure of success with that with 3.4.0 and that the
> stability of the 3.2.x releases is something we can all be proud of.
>
> Over the last couple of weeks, comments and mails both on and off list
> have made me think that maybe I am out of step with what the community
> desires. For 3.6 quality was still the major goal, but perhaps I have
> misjudged what others want.  This has resulted in sleepless nights and
> quite a large amount of self doubt.

First of all, Chris++ for the hard and good work he is doing every
day. For a noob like me its leadership has been really inspiring and
I'm comfortable with the current workflow which I think .

As a 'small' (+30 libraries/koha deploys) contributor University,
we've faced several times this problem Paul brought into discussion
last year about BibLibre's difficulties to make community development
roadmap/process fit their own's, and its' business model. Even if we
are a small non-profit contributor we 'felt the same' [1].

I think it is not easy to avoid this problem: the tension between
community established roadmap and the needs of a third party's
business. Companies like BibLibre have made Koha the great piece of
software it is now (the same goes for LibLime and other companies), so
it is not just BibLibre's problem. Community and third parties
roadmaps diverge easily. As Paul said, perhaps forking is the only
solution for a business model if we don't find a proper solution.

I'd like to see an approach that provided a proper semi-formal way to
make strategic decisions on the future of the project, so that third
parties can propose the community a "big feature" or a "big change",
and the core developers can plan on how the integration will be done.
If it fits the business model (i.e. secrecy is not a need for it),
maybe even make external core devs have access to relevant information
on the inside development process: develop on the open.

I'd like to elaborate a bit more on the need for a strategic decision
taking mechanism, but i've been busy with other project for which i'll
fly to europe tomorrow. Maybe I get some more time to spend in koha in
a few weeks.

Thanks for all the hard work and good will put into this discussion.
To+



[1] We even stopped developing some features our librarians asked for
until we could understand and fit into the dev community and the
process itself. WE DON'T WANT TO FORK. Several times we had the
feeling we could have spent our money/time in a more feature-providing
way, but where confident that we could make our voice into the dev
community. Day suspension fines is a feature we proposed to develop
ourselves with some core-developer guidance but only got this answer:
"liblime has developed that, wait for them to merge their branch". We
are currently working with a small, harmless fork we can maintain
updated.