Salvete! Hope this makes sense. Before I say anything else, I am worried that Hea will become unmanageable in a similar fashion if the Community does not provide authorised value entries for Country, Library Type, et cetera. When I was doing the Koha Users Worldwide stuff it suffered the same info problems. The problem both wrestle with is that we want standards compliant data for at least some fields, but we want providing the information to be easy enough so that there's no barrier for entry. Arguably Hea is more important to the project than the SQL Library since it connects all of us and the Community with the outside Science. The latter can be much more useful on a day to day basis. In either case, they are both a bear for one entirely unpaid person who has to make a living. I'd love help and ideas on either or both. :)
Brooke copied the Holds, Patrons and Circulation reports, unfortunately,
many of these have fallen out of sync with the main SQL Reports Library.
This was bound to happen. Wikis are going to be messy, but they shouldn't be unweildy or unmanageable. I reorged the meeting minutes a long time ago when animals could talk, and that pattern of categorisation seems to have held up pretty well. SQL is much trickier in terms of classification, and since I didn't get much feedback, I was hesitant to do more of something if no one understood the method to my madness. So that leads us to Are the categories my addled mind assigned good enough for other Librarians and Developers? or Should we slice and dice things differently? Many reports cover two or more topics, which is what makes them so darn useful. That makes categorisation quite tricky. It's like a mini 650 for each report that needs to be called elsewhere. There are very neat things that can be done with tables in wikis, as well as other stuff we don't do that makes life much easier in an automated fashion. Again the bar is ease of contributing v. ease of finding stuff later.
I took the first step tonight, by deleting any reports that were exact duplicates, leaving a link in the old library. See https://wiki.koha-community.org/wiki/SQL_Reports_Library#Patrons_with_Holds_.... This points to the full report at https://wiki.koha-community.org/wiki/SQL_Reports_Holds#Patrons_with_Holds_Wa...
I don't think I tackled deduping when I went through since I didn't have feedback on how to handle attribution.
If you have or edited queries that deal with holds, patrons or circulation,
please check to see if your query is in the most recent form in one of the new pages, and leave a link to it from the header in the old SQL Reports Library.
Also, it would be super to just remove your report if for some reason it is deprecated or no longer functional if the Koha guts have changed too much for it to operate.
I would also like to move the other sections, although in those cases I
would prefer to move the *entire* section, and simply leave a link from the old section to the new page, simply because creating the links is a lot of work.
Yup, no dispute that it's yeoman's work. The catch is that if enough people aren't involved, it will just wreck itself in time again since there isn't a place for everything or vaguely logical waymarkers about where stuff should be. There are FAR better cataloguers and classificationists on this list than me. #justsayin Cheers, Brooke