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 _______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
