Re: [Koha-devel] [Koha] Some very sad news.

[BWS Johnson]

Dear Community,

 The gardener of godzone will be sorely missed. It was tough keeping up 
with her at any age. She was a national treasure, and richly deserved the 
international name she made for herself. Never would she have crowed about it 
on her own, of course.

https://digitalnz.org/records/30554095

  If one of the family is reading this, please contact me offlist.

In sympathy,
Brooke

>>
Sad news, let us know when the funerals are.

@community : May I suggest that we name the next release "Koha 22.11 
Rosalie" ?
>>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/

Re: [Koha-devel] KohaCon18 social stuff

[BWS Johnson]

Salvete!

  For folks passing through DCA, IAD, or BWI feel free to drop me a line. 
I'd love to meet up if you have a layover or show you around if you have a 
couple of days before Conference.
Cheers,Brooke
  ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Do you want to see a Koha 18.05 running Elastic Search in production ?

[BWS Johnson]

Salvete!
>>
just go there : https://koha.bulac.fr kudos to BULAC for this move !

And thanks to them for the developments they've sponsored (and are on 
bugzilla)

PS: they made it by themselves, so no reason to congratulate BibLibre ;)
>>
   I saw the Korean in the upper left, and I just had to try it.

   I am impressed!

   A garbage search for

한국어
   came back with results right away. It seems like search is ranked 
relevantly so that the entire word stays put. At least the seems to be the case 
on the first page in the higher ranked results. For instance, Koha wasn't 
naughty and barfed up the 

한
syllable in another word. That is hugely good news. I don't read well enough to 
know precisely how accurately it's searching, but I definitely have seen a few 
catalogues where it isn't even close.
Thanks,Brooke
  ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[BWS Johnson]

+1 to all of this.
Brooke


  From: Gaetan Boisson 
 To: koha-devel@lists.koha-community.org 
 Sent: Monday, August 21, 2017 5:59 AM
 Subject: Re: [Koha-devel] FW: Where is the BIG RED WARNING button?
   
  I really understand Jonathan's point here. He's probably become the one 
contributor with the best overall vision of the project now. I really like the 
idea of using the dashboard more and making it better. I also think Jonathan 
might need something more proactive, the dashboard requires the contributors to 
look at it and decide for themselves, but everyone is really busy, and we all 
get to make our own choices regarding priorities. 
  Two ideas i would suggest (sorry if it's redundant or has been said before): 
- why not have a "mission critical" meeting from time to time for this kind of 
issues? With the goal of defining precisely who will do what on a given issue? 
- would a small team of designated people help? A sort of Koha Kommando 
Jonathan can rely on when stumbling on something like this? It would need to be 
used carefully obviously, but i think just calling for help on the mailing 
list, irc or the dashboard dilutes the feeling of emergency, because no one is 
explicitly in charge. Maybe we (BibLibre), and other import support companies 
like Bywater and others can commit to having one person that is part of the 
emergency team? (note that I'm writing all this without having mentioned it to 
anyone at BibLibre...) 
  https://youtu.be/_MVonyVSQoM
  
  Would that help?
  
 Le 11/08/2017 à 15:40, Marc Véron a écrit :
  
 Sorry for the empty message... What I wanted to say: 
  +1 for improving the dashboard
 (I always check the dashboard first, then the Bug tracker, then the list of 
bugs to sign off, then my open bugs...)
  
  Maybe the Dashboard could contain the links to the newest bugs / changed bugs 
from the Bug trackers start page: 
  Bugs reported in the last 24 hours   | last 7 days  
 Bugs changed in the last 24 hours   | last 7 days   
  
  Marc
  
 Am 11.08.2017 um 15:34 schrieb Marc Véron:
  
 
  
 Am 11.08.2017 um 11:55 schrieb Marcel de Rooy:
  
   +1 for improving the 
dashboard Instead of listing the oldest bugs, which may not be that 
interesting, we should list the critical ones on top. The need to click on that 
line should be removed. See them rightaway. Maybe we can put these oldies 
somewhere down on the page in order to not forget them?
   

  
 ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/ 
 
 
  
 ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/ 
 
 
  
 ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/ 
 
 -- 
Gaetan Boisson
Chef de projet bibliothécaire
BibLibre
+33(0)6 52 42 51 29
108 rue Breteuil 13006 Marseille
gaetan.bois...@biblibre.com ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

   ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[BWS Johnson]

Salvete!

  Crazy idea:

  Most of our developers have been at this a while. They've submitted a lot 
of patches. Is there anyone with a machine learning knack that could apply ML 
in such a way to suggest a next patch for developers based on their prior 
submissions? 

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] FW: Where is the BIG RED WARNING button?

[BWS Johnson]

Salvete!


>>
Of course I was not talking about new contributors. My main goal for this 
release is to help new people to come on-board.
We refreshed the wiki, wrote a step-by-step how-to "signoff and write patches", 
etc.
I give personal answers to new contributors, guide them, give them quick and 
early feedbacks on their patches in order to keep them motivated.

>>

It's obvious to me how much work you're putting in Jonathan, and I 
appreciate it. Thank you. I'm glad one of your big goals is to recruit new 
people since if Koha were a kid, it would be old enough to drive in the USA.


>>
This button I am asking for is to alert support companies and regular 
developers that something is (very) urgent and need their attention. I would 
like to stop gesticulating to try getting this attention. I would like a button 
I can push to make a red blinking light on some desks. Then everybody is free 
to ignore it, but they saw it and I will not push it again. It will be easier 
for me to know that people knows, than sending emails, pinging on #koha, adding 
card to the kanban, CCing people on the bug report, without never knowing if 
they are aware of the problem.

>>

Yes.


>>
About the kanban: its goal is NOT to replace bugzilla, it has never been and 
will never be.
We are talking about two different tools. One is a bug tracker, the other one 
is a tool to manage/prioritize different tasks, group them under "Epic" (big 
works), form working groups, etc. Moreover community tasks are not always one 
entry in bugzilla, we want to track, discuss and keep history of more stuffs 
than just bugs. Taiga answered this lack. Please re-read the wiki page of the 
kanban if its goal is not clear (or ask me to update it).

>>

Thank you for clarifying this. I wasn't sure whether it would eventually 
supercede BZ or not.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Suggestions requested for a feature / enhancement based around opac-retrieve-file.pl

[BWS Johnson]

Salvete!

 I would be surprised if this is very different from some of the other 
authentication work that has already been done. ByWater did work with OverDrive 
that might be useful to think about.


 There are numerous ways to handle this. You could create a verified user 
category. They would then be alerted to the fact that you have to keep a 
maintenance log on access to certain files. This could be a simple email linked 
to a form, which the Library could then track and compile to verify that they 
did indeed opt in on a certain date. As long as your form fields were clever, 
you could automate the log for your Library staff. 


 The kicker for me is flexibility. Are you going to want a user, like a 
Professor or Department Chair, that will need access to everything the Library 
offers? Each thing with a paywall or barrier might warrant an articulation. For 
example, I might need access to PhD theses and Overdrive but not databases. 
Talk to your Library staff to see just who needs access to what so that there 
are a lot of plugs on the metaphorical authentication power strip. 


Hope this helped,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Gender-neutral pronouns

[BWS Johnson]

+1 :D


  From: Alex Sassmannshausen 
 To: Eric Phetteplace  
Cc: koha-devel@lists.koha-community.org
 Sent: Wednesday, April 19, 2017 3:23 AM
 Subject: Re: [Koha-devel] Gender-neutral pronouns
   
Hi Eric,

Eric Phetteplace writes:

> Hi list,
>
> I opened bug #18432 
> https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18432 because I saw 
> several places in the Koha codebase where the pronoun "he" was being used to 
> refer to a generic third person who could be of any
> gender. Jonathan Druart noted that this should be a coding guideline, as 
> otherwise new instances of gendered pronouns might continue to be added. 
> Perhaps it belongs on the "Terminology" page of the wiki?
>
> So here's my proposal. I'm trying to be concise.
>
> 
>
> Use gender neutral pronouns
>
> When referring to a person who could be of any gender, you should use the 
> words they/them/their. This goes for code comments, text in templates, and 
> strings in tests. For example, here's a string from a patrons test updated to 
> be gender
> neutral.
>
> Before:
>
> is( $total, $enrolmentfee_K + $enrolmentfee_J, "Kid growing and become a 
> juvenile, he should pay " . ( $enrolmentfee_K + $enrolmentfee_J ) );
>
> After:
>
> is( $total, $enrolmentfee_K + $enrolmentfee_J, "Kid growing and become a 
> juvenile, they should pay " . ( $enrolmentfee_K + $enrolmentfee_J ) );
>
> Gender neutral terms are preferable for a few reasons. They're more 
> welcoming, showing that Koha expects users and contributors to be of any 
> gender. They're also more accurate. Inappropriately using a particular gender 
> can cause confusion,
> leading someone to believe that code operates differently based on the value 
> of borrowers.sex, for instance.
>
> 

I like the proposal, thanks for putting it together!

Best wishes,

Alex

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/


   ___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] How do we find consensus on interface changes?

[BWS Johnson]

Salvete!

> For my part, I'd love to see Owen as benevolent dictator of Koha's GUI. 
> I
> think he has the most experience, interest, and skill out of all of us in
> this area.


This is +1 from me, but I should hope this discussion migrates over to the 
plain vanilla Koha list. It is where a bulk of the Users are, after all.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Kylie Brice Hall

[BWS Johnson]

Salvete!

 I would like to announce that Kyle will no longer be supported as he's 
been deprecated by Hall 2.0. *duck* Seriously, congratulations!

Cheers,
Brooke




>
> From: Nick Clemens 
>To: Todd Goatley ; Kyle Hall 
> 
>Cc: Koha ; Koha Devel 
>; All Staff ; 
>ByWater Partners 
>Sent: Friday, March 18, 2016 12:53 PM
>Subject: Re: [Koha-devel] Kylie Brice Hall
> 
>
>
>Amazing! 
>
>On Fri, Mar 18, 2016, 12:19 PM Todd Goatley 
> wrote:
>
>So awesome Kyle! He's a beauty!
>>
>>
>>Todd
>>
>>
>>On Fri, Mar 18, 2016 at 6:34 AM, Kyle Hall  wrote:
>>
>>Sent from my phone. Please excuse my brevity.
>>>On Mar 18, 2016 9:31 AM, "Kyle Hall"  wrote:
>>>
>>>Kylie Brice Hall was born at 8:41 am in Erie, Pennsylvania. Weight of 9 
>>>pounds 11 ounces.
Sent from my phone. Please excuse my brevity.
>>
>___
>Koha-devel mailing list
>Koha-devel@lists.koha-community.org
>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/
>
>
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Wiki - Delete/disable user Xdbmsx

[BWS Johnson]

Salvete!

>>  I accidentally approved a new wiki user last night (I thought I had 
> rejected
>>  it, but must have approved it :-( ).
>> 
>>  Could someone who has permission disable/block the user Xdbmsx as I 
> don't have
>>  permissions to do this.
>> 
>>  The user has also created several pages that need to be deleted.



 Hey I'm just very happy for your help, David. I feel like it's very seldom 
that any user waits more than a week or so to get access to the wiki. I try to 
check on weekends. I've been tempted to send summat out to the main list 
encouraging people to add details to their requests so we can sort out the spam 
bots easier. I end up holding or rejecting an awful lot in the name of fighting 
spam.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Need to improve anti-spam for opac-suggestions

[BWS Johnson]

Salvete!

Shouldn't that just draw on the list of registered borrowers? I'm trying to 
think of a situation where I'd take a suggestion from someone that's not a 
Patron, and in those cases they either ring the Library directly or email me.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Thoughts about timing and Koha schedules

[BWS Johnson]

Salvete!

This sounds very reasonable.
But I just want to add that August is probably not that great for releasing a 
new version. In July and August the community is not on its most active state 
of the year :)

 


I realise that developers are behind the schedule. However, if we're 
talking about a timeline that's largely the result of fiscal planning, I think 
this is a question for the wider general listserv. I would also like to add 
that there are quite a few Libraries on a September / October fiscal year or 
have serious budgetary landmarks in that date range. August has also been the 
forced date of the US Conference.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] PRESENTATION: New member

[BWS Johnson]

Salvete!

My name is Anders, working at Luleå Technical University.
My background is old-school Oracle DBA  Jwith Java/SED/AWK/Unix shell 
script/C++ and Fortran as programing languages.
Unix/Linux experience.
 
Have been walking a long way in the promiSED land, sometimes with awk as my 
brother in arms.
 
Right now, at this very moment me and some colleagues are working in a 
migration project from Aleph (Oracle) to Koha.
 
Have done a lot of programming with the database as the central part of all 
systems, most of the time I have been living inside the db J
 
Well, 
nature-photo is one of my biggest interest,
www.enfotograf.se

 


 Welcome Anders! I too like Nature photography. :) I hope you enjoy being 
part of the Community.


Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Wiki page update question

[BWS Johnson]

Salvete!

    Did someone say wiki? :D

    1) Yeah to what Mark said.
    2) There's a sooper sekrit alternate path that wikinerds are familiar with 
for stuff you might wanna keep track of but not really properly change or make 
properly public. For instance, if I'm working on a wiki todo list, I will 
prolly put it on my user talk page. Talk pages in general are tabbed off of 
their partner content pages, so you can *ALWAYS* mess with them without _rolls 
eyes_ messing anything on any given wiki up. 

    3) But really, it's not possible to mess up a wiki, since someone will just 
revert your changes if they are truly awful.
    4) Given enough time, I will try and suss out what y'all want and do eet to 
the wiki so as to ensure that y'all don't have to split dev time and wiki time. 
Pokings are welcome. In this case I *think* Martin has you on the right track, 
but lemme know off list if you still want me to kick tyres.


Cheers,
Brooke


 From: Martin Renvoize martin.renvo...@ptfs-europe.com
To: Mark Tompsett mtomp...@hotmail.com 
Cc: Koha Devel koha-devel@lists.koha-community.org 
Sent: Monday, February 10, 2014 3:12 AM
Subject: Re: [Koha-devel] Wiki page update question
 


I do it for you, but I tend to think leading least on is better than just 
going ahead and fixing things.
The item your looking at is being included on the page as a template. ( in 
fact any inclusion that can be seen as {{pagename}} in the source of a page is 
known as a template in mediawiki.  You can find such pages by limiting a 
search to the template namespace.  So, your page is at 
http://wiki.koha-community.org/wiki/Template:DevBook and it explains how to 
modify it there.
If we were more clever we could use semantics to auto include a page in the 
devbook depending on its contents using dB like queries.
As a side note, you are not limited to only including templates on pages, you 
can in fact include any page on another page using {{namespace:page name}}.
Hope that helps.
On 10 Feb 2014 06:55, Mark Tompsett mtomp...@hotmail.com wrote:

Greetings,
 
http://wiki.koha-community.org/wiki/Developer_handbook
Handy little page, but as I have noted on the discussion, the QA Testing 
Tools are missing from the list.
 
Who? Where? How? Et cetera, et cetera – do I get the QA Testing Tools onto 
the page?
That little macro-y {DevBook} is too magical for a wiki newbie like 
myself.
 
GPML,
Mark Tompsett
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/


___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] ElasticSearch for Koha - presenting the Koha Gruppo Italiano's project

[BWS Johnson]

Salvete!

    In general for your efforts: bravissimi! :D I feel that it's much needed.


 We are very interested to hearing your first impressions, your suggestions 
 etc. 
 about this proposed project. Please respond to this e-mail if you have any 
 comments. Probably the best contributions during this early phase will be the 
 definition of the fundamentals. Example:
 
 - Which search engine? - ElasticSearch, Solr or other (even if, at this time, 
 the name of the initial project is ElasticSearch for Koha)?
 - Should the effort focus on complementing Zebra or on its replacement?
 - Subdivide the workload.
 - Draft a road map.
 

    A long time ago, when animals could talk, it was hoped that whatever steps 
were taken in search would do so agnostically so that one could select 
ElasticSearch, Solr, Zebra, or whatever else they so chose. This hope was 
coupled by the realisation that this approach would probably take longer and 
involve more resources than just settling on one search to end them all, BUT 
would be offset in guaranteeing user freedom.

    This is olde, but might be useful for Solr discussions:
http://wiki.koha-community.org/wiki/Switch_to_Solr_RFC#Concerns

    Realise that this improvement is in discussion, but quite high in 
difficulty in terms of help:
http://wiki.koha-community.org/wiki/I_want_to_help
 
    And tooting me own horn and Jared's:
http://wiki.koha-community.org/wiki/C_%26_P_Search_Rewrite_RFC

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] ping Koha (developers) community

[BWS Johnson]

Salvete!

 
  As for the SO bottleneck, I see know answer except for
 more encouragement
  for the end-users to test and sign-off, as well as
 absolutely clear,
  step-by-step test plans.
 
 
 Yep, that's all I can see too, maybe I could work on some
 openbadges
 stuff, you could win badges by signing off... or a
 certificate .. do
 you think that would help?
 

  Hooray badgers! :D Then we can let them overrun the Patrons in the far 
flung future, too. :) An even easier (read even *I* can manage this) way to do 
this is to shamelessly copy the Wikipedia Barnstar approach. Or we can merge 
the too. Whatevahs. :D

Cheers,
Brooke

 
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Summary of Open session at KohaCon13 - with a focus on Funding the Future of Koha.

[BWS Johnson]

Salvete!


I’d like to give a summary of a open discussion that
occurred at KohaCon14 in Reno.  A spot opened up from a presenter not 
being able to attend - so I volunteered to lead a discussion on Funding 
the future of Koha.   First we invited all current and past RM’s of Koha
up to the front of the room, to educate the audience on some of the 
“plumbing” needs in the code.  When I use the term “plumbing” - I really
mean portions of the code that need to be “rewritten”, “updated for 
current coding practices”, and a “plan for placing newer technologies 
and practices into the code”.  Mainly plumbing = what do we need to get 
completed in the near future and how are we going to get that done.

Many of these “needs” are larger projects that not a single 
organization or library can fund, as we would really need to dedicate an
expert programmer some uninterrupted time to accomplish these goals.  
Not one support vendor can brunt the front of the plumbing needs that 
need to happen.  We need to work together to fund this and we need to have a 
place and plan going forward now.  Let's do this for Koha!


    I can't stress this enough. Bust things into the smallest pieces possible 
and put a price on them with the understanding that the longer things are 
delayed, the more the price will rise. I think one of the biggest fears can be 
not knowing how much a rewrite will cost.

    I would further hope that vendors would factor some rewriting into the 
quotes they give their clients. I can't see this long term need simply 
disappearing. I would assume that it's as agitating to vendors as it would be 
to libraries to have nagging problems. I don't think anyone wants folks to 
bankrupt themselves short term or long term. So please consider everything in 
your aestimates. Perhaps a few tiers as in a consortium makes sense; the larger 
Libraries with means to do so can self identify and help financially, while the 
smaller ones can give in kind.

    I know I'm beating a dead horse here, but it is very important to remember 
the relationship between open source development and fun. I think it might be 
safe to say that rewriting is really not any one's idea of fun.
    



Points that were raised.

Many attendees felt that a clear 
plan on what path Koha should be developing towards would be a useful 
project.  Although setting a ridged path is a difficult thing with a 
community like ours, maybe a place for everyone to get or stash ideas 
for future paths would be a good thing to organize.




    It doesn't have to be rigid. When I was your age and Paul was release 
manager the first time, we had a really simply road map. Anyone could put 
anything on it, and there was a lot of satisfaction as folks signed their names 
to it and owned each feature or fix. We didn't get everything we wanted by any 
stretch, but it sure seemed like we got an awful lot.


    We have the wiki. I know not everyone likes it and it's disorganised, but I 
still feel like it's friendly enough that even I can do it. As long as folks 
have an account, they can muck about and make things as they see it. Someplace 
a long the line, and I tend to blame us Yanks, we lost the spirit of just DOING 
things, and we transitioned to talking about doing things instead.



An important comment here from the attendees was that when someone is 
funding a development - they should not just fund the code, but also 
plan for time and funding for the Sign-Off process and the QA process.



    This should be factored in to a vendor's quote. Sign offs are usually not 
fun, but bugfixing days, chorewars, and scoreboards changed this a little! :D 
(One of many great ideas. :D)

    I stand by my previous assertion that mechanical turking out sign offsand 
sandboxing could be a good thing. We could at least try it for very low cost, 
but it would require pretty bad arse sandboxing. I'm also olde enough to 
remember a time pre sandbox. :D So yes, we are definitely making forward 
progress even if it doesn't seem like it to those in the thick of the fight!   


Funding and how would we organize this?  Since many in the audience were
from the USA - there was discussion of getting a users group going 
again OR creating some sort of “non-profit like org” where libraries 
could pool funding towards projects.  An organization like this would be
able to apply for grants etc.  Something where we could crowd-source 
funding and then fund a developer for a number of hours towards a 
project.


    Users' groups pre date things like Kickstarter. Individual Libraries are 
still free to explore grants without building a whole new umbrella 
organisation. That said, a proper non profit foundation is still highly 
attractive to me despite the endless hoops and pitfalls. I feel like it would 
be a safe place for IP, a good bank for good purposes that Libraries couldn't 
support - like travel to Conference for folks outside their walls. (Thankfully 
this is starting to happen 

Re: [Koha-devel] Kohacon13 hackfest: presenting deployement project management

[BWS Johnson]

Salvete!


 Paul Poulain schrieb am 03.09.2013
  Hi all,
 
  There's something I think should we worth sharing: how does support
  companies manage Koha project  Koha deployement (who do what, when,
  which usual timing, ...)
 
 I'd love to hear more about that topic. Unfortunately I can't come
 to Reno, it would be lovely if you could document a little. :)


    I can try to if someone can lend me a lappy. If not, you'll have to wait 
for ye olde paper and pencil notes. PMPing ain't easy.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] RFC: Plugins QA

[BWS Johnson]

Salvete!


Tarballs, packages, gits (including vendors), stables, latest, bugs and
patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat,
maybe more, and now plug-ins?  Could we please look at what the
open source world is doing? Apache, SendMail, Perl, PostFix,
FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable
with an established security update capability. Even Java and MySQL are
simplifying.


    I'm all for giving our developers the flexibility to deliver their code in 
whatever form they have time to wrap it in. I might _like_ them to do things my 
way, but I'm not paying them, and I never have.

    What do you consider instable or insecure in particular?

    Many of those projects are quite large, so in my light, afford their 
respective projects the ability to do things that we as a smaller project might 
not be able to manage.


    Many thanks to Robin and anyone else that helped with the packages. I had 
whinged for ages that I'd love to just have an apt-get command.   
    


I had a rather important librarian from Quebec drop in, out
of the blue, yesterday to talk about Koha. Her group (37 libraries) had
previously been burned by a trial commercial implementation of Koha (no
need to quote names), so they're using Opals, but liked the
idea of Koha. First question: stability?


    I am stymied by this. Completely, utterly flabbergasted. First, whatever 
trash LibLime were selling wasn't Koha. Second, OPALS?  As in

http://www.mediaflex.net/showcase.jsp?record_id=52

    One of the questions I posed to my students was Is OPALS truly open source 
if you have to beg for the code and a demo? In terms of feature comparison and 
breadth of adoption, it's not even close. It's well known I've a soft spot in 
the granite thing that's meant to be my heart when it comes to Koha, but I 
freely admit when I think we get beat. That is most certainly not the case with 
Koha, and I wish them the best of luck getting a consortium up and running in a 
multilingual capacity with that heap.
    



I know that a number of you will ... whatever ... Paul's a pain in the
neck, doesn't understand, does his own thing, but the bottom line is that
http://opac.navalmarinearchive.com/
is fully functional and is intrinsically Koha. It's (reasonably) secure
(without https) and meets the needs of our users and librarians. It runs
itself with minimal (  1 hour/week statistically ) intervention by IT
personnel. 


    So what's the problem? I'm truly sorry, but I just don't understand why 
you're ranting here.



There are very few institutions that have happiness in the
form of unlimited budgets and unlimited IT departments. I'm personally
intrigued by the creativity of the Koha community, so try and follow
what's happening -- which is magnificent -- but doubt that your average
library has the same passion.



    I think most of the discussions we have are important, and I really love 
having the longer term steering and strategic types of conversations. It's been 
a long time since I had to interact with proprietary vendors, and I don't 
relish the thought of ever being charged with that again. I think that a lot of 
the development done at least gives a nod to small libraries. More often than 
no, folks bend over backwards for small libraries. I get quite prickly if I 
sense that things *aren't* moving that way. This is a big tent system, there's 
plenty of room for everyone's individual take. :)


Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Koha 3.12 Live DVD released

[BWS Johnson]

Salvete!


 You can download the Live DVD from here,
 https://sourceforge.net/projects/kohalivedvd/files
 

    Well that was quick! Thank you. :)

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Koha 3.12.0 is released

[BWS Johnson]

Salvete!

    Wow what a very long list. :D Thanks to everyone for their hard work!

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Koha numbering

[BWS Johnson]

Salvete!

 You silly, silly man. Everyone knows that anything past nine isn#x27;t 
real maths. ;)

xkcd.com#x2F;899#x2F;

 I still mostly don#x27;t care how things are numbered. I care far more 
that thongs operate how they ought to.

Cheers,
Brooke___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Opinions needed on bug 9322

[BWS Johnson]

Salvete!

    OhEmGee, Galen's ears must have been burning. 


I could see wanting to have an item

 auto-transfer to C after a period of time, a la rotating collections.
    

    I agree and I'll think on the other one some more. I would say that 
rotating collections are common.
    

 Perhaps our modeling needs to distinguish between transfers and
 transfer requests.  The former would be the record that an item is


    Yes definitely. I found as I was describing and asking things of Liz that 
there were two entangled articulations. I'd rather have 2 related but hopefully 
not inextricable articulations.


 either in transit (i.e., branchtransfers where datearrived is null) or
 that it was successfully transferred in the past (datearrived is not
 null), while the later would be a request saying that at some
 specified future time the item *should* transit, either
 unconditionally or when it's not needed to fill a hold request.

    *nod* This also would beg the contruction of olde data for those things, 
too. One could be olde transfers and the other olde reserves. I would 
anticipate the latter being more useful than the former. (I don't want to 
sound stupid, but I forgot to pickup a reserve that I placed on a book I forgot 
the title of...)


  A librarian might also legitimately want to have a transfer and a
  reserve going at the same time and choose between them at check-in time.
 

    Mmm, bet hedging, classic.


 I think this should be unpacked as well ... when would one prefer to
 transit the item rather than fill a hold request?

    In the case of an 
item that has been damaged and needs return to processing. (You don't 
like transmission fluid leaking from your Chilton's?)
    In the case that the delivery driver is at the door right NAO and that hold 
could theoretically come back to you quite quickly v. sitting on your holds 
shelf mouldering away for quite a while.   

    These are related to requests, obviously. I realise a lot of this can be 
done with overrides. I 3 overrides for situational stuff. Being a slave to the 
LMS is no fun. Some of this stuff can be managed with clever Patron categories 
and is on the Librarian rather than the database designer.

    In the case of a delinquent Patron, I'd rather forward the item on to 
someone that is more likely to return it than give it to someone proven to be a 
bit dodgy.
    In the case of a Patron what takes overly long to read in favour of one 
that I know takes a day or two to worm on through. (The former is me. Don't 
look at my reading records, they are not pretty on the renewal front.)
    In the case of at Patron who has a time sensitive request. (Dude, my kid 
needs this book for his school project what was due YESTERDAY. Doctor so and so 
needs this book for surgery NAO.) These are related to requests, obviously.
    In the case that the item has essentially been on world tour and really, 
the collection development people are getting torqued that their book isn't on 
*their* shelf. (This should be accomplished through itemtypes, but hey, 
sometimes folks are nice and it's not.)

    I also think this is useful to think about in the reverse. When would I 
want to prefer that an item stay put rather than fill a transfer?

    In the case of a Very Important Patron. (You tell that Major Sponsor they 
ain't getting Consent of the Networked right now or Jo that she's not getting 
Fifty Shades of Grey. Not me, I'm a coward!)
    In the case where geography makes it silly and a book would ping pong 
unnecessarily if behaving how it ought to under the transfer or reserves queue 
alone. (This happens with ILL proper way more than local transfers, but 
seriously, why would I send summat way far out only to come back again when I 
can just kill all non local holds in one fell swoop?{Clearly care needs to be 
taken in logic to avoid making someone wait for bloody ever for their stuff, 
but suppose someone is #5 on the list and you're working on #3. Skip #4 for now 
because it's a victimless crime like punching someone in the dark.})
    In the case of a book club, town read, or other event that is time 
sensitive. (As in hey, I happen to need 10 copies of this, but just for tonight 
or 1 week from now, or whatever. [Yes you ought to have placed a group hold, 
but hey, let's not talk about who smells like what for not doing so.])
 

    Hope some of this made sense.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Authority Marc Structure Import/Export Function

[BWS Johnson]

Salvete!

What do folks think about adding an import/export function for the authorities 
marc structure frameworks? 


    I think if ye manage and nengard likes it, I'll buy ye a beeyah.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] kc.org support companies page broken...

[BWS Johnson]

Salvete!


 http://koha-community.org/support/paid-support/country/#ind
 

    Works for me using Firefox on my Mac both from the direct link Liz provided 
and from the navigation links on the site.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

[Koha-devel] Merci Frédéric! Re: It's string freeze time again

[BWS Johnson]

Salvete!

 I'd like to take this opportunity to thank Frederic for all his hard
 work as translation manager, he has done a fantastic job.

    And I would add for a LONG time! Merci beaucoup!

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Default search options in the OPAC

[BWS Johnson]

Salvete!


 I am not feeling comfortable with adding more search options to the masthead 
 search bar too. As you wrote it should be simple to use and we already offer 
 a 
 lot of options there.
 
 One of the bugs noted that the full functionality can not be achieved by 
 using 
 jQuery, so maybe we can find another compromise.
 
 Perhaps this needs to be made configurable sometime in the future. Could we 
 make 
 it easy to use CSS to hide or even 'unhide' some of the options?


    This sounds like an idea for an interface and usability panel or committee. 
Would it be a helpful starting point if I screenshot what folks are talking 
about and then rearrange it how it would look in my world? I think some of the 
struggle we face in preferences now is from there still being a One Koha To 
Bind Them All in the stead of modules that are specific to different Library 
types. Yes, I do realise that I don't have any money for building modules, but 
it won't stop me from thinking that different preset out of the box skins and 
preference set ups would save a lot of user and vendor time in the long run.

    I appreciate you all for at least talking about it. It's part of what makes 
us different from ye olde proprietary vendors. :)

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Default search options in the OPAC

[BWS Johnson]

Salvete!

  Would it be a helpful starting point if I screenshot what folks are talking 
 about
  and then rearrange it how it would look in my world?
 
 What do you mean by how it would look in my world?
 

I mean how I'd do it if I were empress of everything and could code. In 
reality, folks in community need to decide how they want stuff, but I'm 
wondering if seeing summat to vote on would be more helpful than talking about 
stuff that doesn't exist whatsoever yet. It's often helpful in planning to come 
with a plan then alter it to the needs of whoever you're planning for. However, 
I know a lot of process based stuff is unfun and unrewarding for developers so 
I'm trying to avoid following my consultant twitches. 

       So similar to how I did my presentation in India which was also based 
off of how I saw Cataloguing and blogged about it. :)

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Default search options in the OPAC

[BWS Johnson]

Salvete!

    My inclination is that I'm answering this too soon and that I've not 
thought enough about your questions in particular, but I've thought over 
structure in general and I want to honour an expedient timeframe for your 
question in especial.


 We could all chime in about which features we think are the most
 important, and we'd have as many different views. The questions I want
 to get at:
 

    Niyayo, but it is not unusual to see a pattern after preference voting. We 
all want the conference different places, but a vote settles where we hold 
Conference in a given year. I realise that features and Conferences are 
different birds. I am glad that you highlighted that which is important to you. 
That is why I suggested a committee or some sort of group work. We will all 
like different things. The power here is seeing a pattern.


 - Is it a (mostly-) common goal that the OPAC default search options
 be simple and few?
 

    There are two OPACs as things are currently. While our Patrons are not 
dumb, I feel that we did our best as a Community when we had a simple text 
search box as the first thing a user saw in our Catalogue for Patrons. I 
realise that this was quite a long while ago, but I still think that the search 
from 2.X - just the box first - was the best. To my perhaps faulty 
recollection, a user could toggle to advance search if they wanted interface 
clutter in their lives so that they could hone in on specifics. This is very 
similar to the evil Google, I realise.

    I think it is safe to assume that Librarians ought to be more proficient 
than most Patrons. (My weasel words are in there as an acknowledgement that 
sometimes this is not always the case. In the rare exceptions, it would not be 
out of the pail for a Librarian to grant a highly proficient Patron, such as a 
Bibliographer, Staff Access. But programme first for the rule then for the 
exception, yes?) So for the Staff search, I think the common goals can be 
arrived at in few and in order of frequency of encounter within one's daily 
routine. I would advise breaking skins or templates into Library types (small 
rural Public (or just Public to start), large private Academic, et cetera.) 

    So, in my world, one has a matrix of 

Library type: Academic, Public, School, Special

 and there's another toggle for size: 

Large, Medium, Small. 

    It's complex, but finite. Granular, but not overwhelming. At least to my 
pea sized brain. Your mileage may vary.


 - If not, should the solution be something more structured than
 javascript-based customizations?

    I think you have a very good handle for local customisations. I remember 
thinking Oh, if only I could change things just a touch so that I could add my 
Library's picture and name. You and others made this happen. :) That was more 
than I ever really thought I'd see since it was a good It would be nice if 
enhancement. I think some folks are always going to customise their OPAC, but I 
think there will be natural variance from site to site. Wordpressesque skins 
are a good way to address this added personal touch that perhaps not everyone 
would care for. We've had brilliant response to SQL reports in terms of 
contributions, and now I think we are building the same sort of base of jQuery 
stuff. Perhaps skins would be another bank of stuff that might build, or 
perhaps not given the way templates are. I don't know.

    In short, (too late, I know!) two dials are better than one here given that 
they're both logically constructed, which I think is best done with users 
working in concert with developers. Not that we don't already do that. 

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Lets improve the Koha installation documentation

[BWS Johnson]

Salvete!


   (...or just delete the old doco)++


    Don't pick this option. Warn instead. 
(http://en.wikipedia.org/wiki/Category:User_warning_templates) 

    As someone with deprecated documentation, on the few occasions when I 
return to clean things up, I count on my old doc being there as a starting 
point. Old documentation serves a historical purpose, too. I just read an 
academic article that cited work from 2003 for our project. Granted, that 
wasn't installation documentation, but it was good to see something from that 
long ago in the paper. It's useful to have archival versions of Koha and 
archival versions of the documentation so that folks can get a grasp of the 
progress that's been made. That said, there should definitely be warnings that 
folks are taking a trip down memory lane, and they should be redirected to the 
new versions.
    The most important reason to keep it round is that folks still use it, in 
especial people that are too hard pressed for cash to upgrade. Believe me, I 
die a little inside when someone contacts me at my school address, since I know 
that they're using one of the oldest forms of my Newbie Guide, but it happens 
with regularity. I of course redirect them to newer documentation. I'd like for 
people to install the newest shiniest version of Koha on the newest shiniest 
version of Debian, but unfortunately this just isn't the way a lot of people 
operate.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Lets improve the Koha installation documentation

[BWS Johnson]

Salvete!


 the big problem is... 
 there are too many 'Koha installation guides' on the kc.org wiki that 
 have old ,incorrect, redundant or duplicated info
 
    
    Alternatively, we could mark those entries up with wiki tags to reflect 
that there is old, incorrect, or redundant redundant redundant information. :) 
Then we can have some folks that aren't eyeball deep in code go and fix 'em.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] About Release process

[BWS Johnson]

Salvete!

    Perhaps no one will notice that I'm commenting from the wrong side of the 
marae. . .


    I know I tell this story all the bloody time, and I realise that this is 
the Developers' list so imagine me ducking rotten veg.

    I agree with Ian's observations. Also, he spelt favour correctly :)


  

  An Unacceptable Wait: A Cautionary Tale


    A long time ago, when animals could talk, I heard this tale from an older 
Librarian. This Librarian had a daughter. About the time that daughter was 
born, she asked her proprietary vendor to please code a bookmobile plug in. 
This was a keen Librarian. I would say that specifications were probably not an 
issue here. We Librarians are patient. Our fur is not so shiny as otter's. We 
are not so fast as horse. But we are patient.

    That said, every now and then, the Librarian would go back to the 
proprietary vendor and ask after this bookmobile plug in. Oh no, we aren't 
done yet, you will just have to wait.

    So the Librarian did. Every now and then, she'd politely (and after many, 
many moons perhaps not so politely) inquire with the great white proprietary 
father about her plug in. The answer was always the same. Perhaps she was not 
praying hard enough.

    After a very long wait indeed, she was finally told that it was ready. It 
of course didn't do what it was meant to actually do. But, it was ready.

    But Brooke what of her daughter? You might ask. When the plug in was 
released, her daughter was married to a handsome man from the next village over.

    So. THAT is an unacceptable wait in Libraryland.



    Surely there is summat between that and our release cycle that can be 
settled on. 


    At first, six months was a matter of pride. We had taken a very long time 
on a given release. Everyone got frustrated. This was bad. We all agreed. It 
was great to get back to six months just to show the world that we could. 


    I have been very nervous about the 6 month cycle, and I have said several 
times that it could easily be 9 months or even a year. I worry enormously about 
Developer burnout. I also will say that I worry a whole lot about Library 
funding to upgrade every bloody year if one skips a version. 


    Not too terribly long ago, it was mentioned that perhaps we should consider 
alternating feature releases and bug fixing releases. Perhaps function should 
dictate the schedule. You all might feel like there's this giant pressure on 
you to do things and do them RIGHT NOW but as long as you tell us when you 
first sit down with us how long you think it will take, and why it might be 
taking longer if it is taking longer, perhaps this pressure wouldn't be there.


    It is the old good, fast, or cheap you can have any two equation. I would 
pick good and cheap.


    Anyway, I will shut up now and stop invading your listserv.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] About IRC meeting voting

[BWS Johnson]

Salvete!


      That said, having LimeSurvey up and available to the community at large 
 would just be so fantastic.
 Nicole gave me a limeSurvey admin access. I'll use it when a discussion
 arise, and we will see if it fit our needs.
 If it does, we can open a survey.koha-community.org. But let's check if
 it fit our needs first.


    Forwarding this on to the general list, since to my recollection, the 
context of discussion was larger than what would apply on the developer's 
listserv. Again, my gut feeling is that it is quite useful to have an 
asynchronous tool, but it is also important to me to have meetings. I'm no fan 
of meetings as a concept, but for this body with everyone so far from one 
another, meetings help build community. I have the same rationale for KohaCon. 
Distance synchronous meetings are good, but buying someone a pint is even 
better :D

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Social library

[BWS Johnson]

Salve!


        Fisrt, thanks for sharing this: http://thesocialopac.net/. It's really 
nice way to find some help. I agree with you about the law's problem. We can 
solve it with some option for user to choose like sharing you action to your 
friends, not sharing And if u ask, where we can put this Wall on the Opac 
website, i think we can creat one more little menu like- My friend's action 
above the My summary on the menu.
        We can make a default like sharing your actions with your classmates 
(for shool's library or university's library). After friend's action, you can 
comment, like (it looks like in facebook). I think, the main idea is that, you 
can share your opinion about some books, recommend it to friends... We did 
have all databases, how can we make it comes true? I hope some programmer can 
do it and i think they really can.


    Well hmm. Now I'm just wondering if you're viewing an older version of 
Koha, perhaps... Have you seen:

http://catalog.losgatosca.gov/cgi-bin/koha/opac-detail.pl?biblionumber=117395

 Be sure and scroll down to the bottom of the page and click on all of the 
tabs and stuff. I'm not entirely sure that I'm fully understanding precisely 
what enhancements you want, but we might already be doing part of what you 
propose. :)

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Social library

[BWS Johnson]

Salvete!

    Two things. The first is that Paul is not only French, but also quite 
modest. So, he will probably not tell you that he was working on making Koha 
and SOPAC work together (at least a few years back.) This *might* satisfy your 
needs (or you might think it's lipstick on the pig.)

http://thesocialopac.net/

    The second thing. *begins the not a lawyer dance* I am not a lawyer, so 
this should not be considered legal advice, BUT, I should think that this could 
be worked around with a multi lock [as in canal] system should folks feel like 
working on it. The first lock would be ensuring that it was a system preference 
that a Library could toggle on or off. That should keep you out of sweeping 
legal trouble in the case that your country or locality forbids collection of 
data. The second lock of sorts would be that individual Patrons could choose to 
opt in should they feel like doing so. In theory, this might be layered. That 
way, I could share the information with my friends, but in the event that the 
Library as a whole had summat like a large screen at the Library, I might be 
able to opt out of just that feature.
 I would think that anonymised data in the US would be fine if kept as a 
general statistic anyway, specifically reader's advisory suggestions. (As in 
did you like X? then try Y.)

    Please keep the new ideas coming, that's how we get better :D


Cheers,
Brooke



- Original Message -
 From: Mirko 5...@gmx.de
 To: Koha-devel@lists.koha-community.org 
 Koha-devel@lists.koha-community.org
 Cc: 
 Sent: Friday, June 22, 2012 6:10 PM
 Subject: Re: [Koha-devel] Social library
 
 Hello!
 
 Just a little showstopper: at least where I live it is not allowed
 to gather and share this kind of information about patrons. We are
 not allowed to log the borrowing history of our patrons due to data
 protection laws.
 
 I don't mean to keep you from dreaming and sharing your ideas
 thought. Feel free to elaborate on this or other ideas you might have.
 
 - Mirko
 
 
 
 schrieb Uy am 22.06.2012 23:40:
  Hi everyone! I have worked with Koha for 4 month. I am not a
  programer, i just know php mysql and html. Love koha and i want
  to share some ideas with you guys. Hope that some developer get
  the same ideas and will make it come true. We know now facebook
  is really famous, and how do you think about the social library?
  I think, if we have a social library, the patrons will be
  interested more and more with our library. Let me give you
  example in my opinion: A patron join into OPAC site, and they
  will see that in 5 days from his last checkout, how many his
  friends came to library, what kinds of books they borrowed? It
  looks like a small wall on facebook. Now i can see that the OPAC
  when an user login in KOHA is quite sad, i mean there is a very
  little thing, which can make them stay on our library'site
  longer! I know that we are working with a library managment
  system, i can't dream more and more, but i think our student
  really love it. Thanks for reading, and i love to receive your
  reply.
 
  Kindest Regards! Nguyen Quoc Uy 
  ___ Koha-devel
  mailing list Koha-devel@lists.koha-community.org 
  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/
 
 ___
 Koha-devel mailing list
 Koha-devel@lists.koha-community.org
 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/
 
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] About IRC meeting voting

[BWS Johnson]

Salvete!

        I'm still mulling over the whole voting by proxy thing: I really don't 
like it, but I need to sort out and share precisely why. (Much of my 
reservations have to do with an erosion of Community and a ratcheting up of 
administrative duties.)

    That said, having LimeSurvey up and available to the community at large 
would just be so fantastic. I bugged Nicole to use hers to help me do a study 
months back and it was beautiful. It's so easy to use even I can do it, and 
it's quite powerful in terms of statistics. I love that it's FOSS to boot. It 
would be an incredible resource for Librarians.

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

[Koha-devel] To-morrow and to-morrow and to-morrow

[BWS Johnson]

Salvete!

    If you only make 2 IRC Meetings a year, tomorrow's is one to catch.

4 April at 10 UTC

    we're voting on roles for 3.10. There's still time to visit the wiki, step 
up, and volunteer in advance of the meeting. So have your +1s at the ready! 



See you soon,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Call for Nominations: Roles for 3.10

[BWS Johnson]

Tena Koutou!


 Just a bump... we still need a Translation Manager (someone with a
 non-English first language preferred), and specific module maintainers.
 More bug wranglers are always welcome, too!
 

    *cough* Marjiana or Dorbica *cough*


 He aha te mea nui o te ao?
 He tangata!
 He tangata!
 He tangata!


    Niyayo. :D

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] IRC meeting decision about discussion

[BWS Johnson]

Salvete!


  I think this is a valid point. The meeting agendas are posted well in
  advance, so it should be possible to arrange to be present for a vote.
 Well, with time shifting, don't expect ppl from the it's 2AM 
 timezone
 to be here, so I strongly think we should adress this issue.
 

    How? I don't think anyone expects people from the crummy timezone to be 
present. The best we can do is slate a time that works for a good chunk of the 
geographic world, as we do now. It's always going to be a reality of life for 
real time meetings when we have a global project that part of the project is 
disenfranchised part of the time. If we come together as we have and say that 
Okay, this is a large issue, let's invoke a special procedure that's fine. 
It's basically a motion to suspend the rules as far as I'm concerned. Those are 
in order some of the time in special cases. Making a special case a day to day 
reality is why I'm starting to dig in. I don't want to overpromise myself here.


  We've already demonstrated that for larger issues (like the Koha
  non-profit question) we can use alternate methods to vote. I say we
  should keep the smaller stuff (especially developer-centric stuff) to
  the IRC meetings.
 So maybe we should say:
 * discussion votes are made on the mailing list / on the wiki, and not
 on IRC if you think we should not have 2 places to vote ? Note that i've
 nothing against more than one method to vote. In France, if you're not
 present the day of the vote, you can do a vote par procuration 
 (proxy
 vote says gg translate). It would be the same kind of voting.
 

    All of this is a matter of frequency. Voting in France is not monthly on 
multiple small issues. Furthermore, there's infrastructure at work that I don't 
have at my disposal. I am not even an arrondisement, Paul. If we really want 
this, then we'd need a committee of volunteers that would show to count proxies 
_every_ month. That's a lot of man hours that I'd frankly prefer to dedicate 
elsewhere.

    If we decided on this for roles *maybe*. I'd be inclined to say certainly 
if we went to a 9 or 12 month release cycle. Conference to me works well: it's 
a once a year occurrence.  We're lucky to have Nicole helping there and 
tabulating things.

    Hashing things out on the mailing list first certainly works. I still like 
formalising it at the meeting so that there's a logical end to discussion. I 
don't think anyone wants to miss a discussion, which is why the one week window 
before the meeting for things labeled discussion works. I think it's going to 
be tricky to ensure that we don't fall back to things discussed over the list 
and MUNG in IRC. We'll see though.

 To answer Brooke concern:
 I also think the you must register on the wiki is not a big deal. If
 you want to be involved in Koha, registering on the wiki  bugzilla will
 be hard to avoid...


    It's not a big deal with plenty of lead time. If the wiki is down, then it 
becomes a big deal. Bugzilla is not particularly hard to avoid for non devs.

    We need a nice participation flow from listserv, IRC, wiki to harder things 
like sandboxing, bugzilla, and proper developing. 

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Update database changes proposal [IMPORTANT]

[BWS Johnson]

Kia ora!


 Maybe a middle solution would be to have do a check on the login page
 only (or on mainpage.pl ?). As it's mandatory to log-in on the staff
 interface, that seems fair.


    Any reason not to do it at logoff in the background?

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha

[BWS Johnson]

Salvete!


 2011/11/22 Lori Bowen Ayre lori.a...@galecia.com:
  The truth is that the law isn't really on the Koha community's side
  on this issue because of the sale of the domain to Liblime way back when.

    I think it's premature to say that. To my knowledge, this hasn't actually 
been navigated in court yet. Until our appeals are exhausted, I don't think we 
should give up. Doing so sends a message that it's okay for a large corporation 
to shove the public interest about. As far as what is in the name is concerned, 
it chafes me to see a native term, in especial that one, abused.

    We've already tried the way of the two row wampum. We've already said we'll 
be over here, you stay over there, and we'll mutually mind our own business. 
This has not stopped the personal attacks or the corporate ones. If it is a 
fight they want, then it is a fight they'll get.

 
 Putting aside the issue of whether we should fight this fight or not,
 the sale of the domain to Liblime has nothing to do with whether PTFS
 should own a trademark on the term Koha in New Zealand. Owning a
 domain name does not give you a trademark on that term.
 

    *nod* Even at the stage of owning a trademark, one must defend that 
trademark to retain it. I really do believe that the horse left the stall quite 
a while back. I'd love to see that tested in court.


 We were naive to let Liblime get a US trademark on Koha in the first
 place. We should not repeat that error.


    I agree, and certainly not in the birthplace of Koha. 

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Plea for help from Horowhenua Library Trust re: Koha

[BWS Johnson]

Salvete!

The situation we find ourselves in, is that after over a year of battling 
against it, PTFS/Liblime have managed to have their
application for a Trademark on Koha in New Zealand accepted. We now
have 3 months to object, but to do so involves lawyers and money. We
are a small semi rural Library in New Zealand and have no cash spare
in our operational budget to afford this, but we do feel it is
something we must fight.



    I concur. If one doesn't stand up to the schoolyard bully, they simply keep 
stealing lunch money. Having poor customer service and a vanishing clientele, 
PTFS are clearly at the stage where they needs resort to domain camping and now 
trademark on a generic term long utilised in the public interest. May Justice 
let whichever Court ultimately hears this do so with extreme skepticism.


For the library that invented Koha to now have to have a legal battle
to prevent a US company trademarking the word in NZ seems bizarre, but
it is at this point that we find ourselves.

So, we ask you, the users and developers of Koha, from the birth place of 
Koha, please if you can help in anyway, let us know.


    Let us know where the paypal page is set up for this. Hardly the sort of 
chicanery that needs happen during a building project.

Kia kaha,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Fwd: Interested to speak at KohaCon 2011

[BWS Johnson]

Kia ora!

    That's great news! Thanks for this, Paul, I'm sure that everyone will 
be excited to hear what our friends at Open Library have to say. :D

Cheers,
Brooke

___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Kohacon11 : Last date of paper submission extended till August 30 2011

[BWS Johnson]

Kia ora!

This means we have to drop the Advertisements in the 
conferenceproceedings publication type of sponsorship. The largest 
sponsor we have Bharat Grahak had opted for back page of the same and I would 
hate to lose that sponsorship.  I hope the other sponsors who had opted for 
advertisements will be ok with some of the other at the venue options 
presented here http://www.vpmthane.org/payments/kohacon11/insert_cc.asp ?



Not necessarily. Check and see if the compromise of having a collection of 
abstracts with advertising would be amenable to them. My gut tells me there 
would be very little difference to an average person in having their advert 
with an abstract v. a full paper.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] Global bug squashing day #2 - 1 short summary and 2 questions

[BWS Johnson]

Kia ora!

 Now that actually looks less impressive than it is. A lot of bugs were



I disagree! Those are great numbers :D Thanks for another job well done.


 And as Paul has already said somewhere else, a lot of work was also
 put into organizing RFCs on the wiki:
 http://wiki.koha-community.org/wiki/Category:RFC_Status
 


Wiki categorisation ftw :D


 All in all, a productive day for Koha, I think!
 
 A couple of questions:
 
 * BibLibre are having community days every other Friday (as far as I
 have heard). Should there be GBSDs to coincide with every one of
 these, or is every other enough (= GBSD every 4 weeks)?
 (I think for me personally dedicating 1 day every 4 weeks to this
 stuff is probably the best I can do at the moment, but others might
 see it differently.)
 
 * Is Friday the best day for GBSDs?
 (I know I personally want to make pizza and be around the wife and the
 dogs when Friday afternoon comes around, whereas on another weekday it
 might be easier to get some work done after dinner. Whaddaya think?)



Just keep in mind that our Friday is Kiwi Saturday.

http://cep.lse.ac.uk/pubs/download/mhrldp0004.pdf


Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/

Re: [Koha-devel] [Koha] Summary of Global Signoff Day 2011-06-15 - more to come?

[BWS Johnson]

Kia ora!

 -- Better/other lists and visualisations?


A notch in the belt visualisation. You know you wanna.

 -- Could we use some kind of VoIP/videoconferencing tools to make the
 social interactions seem more um... real?
 


Mumble, it's like Ventrilo, but bettah.

http://sourceforge.net/projects/mumble/

The question would be would this leave a few folks out in the cold if they've a 
crap connection.

Cheers,
Brooke
___
Koha-devel mailing list
Koha-devel@lists.koha-community.org
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/