[Koha-devel] Koha 3.6 is out, starting Koha 3.8 !

[Paul Poulain]

Hello happy hackers,

As Koha 3.6 has been released on saturday, it's time to start officially
Koha 3.8
I don't have all doors opened yet, but chris is in a plane back to NZ
and will grant all access I need and explain some things he did as RM
once he has recovered from his trip.

=== Bugzilla ===
In the meantime, I've started some work on bugzilla :
* all ENH that are "needs signoff" and/or "signed off" have been
switched to Rel_3_8 version.
* I've added a "Koha 3.8 patches" shared query that you can add to your
footers if you want.
* i'll also investigate ENH that are "failed QA" and either bump them to
3.8 or close the bug as "abandonned" if it seems it's abandonned. Of
course, the author will always be welcomed to reopen it and submit an
acceptable patch. I'll decide looking at the age of the patch, how far
is it to be acceptable, how active is the patch original author, how
interesting is it to have this ENH.
* looking at all ENH, I see there are 920 that are open. A large part of
them have had no activity for more than 1 year. A few of them maybe good
ideas, but they are not sponsored. I do the following proposition :
"i'll close all ENH bugs that are not sponsored and have had no activity
for more than nine months. For sponsored entries that have more than 9
months, i'll add a comment to ask wether we should wait for a patch or
close the bug". If you disagree, please argue. If it's OK, I'll add this
rule to the wiki.

=== Koha roadmap ===
I plan to start a wiki page with the roadmap. I'll store on this page :
  * what *will* be in Koha 3.8 = features/patches that have been
validated and are already merged into master
  * what *should* be in Koha 3.8 = features/patches that have been submitted
  * what *could* be in Koha 3.8 = features/patches that have been
announced, should be submitted in time, but you know, sometimes you
don't do what you would like to do...

I'll mark "could/should" only important things. I'll add in "will"
everything (like what chris did with
http://koha-releasemanagement.branchable.com/ ). I'll add in
"could/should" only "important" things (ie : not a minor improvement to
display a missing field, or add a link/control/...)

I also plan to split the roadmap in 2 parts :
  * functionnal => for patches that are interesting for librarians.
  * technical => for patches that are interesting for developers

I'll submit in the next days a first draft of all changes we could do in
the next months (year(s) ?). That will be ambitious, of course that will
be a 1st draft to discuss from what you want , my main goal being to
have a clear visibility of where we would like to go and who want to
endorse what.
You won't probably be surprised by what will be in this list, as it's
things we already have speaking of.

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08