nyuuzyou/wikis huggingface dataset:
Remote training

= Remote training =
With the COVID-19 crisis, libraries are asking for remote training sessions. This page can help organizing your seminars ! 
== Schedule ==
Introduction to the Digital experience: We will cover the OPAC, how it works and allow staff to get comfortable with the OPAC interface. 
#The Path of the Patron: The circle of patron activity from registration all the way through lost books, damaged items and everything in between. 
#The Life Cycle of the Book (Part 1): We will walk staff through the acquisition process, cataloging, and withdrawing/removing materials. We will follow a title from its birth to death inside the ILS. 
#The Life Cycle of the Book (Part 2): Continuation from part 1 
#Freedom to Change: We will demonstrate the administrative side of the Path of the Patron and Life Cycle of a Book. We will review reports, tools and system preferences and how they relate to each of these processes.
If libraries want to use acq or serials or to go really deep into cataloging they need more time. Benefit of webinars is it’s relatively easy to tack on more as needed. 
== tips and tricks ==
Manage expectations - It’s really hard to get as much connection and hands-on work over a webinar. 
=== people ===
*Shorten times - We usually do webinars in 2 hours blocks. That seems to be all the attention span most folks have for it in a day. 
*Break every hour.  Take a 5 min break, let them get a cup of coffee, get up and stretch their legs. 
*Stay animated!
*Have them talk about a process that leads into the next action, sometimes this helps refocus attention when you notice a lack of involvement. They feel more invested when leading the conversation.
*Offer to meet several times after webinar training for Q&A and workflow questions. 
*participants seem to have less energy for remote training than in-person training
=== technical aspects ===
*Don’t assume the librarian will be comfortable with Zoom. Some time spent familiarizing them with it is worth it! 
*Have your camera on! 
*Have their camera on, too, if possible. We’ve even talked about sending folks a webcam when they don’t have one. 
*If they are comfortable, let them share their screen and walk through creating a patron, going through the lost process, adding an item to a record, etc. 
*it's harder to monitor their progress, since you can't look over their shoulders and do as much one-on-one work
*Offer to record the sessions- this will ease the idea that they have to remember everything! 
*Upload the recording and make them available to download
Rendered hold slip with barcode

Date: 11/22/2016
Hold at Middletown
ITEM ON HOLD
If on a Winter's Night a Traveler
Italo Calvino
 279
 FIC CALVINO
 1
Notes:
Remember to tell the borrower that this
is a signed copy; be careful with it.
Chittenden, Barton
 6543
 502-555-7890
Report to find bad smsalertnumbers in Sweden

If you set up Koha to send text messages/SMS'es you need to fill the smsalertnumber for patrons that want to receive text messages. The SMS-drivers are quite particular about the format of the phone numbers in this field. The following report should pick out some of the numbers that are wrong:
 SELECT CONCAT('<a href=\"/cgi-bin/koha/members/memberentry.pl?op=modify&borrowernumber=',borrowernumber,'&step=5\">', borrowernumber, '</a>') AS borrowernumber, firstname, surname, smsalertnumber 
 FROM borrowers 
 WHERE smsalertnumber != 
 AND ( LENGTH (smsalertnumber) < 12 OR LEFT( smsalertnumber, 1 ) != '+' )
The borrowernumber will be a clickable link that takes you to the screen for editing the smsalertnumber.
Category:Sweden
Requiring items RFC

Would that seem a sensible approach to you?
Edit From HDL
Very Nice feature.
But Is this the way to implement that ? should it not be managed via a kind of holding level ? a “virtual” holding would be linked to all the holdings in the subset. And we would check the father only when all children are checked out.
We need the same kind of father/son relations for Biblios, and we have kind ot that for authorities. This would allow to have the list of all the holdings of the subset on screen at once when trying to check out a single item of that set. Just my 2 cts.
Response from MJR
This has been delayed by non-enhancement matters. It needs a wider discussion of parent-child biblio relations which I have not initiated.
May relate to Holdings or summary records RFC and Analytic Record support
Category:RFCs
Category:Circulation_RFCs
Category:RFCs_not_targeted_at_a_particular_Koha_version
Resolve Merge Issues

The following tutorial will walk you through resolving merge issues in your git repository. Should you encounter errors when doing a rebase of your branch, you will need to follow these steps:
* Fetch updates with git fetch
* Rebase your branch with git rebase
* If there is an error it might look something like this:
: Applying BUG 2761 Fix max length of itemcallnumber to 255
: error: patch failed: installer/data/mysql/kohastructure.sql:932
: error: installer/data/mysql/kohastructure.sql: patch does not apply
: error: patch failed: installer/data/mysql/updatedatabase.pl:2500
: error: installer/data/mysql/updatedatabase.pl: patch does not apply
: error: patch failed: kohaversion.pl:10
: error: kohaversion.pl: patch does not apply
: Using index info to reconstruct a base tree...
: Falling back to patching base and 3-way merge...
: Auto-merged installer/data/mysql/kohastructure.sql
: Auto-merged installer/data/mysql/updatedatabase.pl
: CONFLICT (content): Merge conflict in installer/data/mysql/updatedatabase.pl
: Auto-merged kohaversion.pl
: CONFLICT (content): Merge conflict in kohaversion.pl
: Failed to merge in the changes.
: Patch failed at 0001.
* updatedabase / sysprefs / kohaversion are the main source of merge conflicts
* The above error says that there are two files that need to be cleaned up
** installer/data/mysql/updatedatabase.pl
** kohaversion.pl
* You can also find files that had merge issues by doing a git status
* In the case above git status returns 2 files that are 'unmerged'
** unmerged: installer/data/mysql/updatedatabase.pl
** unmerged: kohaversion.pl
* Open up the file in the editor of your choice and look for the lines that caused the conflict
** It will start with «««< HEAD: and end with »»»>
** In the case of the conflict in kohaversion.pl, it looks like this
: <<<<<<< HEAD:kohaversion.pl 
: our $VERSION = '3.01.00.045';
: =======
: our $VERSION = '3.01.00.042';
: >>>>>>> BUG 2761 Fix max length of itemcallnumber to 255:kohaversion.pl
* To fix this conflict you will need to delete all but “our $VERSION = '3.01.00.045';”
* Generally all you need to do is delete the ««. ====, and »» lines. In fact, the general principle for resolving merge conflicts is that you want the resulting state of the file to be what you want
* Once the files it edited, save it and then git add it to the repository
* Repeat those steps for all conflicts before continuing with the rebase
* git rebase –continue
* Sometimes after you fix the conflicts you might get an error message
: Applying BUG 2761 Fix max length of itemcallnumber to 255
: No changes - did you forget to use 'git add'?
: When you have resolved this problem run "git rebase --continue".
: If you would prefer to skip this patch, instead run "git rebase --skip".
: To restore the original branch and stop rebasing run "git rebase --abort".
* This error is okay and does not list any conflicts so you can simply skip it
** git rebase –skip
Category:Git
Retain GPL 2 for Koha 3.4 - 150 word advocacy

This page is reserved only for an 150 word summary advocating GPL 2, invoked with an or later version option, for Koha 3.4. The summary is part of a ballot process for inclusion in a ballot on the question of upgrading the Koha copyright license.
Please use the Retain GPL 2 for Koha 3.4 - Advocacy wiki page for more detailed advocacy linked from the summary.
Please use the Koha GPL 2 option wiki page or the Koha mailing list for open comment.
==Retain the GNU General Public License version 2 (GPL 2), invoked with an or later version option, as the copyright license for Koha 3.4 - advocacy==
==Summary (150 words at most)==
Category:Koha_copyright_license
* Reason 1.
* Reason 2.
See http://wiki.koha-community.org/wiki/Retain_GPL_2_for_Koha_3.4_-_Advocacy for more detail.
Retain GPL 2 for Koha 3.4 - Advocacy

This page is reserved only for advocacy of GPL 2, invoked with an or later version option, for Koha 3.4 as part of a ballot process on the question of upgrading the Koha copyright license. Please use the Koha GPL 2 option wiki page or the Koha mailing list for open comment.
==Retain the GNU General Public License version 2 (GPL 2), invoked with an or later version option, as the copyright license for Koha 3.4 - advocacy==
==GPL 2 Text==
See GNU General Public License version 2 (GPL 2) from the Free Software Foundation (FSF) for the full text of the license.
==Simplicity==
It has been around much longer (20 years instead of only 4), more users and developers know it already than any other license in this ballot and it's about half the size of GPL-3:
 lines words chars
 339 2968 17987 /usr/share/common-licenses/GPL-2
 676 5644 35068 /usr/share/common-licenses/GPL-3
That means half as much licence text for new users and developers to read, saving a huge chunk of community time which is better spent improving Koha, participating in the community or simply making library catalogues better!
==Cheaper and Easier Compliance==
We already use this licence, a lot of good clean-up work has been done to bring us closer to best-practice compliance, while the other options have lawyers saying troubling phrases like "I'm not sure the community has come to a consensus on it, nor am I aware of any definitive statement on the limits of this requirement by an authoritative source such as the FSF. I think you are right to read it fairly expansively, and that including the source for required Perl modules is a good plan." (under "AVOIDING AGPL 3 VIOLATIONS" in [this koha discussion])
Depending on how that uncertainty is resolved, an AGPL-3 Koha may have to offer downloads of the source code for all Perl modules used; and owners of servers that run Koha may need to buy contracted service from git hosting providers (the hypothetical token-fee services do not exist: cheapest github is US$7/month and gitorious US$99/month) or accept an unlimited download cost liability.
Compare that to retaining "GPL 2 or later" which costs us nothing extra.
==Easier with Greater Compatibility==
There is currently no code that we want to integrate which requires a change of licence.
While we use "GPL 2 or later", we are keeping our options open: this is the only choice which is allows us to choose either "GPL 2" and "GPL 3 or later" at some point in the future, when there is code that we want to integrate which requires a licensing change.
Let's keep our options open: vote "GPL 2 or later" as your preferred option.
Category:Koha_copyright_license
Return claims endpoint RFC

This RFC should be the basis for making the suggestions endpoint follow the guidelines. Bug has already been filed and patches submitted : https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14697
== Actions and routes ==
The following table presents the current implementation, and the proposed changes. 
Description 	Action	Proposed path
Make a claim 	POST 	/return_claims/claim/{item_id}
Update claim notes	PUT 	/return_claims/{claim_id}/notes
Resolve a claim 	PUT 	/return_claims/{claim_id}/resolve
Delete 	DELETE	/return_claims/{claim_id}
== suggestion object definition ==
Object definition will match the table definition 
DB 	API
id 	id
itemnumber 	itemnumber
issue_id 	issue_id
old_issue_id 	old_issue_id
borrowernumber	borrowernumber
notes 	notes
created_on 	created_on
created_by 	created_by
updated_on 	updated_on
updated_by 	updated_by
resolution 	resolution
resolved_on 	resolved_on
resolved_by 	resolved_by
All 200 responses will return the newly updated object as JSON. 
== Comments ==
* itemnumber should be item_id
* borrowernumber should be patron_id
* issue_id should be checkout_id
* *_on should be _date
* *_by should be discussed to include _id as they reference ids
It looks like this bypassed the voting process?
--Kfischer 02:02, 14 January 2020 (EST)
Category:RFCs
Rfc 3.10 webinstaller improvements

The web installer hasn't changed in a long time. It's time to fix it up a bit. :)
Proposed ideas for the web installer:
*have a web interface to generate translations at install time.
*create an alternate administrative user that is not the DB user for initial login.
*give option to define your first library as part of initial install
*give option to create (or install by default) a "staff" patron category
Nice, but not essential:
* Default "sets" - for example:
** single library
** multi-branch, independent (what preferences this flips tbd later)
** multi-branch, interdependent (ditto)
Possible preferences to ask about at install time:
* allowonshelfholds (Allow patrons to place holds on items that are currently available?)
* opacpublic (Would you like your OPAC to be public? If no, the OPAC will require a valid login to view.)
 
Possible structural changes:
*Do not allow the db user a log in to the intranet? (this has always seemed like a security risk to me)
Category:RFCs
Category:3.10
Roadmap for Koha

This page records work that is proposed for inclusion in future releases of Koha. It lists both proposed features and improvements to Koha's architecture.
The page is a memorandum of intent. It is neither a strategic plan, nor a promise. Developers and contributors are asked to keep the status of proposals up to date (for example, by linking to an issue in Koha's bugzilla repository) however we cannot assure that information on this page is current.
Unlike Koha releases, information on the page is feature based, not time based. Proposals on this page are not necessarily intended for inclusion in the next Koha feature release.
Work is added to Koha in accordance with the project's Development Workflow. The decision as to whether a particularly piece of work is included in a Koha release is ultimately for the judgement of the Release Manager. Inclusion of a proposal on this page is not a guarantee that the work will be included in a future Koha release, soon or ever.
Maintenance of this Road Map may be a continuous process. Log in to edit the page. It is intended that a review and update of the Road Map will be conducted at the Monthly IRC Meeting following each major feature release and whenever else it is considered to be needed.
Note to contributors:
* Please describe your proposal here in a line or two; consider key words carefully to assist others to locate your idea.
* Please link your proposal to another page that provides a full RFC (Request for Comment).
* If work has started, please link to an entry in Bugzilla to enable others to track progress of the work.
* Consider updating your entry when appropriate.
* Debate about an idea should not be conducted on this page: the RFC page and/or mailing list are more appropriate.
Thank you for your contributions to Koha!
----
__TOC__
== PROPOSED NEW KOHA FEATURES ==
*ElasticSearch Compatibility
Can we has cheeseburger? ElasticSearch does very cool things which we also want Koha to be able to enjoy. Catalyst and ByWater have been working on this. 
*A Badge or Achievement System
I am willing to come up with badges, barnstars, or achievements for different spheres (Patrons, Developers, Librarians, et cetera) if someone is willing to take the time and code things. For now, I have added just a few to the User Talk pages of the wiki. You can see one here: http://wiki.koha-community.org/wiki/Talk:Chris_Cormack 
*REST-apiNew_REST_API_RFC
==PROPOSED ENHANCEMENTS TO EXISTING FEATURES==
* 
*
*
== PROPOSED IMPROVEMENTS TO KOHA ARCHITECTURE ==
*Plack "officially supported"?
*
*
Category:Release_Management
Roadmap to 3.12

Taken from http://lists.koha-community.org/pipermail/koha-devel/2013-February/038846.html
= Feature slush - March 15 =
Starting on March 15, any patch adding a new feature or enhancement which
has not already been attached to a bug on Bugzilla (or submitted to Koha
via git branch) will not be considered for inclusion in Koha 3.12.
During the feature slush, enhancements/new features requiring at most minor changes for inclusion will be considered. Patches with the following issues addressed during the feature slush will be candidates for 3.12:
* Whitespace problems (e.g. tabs instead of spaces)
* Simple perlcritic errors (a disallowed "return undef;" for example)
* Typographical errors and misspellings
* Missing copyright statements
* Untranslatable strings
* Minor functionality issues or regressions that would not require any architectural changes to the submitted code to fix
* Poor commit messages
* Perltidy not run on new code
Any of the above problems must be wholly fixed in order for the patch to move forward and into 3.12, of course.
Any other problems would render a patch unsuitable for consideration prior to the release of Koha 3.12. Examples of common problems that would automatically disqualify an enhancement/new feature after March 15 (note that this list is non-exhaustive):
* Any issues that would require rearchitecting the code
* Missing unit tests
* Complicated perlcritic errors (e.g. disabling strictures or string requires)
* Missing documentation
* Passing hashes directly rather than as hashrefs when not required by an existing API (i.e. if external class A uses hashes for arguments, anything that extends A should use hashes as arguments; a new class which does not build on an existing API should use hashrefs)
* Overzealous code removal (if a patch that is removing unused code is found to have removed code that is still relevant, the patch must wait until after 3.12 regardless of whether or not the identified problem can be easily fixed)
= Feature freeze - March 22 =
Starting on March 22, no further features or enhancements will be pushed.
It will be bugfixes only from here on out. This will allow our Docs Manager
to revise the help files to reflect the features of 3.12 prior to the
string freeze, below.
= String freeze - May 1 =
Starting on May 1, no patch (other than security patches) changing
translatable strings will be accepted for Koha 3.12.0.
= Koha 3.12.0 Release - May 22 =
On May 22, Koha 3.12.0 will be released, and the 3.12 branch handed off to
the 3.12 RMaint. Depending on the preferences of the 3.14 RM, 3.12 may be
branched on May 22, or 3.12 may be branched earlier.
= Recap =
* March 15 - feature slush
* March 22 - feature freeze
* May 1 - string freeze
* May 22 - release
Category:Development
Category:Release_Management
Category:Koha_Versions
Category:3.12
Roadmap to 3.4

=Introduction=
Koha 3.4.0 is a short cycle release, aimed mostly at performance and tidy up. The release date has been called for April 22, 6 months after the release of 3.2.0.
=Release Plan=
All patches should have at least 1 signoff before the Release Manager looks at them, (exceptions will be made for trivial patches). Preferably 2 signoffs, 1 from the QA manager and 1 from someone else. Although 1 from the QA manager will suffice.
All patches must refer to a bug number, I will then push up a branch that follows this convention
* new/enh/bug_1234 - For enhancements/new features 
* new/bug_1234 - For bug fixes 
* new/awaiting_qa/bug_1234 - For patches that haven't been QA'd yet, but that I don't want to lose track of 
Branches will then be merged into master after testing. 
Branches will also be removed from master if they cause breakage, until the breakage is fixed. 
== What makes a good patch? ==
Guidelines_for_Patch_Acceptance/Rejection
==How you can keep track?==
I am keeping a log of all my work here
http://koha-releasemanagement.branchable.com/
You can comment etc if you like.
A bug status page is at http://s.coop/koha34status
= What will be in 3.4.0? =
RFCs for Koha 3.4
Category:Koha_3.4_RFCs
Category:3.4
Roadmap to 3.6

=Introduction=
Koha 3.6.0 is a short cycle release, aimed mostly at performance and tidy up. The release date has been called for October 22, 6 months after the release of 3.4.0.
=Release Plan=
All patches should have at least 1 signoff before the Release Manager looks at them, (exceptions will be made for trivial patches). Preferably 2 signoffs, 1 from the QA manager and 1 from someone else. Although 1 from the QA manager will suffice.
All patches must refer to a bug number, I will then push up a branch that follows this convention
* new/enh/bug_1234 - For enhancements/new features 
* new/bug_1234 - For bug fixes 
* new/awaiting_qa/bug_1234 - For patches that haven't been QA'd yet, but that I don't want to lose track of 
Branches will then be merged into master after testing. 
Branches will also be removed from master if they cause breakage, until the breakage is fixed. 
Bug-enhancement-patch_Workflow
== What makes a good patch? ==
Guidelines_for_Patch_Acceptance/Rejection
==How you can keep track?==
I am keeping a log of all my work here
http://koha-releasemanagement.branchable.com/
You can comment etc if you like.
= What will be in 3.6.0? =
RFCs for Koha 3.6
Category:3.6
Roles for 16.11

Anyone who wants take on any of these roles is more than welcome to put their name next to one and perhaps link to their proposal. 
Elections: General IRC meeting 4 May 2016
*Release Manager
** Brendan Gallagher (continuing) 
*Release Maintainers
** (16.05) Frederic Demians
** (3.22.x) Julian Maurice (continuing)
** (3.20.x) Chris Cormack
*Module maintainers What does a module maintainer do
** ...
*Translation Manager 
** Bernardo Gonzalez Kriegel (continuing)
*Documentation Manager 
** Nicole Engard (continuing)
** David Nind (happy to help Nicole as required and work on installation documentation)
*Database Documentation Manager 
** ...
*Quality Assurance (QA) Manager
** Katrin Fischer (continuing)
*Quality Assurance (QA) Team
** Kyle M Hall (continuing)
** Jonathan Druart (continuing)
** Tomas Cohen Arazi (continuing)
** Marcel de Rooy (continuing)
** Nick Clemens
** Jesse Weaver
** Martin Renvoize (continuing)
*Packaging Manager 
** Mirko Tietgen
*Continuous integration infrastructure maintainer (a.k.a. Jenkins) 
** Tomas Cohen Arazi (continuing)
*Bug Wranglers (the more the merrier!) What does a Bug Wrangler do
** Indranil Das Gupta (continuing)
*Wiki Curators (The more the merrier model should be considered as with some other roles.)
** Starting Mid June Brooke 18:48, 19 April 2016 (EDT) 
** Proposal from Thomas Dukleth in conjunction with Brooke and any others to further work on the proposal even if Thomas' time may be interrupted [helping his friend avoid eviction].
** David Nind
Category:Release_Management
Roles for 17.05

Anyone who wants take on any of these roles is more than welcome to put their name next to one and perhaps link to their proposal. 
Elections: General IRC meeting 2 November 2016
*Release Manager
** Kyle Hall / Brendan Gallagher ( Continuing )
*Release Maintainers
** (16.11) Katrin Fischer
** (16.05) Mason James
** (3.22) Julian Maurice (continuing)
*Module Maintainers
** Architecture, internals and plumbing - Jonathan Druart - I'd like to have the privilege to push to master bugfixes fixing critical or very annoying bugs (DBIC schema, tests, syntax, etc.)
*Translation Manager 
** Bernardo Gonzalez Kriegel (continuing)
*Documentation Manager 
** Chris Cormack 
** David Nind (happy to assist in any way)
*Database Documentation Manager 
** David Nind (happy to assist in any way)
*Quality Assurance (QA) Manager
*Quality Assurance (QA) Team
**Martin Renvoize (continuing)
** Marcel de Rooy (continuing)
** Nick Clemens (continuing)
** Tomas Cohen Arazi (continuing)
** Kyle Hall (continuing)
** Jonathan Druart (continuing)
** Fridolin Somers
** Julian Maurice
*Packaging Manager
** Mirko Tietgen (continuing)
*Continuous integration infrastructure maintainer (a.k.a. Jenkins)
** Tomas Cohen Arazi (continuing)
*Bug Wranglers (the more the merrier!) What does a Bug Wrangler do
** Indranil Das Gupta (continuing)
** Marc Véron (continuing)
*Wiki Curators (The more the merrier!)
** Proposal from Thomas Dukleth (resuming in February) in conjunction with any others, such as those who have volunteered in the past: Indranil Das Gupta, Brooke, and David Nind.
Category:Release_Management