nyuuzyou/wikis huggingface dataset:
Proposal for RM 20.11 joubu

I (Jonathan Druart aka Joubu) propose to continue and serve as Release Manager for the development cycle of the version 20.11 of Koha.
= Previous RM candidatures =
Can be found at Proposal for RM 17.11 and Proposal for RM 18.05.
= Goals and focus =
I am going to continue and bring forward the give and take approach, and work closely with the active community members.
Knowing the needs of some of you, I will try and help on the different topics along the release cycle:
* REST API and its use within Koha
* Elasticsearch
* Improve the error handling (logging, exceptions, trace)
* Translatability (make things more translatable)
* Code stability (refactoring, test coverage, etc.)
A RM 20.11 board will be created for use by the community members who are willing to participate (detail will be discussed with the team).
= RM priorities =
I am trying to keep up-to-date a list of my priorities (ie. what I want to see moved forward/what I want to be worked on)
https://hebdo.framapad.org/p/9gkb-joubu_koha_priorities
On bugzilla there are 2 useful keywords to follow: rel_20_11_target and RM_priorities
= Timeline =
Koha 20.11 will be released end of November, if it is considered stable enough for release (i.e. if it has been thoroughly enough tested)
Proposal for RM 21.11 joubu

I (Jonathan Druart aka Joubu) propose to continue and serve as Release Manager for the development cycle of the version 21.11 of Koha.
= Previous RM candidatures =
Can be found at Proposal for RM 17.11, Proposal for RM 18.05 and Proposal for RM 20.05.
= Goals and focus =
I am going to continue and bring forward the give and take approach, and work closely with the active community members.
Most of my time will be on RM duties and help the 21.11 roadmap topics
Again, a special attention will be put on test coverage.
Any changes to a module must be tested (no more exceptions for SIP, EDI, etc.)
= RM priorities =
On bugzilla there are 2 useful keywords to follow: rel_21_11_candidate and RM_priorities
= Timeline =
Koha 21.11 will be released end of November.
Proposal for RM 22 05 fsomers

This is my proposal to serve as Release Manager for Koha 22.05. 
== Overview ==
Member of the community since 2010 🦕 on Koha 3.2, I've been several times Release Maintainer 🛠️.
Now it is time to see big and walk into the footsteps of great Release Managers 👑, like my boss Paul Poulain for 3.8.
My plan is simple : be there for the community 👋.
Biblibre will allow me 3 days per week for this role.
Note that I live in Tahiti 🌊 so UTC-10 and I work in the morning plus from 20:00 to 23:00 local time to connect with the other part for the world.
Sometimes I will adapt to attend meetings.
== In details ==
Koha community has awesome skilled developers, I will rely on them to point the code in the right directions 🚀.
Also RM assistants are in several countries 🌍, it will help to have someone available for American and European continents working hours.
Like Joubu, I will help to continue the work on 21.11 roadmap topics.
Last but not least I hope to help new members to enter the community and feel like staying 😀.
== Contact ==
Fridolin SOMERS 🦄
Punaauia, Tahiti, French Polynesia.
Developer and Sysadmin at Biblibre, France.
Contact me on IRC chan #koha @fridolin or <fridolin dot somers at biblibre dot com>.
Category:Release_Management
Proposal for RM 22 11 tcohen

This is my proposal to serve as Release Manager for the Koha 22.11 cycle.
== TL;DR ==
Have an awesome cycle where we all accomplish our goals. And be happy :-D
== Overview ==
The Koha community has a well established workflow for test-driven development. I’d like to see our team continue with this solid approach of cooperative development, finding out where the bottlenecks are and providing a workaround where needed.
My main goals if elected would be:
* Promote the adoption of (yet more) coding guidelines and improve our onboarding docs for new developers.
* Heavily rely on module maintainers.
* We are getting into speed with the codebase modernization: the API is getting interesting, code is being actively moved to our OO namespace with good results in terms of maintainability and is well tested now.
* Discuss ways to attract new developers, with new POV, specially now we have started the transition into using new tools like Vue.js.
== Release management: a team ==
There's a lot of people in the QA team, and that's exciting. I will count on the QA team manager for prioritizing work, and will try to have direct contact with support providers so they also prioritize bug fixes more consistently.
== Major goals ==
* On the 22.05 release, and notably during the hackfest, a bunch of devs put our grips on the great background jobs infrastructure Jonathan added (kudos for Joubu). I would like to encourage more work in the area so we entirely remove the *need* for CGI tasks. There's still some work to be done on parallel excecution.
* Vue.js integration. Will keep a close look at the work being done on ERM and organize meetings to discuss technical decisions and their consequences. I'd like someone to pick on the main admin page to move it into using Vue.js as well.
* There's an open bug for merging reserves and old_reserves. I'd like to see that pushed early next cycle, along with the issues/old_issues counterpart. 
== Timeline ==
*I’d keep the current 6-month timeline for the release
Category:Release_Management
Proposal for RM 24.05 Katrin Fischer

=== About me ===
* Librarian with some developer skills
* Working at Bibliotheksservice-Zentrum Baden-Württemberg (BSZ) 
* Long term member of the Koha community
* Had a lot of different Release Team roles over time, including one year as RMaint for 17.05/17.11
* Currently known as your friendly neighborhood QA Manager
=== Goals ===
==== Organization ====
* I'll try to spend time on RM tasks (pushing, communicating) every work day. The times might shift a little depending on my other responsibilities.
* I'll be reachable on IRC as always and through my work e-mail. I'll also try to follow the bug updates on bugzilla, so leaving a comment there for non-urgent things will work just as well.
* I won't be around on IRC permanently, please don't rely on @laters. If it's urgent and I am not there, please e-mail instead and I'll get back to you as soon as possible.
==== Keep the queue moving ====
* I'll try to stick to a system as strictly as possible:
** Bugs will have first priority and be pushed first.
** Any enhancements and new features will be pushed chronologically, from oldest to newest in the queue.
** If something fails in testing and needs a follow-up, it will keep its original priority at first. If it takes a longer while to hear back, it will move back into the queue waiting its turn.
* My skill set is different to that of former Release Managers which means I will have to do some things differently. This will include asking for help and second opinions/additional reviews where I feel something needs deeper code/programming knowledge.
==== Roadmap ====
Road map 24.05
I'd like to create the road map a little differently:
* I propose to start with 2 sections on the road map wiki page: proposals and accepted road map items.
* A road map item will be accepted to the list, if it has a lead (someone who feels responsible and that I can reach out to) and at least 2 supporters (testing, QA, code golf).
* All those people should expect to get emailed by me eventually :)
Proposal for RM 24.11 Katrin Fischer

===About me===
*Librarian with some developer skills
*Working at Bibliotheksservice-Zentrum Baden-Württemberg (BSZ)
*Long term member of the Koha community
*Had a lot of different Release Team roles over time, including one year as RMaint for 17.05/17.11 and Release Manager for 24.05
===Goals===
====Organization====
*I'll try to spend time on RM tasks (pushing, communicating) every work day. The times might shift a little depending on my other responsibilities.
*I'll be reachable in Koha chat and through my work e-mail address. I'll also try to follow the bug updates on Bugzilla, so leaving a comment there for non-urgent things will work just as well.
*If it's urgent and I am not in chat, please try an e-mail instead and I'll get back to you as soon as possible.
====Keep the queue moving====
*I will be reviewing bugs and pushing patches in the sequence of the "Patches ready to push" list on the dashboard. These are the basic criteria:
**Anything that fixes Jenkins failures will be pushed with high priority.
**Bugs will have second priority over enhancements.
**Any enhancements and new features will be pushed chronologically, from oldest to newest in the queue.
**If something fails in testing and needs a follow-up, it the query is set up so it jumps back to the top of the list. If things take a long while to bounce back, I might push them down in queue a bit.
*My skill set is different to that of former Release Managers which means I will have to do some things differently. This will include asking for help and second opinions/additional reviews where I feel something needs deeper code/programming knowledge.
====Roadmap====
I'd like to refine the road map a bit more from the 24.05 (Road map 24.05) version.
*We will have 2 different tables on the page: Planned projects and Community projects.
**Planned projects can be anything that you want to advertise and to get more people interested in for this cycle. There will be no requirements for this item.
**Community projects are supposed to be bigger goals that will need more resources from more people and may require agreeing on a project time frame and even freezing master. These will require backing from different community members to make the list.
*You can add proposals to both tables at the beginning of the cycle and we will discuss about placement at the Development meetings.
Proposal for RM 3 18 tcohen

This is my proposal to serve as Release Manager for Koha 3.18.0.
== Overview ==
The Koha community has a well established workflow for test-driven development. I’d like to see our team continue with this solid approach of cooperative development, finding out where the bottlenecks are and providing a workaround where needed. 
My main goals if elected would be:
*Continue Galen’s effort on “everything needs a unit test”. More documentation on ‘best practices’ would be great. This matter should be subject to broader discussion with the QA team (and the rest of the dev team).
*Trust a team of elected Module Maintainers (at least) for critical modules maintenance.
*End-user in mind.
*Codebase maintenance.
== Release management: a team ==
Even when the RM retains the ultimate right to decide what does or does not get pushed to master, I’d encourage people from the QA team and past release managers/maintainers to become Module Maintainers.
Communication would be key, and pull-requests from topic branches would be my ultimate goal for this term.
== Major goals ==
As every RM, I’ll try to reduce the backlog of patches that always accumulates over time. I also have some specific goals:
*Help people working on search engine abstractions and search code refactorization get their work ready for production.
*Prepare for a convergence between the-packages-way and source installs. A new ‘cluster’ install method for source code installs might emerge.
*I’d like to see some project source code reorganization. This could only happen if we provided some backwards compatibility.
== Timeline ==
*I’d keep the current 6-month timeline for the release (dates may vary), thus:
*May 2014 (after 3.16 is released): I’d start pushing to master, for 3.18.0
*September 2014: Probably some pre-pre-alpha 3.18 - after this point, major architectural changes will be discouraged
*End of September 2014: (Soft) Feature slush
*October 2014: Feature freeze
*November 2014: String freeze
*End of November 2014: release of 3.18.0
Category:Release_Management
Proposal for Wiki Curator24.05 Will1410

I'd like to re-organize the jQuery library (https://wiki.koha-community.org/wiki/JQuery_Library) by dividing it into sections - in a similar way to how the SQL library has been reorganized. Specifically, I'd like to reorganize the jQuery so that it's organized by Staff interface/OPAC and then by module. It would be really helpful, for example, if all of the circulation jQuery was grouped together in one section (or possibly its own page) and acquisitions jQuery was grouped together, and so on.
Similarly, I'd like to update and reorganize the Notices and Slips Library (https://wiki.koha-community.org/wiki/Notices_and_Slips_Library). There had been some work to that end in the past that was left unfinished and I'd like to do some work on finishing up what was started and updating many of the existing examples with template toolkit syntax.
Proposal jcamins RMaint 36x

= Proposal for Release Maintainer for 3.6.x During the 3.10.x Release Cycle =
== Summary ==
With the 3.10 release cycle, Chris Cormack and I have proposed to divide the RMaint duties, with Chris managing the 3.8.x branch and me managing the 3.6.x branch. In the interest of stability, I propose the following change to maintaining 3.6.x:
Rather than cherry-picking commits off of master (or 3.8.x) directly onto the 3.6.x as soon as they are committed, I propose imposing a 1-month (or so) embargo on all non-security fixes, so that any unforeseen regressions will (hopefully) be caught and fixed on the master branch, and not deployed to a stable version. To accomplish this, I propose using two git branches for 3.6.x. The first branch will be 3.6.x-testing, which will have the code proposed for 3.6.x but not out of the embargo period. After they have passed their embargo period, commits on 3.6.x-testing will be cherry-picked onto the existing 3.6.x branch for incorporation into the next release. Note that the 3.6.x-testing branch *is not intended for production use*. Rather, it is intended to increase the transparency of the release process.
Category:3.10
Category:3.6
Proposals for KohaCon12

It's time to start thinking about KohaCon12. Organizations that want to host the event are requested to add the details of their proposal to the table below, and create a separate page for further details. It is customary that the final decision will be made through a vote open to the whole Koha community. 
== The rules ==
No single country can host KohaCon two years in a row, so since KohaCon11 is being held in India, proposals from India for KohaCon12 are probably not necessary. 
== The time ==
The proposing organization decides what time they want to hold the conference. Some people have expressed their preference in this Doodle poll.
== Deadlines ==
* Deadline for proposals: 1st September 2011. - This deadline is now passed and it is too late to add more proposals! 
* Deadline for voting: 1st October 2011
==The result==
Edinburgh, Scotland, UK.
== The Proposals ==
=== Summary Table ===
Please edit this table and add any information you have. (The format of this table is the same as the one for the KohaCon2011 Proposals, so if you want to re-use a proposal you should be able to copy and paste from there.)
Location 	Hosting Organization 	Contact 	Proposed Dates 	Proposed Cost 	Local Hotels 	Restaurants in Walking Distance 	Local Libraries and Library Science Work 	Arts/Entertainment in Walking Distance 	International Airport Options
Edinburgh, Scotland, UK	software.coop (IYC 2012 is also our 10th anniversary) and other tbc	MJ Ray, citing ref 2612	tbd on venue availability, prefer June to avoid festival season	free to attend, costs to be covered by finding sponsors	"huge choice" 	"vast selection" 	Several Scottish national libraries, universities	Lots, as you would expect in a capital city. See wikitravel	EDI (incl Newark+Atlanta), GLA (incl Toronto, Dubai+Lahore), PIK (Ryanair/Wizzair), ZXE via LHR/LGW/LUT/STN
Reno, NV USA 	Washoe County
Library System 	Nancy Keener 	tbd 	unknown 	top rated hotels & casinos	numerous, wide variety http://www.visitrenotahoe.com/	Academic, Public, Law 	numerous, wide variety http://www.visitrenotahoe.com/ 	Reno Tahoe
International Airport
Please feel free to create links to a page with further details if the table above feels too constrained. And to re-use pages from earlier proposals!
Category:KohaCon12
Public patrons password endpoint RFC

This RFC should be the basis for making a public endpoint for changing patron's password.
== Actions and routes ==
The following table presents proposed implementation.
Description 	Action	Proposed
Update password	POST 	/public/patrons/{patron_id}/password
== Request body ==
Attributes 	Description
password 	New password (plain text)
password_repeated	Repeated new password (plain text)
old_password 	Patron's original password
Category:RFCs
Public patrons privacy endpoints RFC

This RFC should be the basis for endpoints to be used to change a patron's privacy settings themselves. This is being worked on 
== Actions and routes ==
The following table presents proposed implementation.
Description 	Action	Proposed
Allow guarantor to see fines 	PUT 	/public/patrons/{patron_id}/guarantors/can_see_charges
Allow guarantor to see checkouts	PUT 	/public/patrons/{patron_id}/guarantors/can_see_checkouts
== Request body ==
Edited by tcohen:
The request body will be a JSON object containing a single attribute: 'allowed' being a boolean
== Discussion ==
+1
--Kfischer 06:34, 22 September 2019 (EDT)
Category:RFCs
Purchase Approvals Process

= Acquisitions - Purchase Approvals Process =
Many Academic libraries in India follow a purchase approval process. 
== Process Overview ==
1. Enter list of titles by vendor, capture biblio and administrative details like price, number of copies to purchase
2. Create a purchase approval request by selecting all or a subset of titles available from step 1 above. A unique approval request number is generated.
3. Print the approval request form and circulate to the library committee for approval.
4. Update the approval status (approved, rejected) of each title.
5. Create a purchase order by selecting titles that are approved. The titles may belong to different approval requests.
== Approval Request Number ==
The unique approval request number is used to link information on the ILS to paper files and registers. The number can be auto-generated by the ILS or staff can enter the number manually. 
== Approval Record Use Cases ==
Following use cases must be supported:
Add, edit or delete approval records
Add, edit or delete titles within approval records
Update approval status (approved, rejected) for each title
== Information Retrieval Use Cases==
Use cases that must be supported are:
Find approval requests related to a purchase order
Find purchase orders related to an approval request
Find titles related to an approval request
Find approval requests for a vendor
View log records of updates to approval records
== System Preference ==
A system preference will control whether approval process will be active or not.
== Modifications to Koha's Order Process ==
Currently titles are added to an order basket from various sources - purchase suggestions, existing catalog, new record etc. 
We propose to create the approval process at this stage - instead of adding titles to an order basket, titles will be added to an approval request form.
When creating or editing an order basket, only titles that are approved for purchase can be added to the basket.
== Open Questions ==
Do we need any new permissions to control who can perform the approval tasks? 
Do we need granular permissions to control access to steps within the approval process? 
What are the commonly used formats for the approval request number? 
Format of the approval request form (for printing)
Category:Acquisitions_RFCs
Category:Koha_3.4_RFCs
Pybugz configuration

pybugz is a command line utility to interact with bugzilla. I was looking for a command line tool to retrieve information from bugzilla like status, comments, without having to go on the webpage (I didn't found equivalent with git-bz).
= Get pybugz =
Go where you want ($PATH), run: 
 cd $PATH
 git clone https://github.com/williamh/pybugz pybugz
To install it run: 
 python $PATH/pybugz/setup.py build
 sudo python $PATH/pybugz/setup.py install
= Configure pybugz =
Minimal configuration file $HOME/.bugzrc
 [Koha]
 base: http://bugs.koha-community.org/bugzilla3/
 user: USER@EXAMPLE.COM
 password: PASSWORD
You can do an alias in your ~/.bashrc file for example: 
 alias bugzz='bugz --connection Koha'
Or without the configuration file:
 alias bugzz='bugz -b http://bugs.koha-community.org/bugzilla3/ -u $USER -p $PASSWORD '
 source ~/.bashrc
= Using pybugz =
 $ bugzz search datatable
 * Using http://bugs.koha-community.org/bugzilla3/ 
 * Searching for 'datatable' 
 * Already logged in.
 6836 julian.maurice jQuery plugin Datatables integration
 * 1 bug(s) found.
 $ bugzz get 6836
 ...
 Title : jQuery plugin Datatables integration
 Assignee : julian.maurice@biblibre.com
 Reported : 2011-09-02 10:31:00 +0000
 Updated : 2011-10-31 09:48:59 +0000
 Status : ASSIGNED
 Severity : enhancement
 Priority : PATCH-Sent
 ...
 $ bugzz get 6836|egrep -i "(status|priority)"
 Status : ASSIGNED
 Priority : PATCH-Sent
 $ bugzz search --assigned-to julian.maurice@biblibre.com --show-status
 => Find all bugs assigned to julian
* Read some documentation
= References =
*https://github.com/williamh/pybugz 
*http://www.liquidx.net/pybugz/
= See also =
*Git BZ
Category:Development
QA Manager for 3.6 Proposal

== Candidate: Ian Walls ==
*Continue practice of minimum 1 signoff for patches from someone other than the author 
*For larger devs and bug fixes, require a rigourous test plan 
**Tell the community how we can tell that your code actually works, and doesn't break other stuff. 
*Push for more unit tests 
*Push for a robust example DB to test against 
**This should be a full Koha database that can be loaded into MySQL and tested against. 
**Dates should be in relative SQL (CURDATE +/- days)
**Lots of notes as to which patrons, items and holds are good for testing what kind of things
**Addition of new data will be welcomed from any and all community members
*Regular reports to list and at IRC meetings of the statuses of devs that are 'in QA'
If possible, I'd also like to coordinate with area library schools, and get students to test parts of Koha for credit and experience. This is subject to many factors and thus cannot be promised, but it's an option I intend to explore.
Category:Quality_Assurance_Testing