[Koha] [Fwd: Re: Koha Foundation Vote is open]
Please, whenever we next have a community poll, we should go back to using FOSS software, such as LimeSurvey which we have used in the past. Using non-FOSS software, such as JotForm if I understand correctly, where the source code is not even available for audit is particularly problematic for community surveys. Some language furthering Koha as FOSS and the Koha community in a FOSS environment wherever practical should be in the organisational purpose of any Koha community foundation incorporation papers. FOSS should be the primary reason people choose Koha and we should avoid diluting that message wherever practical. [Previous reply with a minor word order correction is quoted below.] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 Original Message Subject: Re: [Koha] Koha Foundation Vote is open From:"Thomas Dukleth" Date:Thu, May 16, 2024 02:20 -- [Reply inline with a word order correction.] On Wed, May 15, 2024 21:47, Auld, Andrew wrote: > The Koha Foundation proposal vote is now open. You can place your vote on > the Koha Community website and there you will also find a link to the > proposal and background research. Votes must be placed by 5pm UTC on > Friday > 14 June. One vote per person please. If I remember correctly, previous survey software used for voting on Koha community concerns certainly had the principle of one vote per person but allowed vote reconsideration and changing the one counted voted by voting again with a different vote. > https://koha-community.org/koha-foundation-vote/ In https://ptfs-europe.com/koha-foundation-proposal/ , very little is stated about the intended governance structure of a foundation other than the legally required five member board of directors and two volunteers, and the unstated presumptive necessity that it has to avoid legal conflicts of interest to comply with Open Library Foundation and US non-profit 501c3 rules. For example, there is no statement considering a concern of historic discussions of a possible Koha foundation to geographically federate some input into foundation governance for such an internationally distributed project as Koha to avoid the foundation excessively serving US or Anglo-US interests based on the US location of the foundation other than "in the first instance, to keep the governance light". There is also no historical background explaining that the project had previously organised under Horowhenua Library Trust [HLT], subsequently THT. Upon the dissolution of THT for Horowhenua District Council [HDC] to directly run Horowhenua libraries directly, Koha community assets might have devolved to HDC which had created HLT and then THT as an administrative organisation for local libraries. I do not remember what happened if anything decisive subsequent to "THT and Koha: a new Trust Deed" - https://lists.katipo.co.nz/public/koha/2016-October/046346.html and https://wiki.koha-community.org/wiki/THT_and_Koha . The complication at the time was that there was no representative Koha community organisation to which THT or HDC could transfer Koha community assets other than THT which was being dissolved. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Koha Foundation Vote is open
[Reply inline] On Wed, May 15, 2024 21:47, Auld, Andrew wrote: > The Koha Foundation proposal vote is now open. You can place your vote on > the Koha Community website and there you will also find a link to the > proposal and background research. Votes must be placed by 5pm UTC on > Friday > 14 June. One vote per person please. If I remember correctly, previous survey software used for voting on Koha community concerns certainly had the principle of one vote per person but allowed vote reconsideration and changing the one counted voted by voting again with a different vote. > https://koha-community.org/koha-foundation-vote/ In https://ptfs-europe.com/koha-foundation-proposal/ , very little is stated about the intended governance structure of a foundation other than the legally required five member board of directors and two volunteers, and the unstated presumptive necessity that it has to avoid legal conflicts of interest to comply with Open Library Foundation and US non-profit 501c3 rules. For example, there is no statement considering a concern of historic discussions of a possible Koha foundation to geographically federate some input into foundation governance for such an internationally distributed project as Koha to avoid the foundation excessively serving US or Anglo-US interests based on the US location of the foundation other than "in the first instance, to keep the governance light". There is also no historical background explaining that the project had previously organised under Horowhenua Library Trust [HLT], subsequently THT. Upon the dissolution of THT for HDC to directly run Horowhenua libraries directly, Koha community assets might have devolved to Horowhenua District Council [HDC] which had created HLT and then THT as an administrative organisation for local libraries. I do not remember what happened if anything decisive subsequent to "THT and Koha: a new Trust Deed" - https://lists.katipo.co.nz/public/koha/2016-October/046346.html and https://wiki.koha-community.org/wiki/THT_and_Koha . The complication at the time was that there was no representative Koha community organisation to which THT could transfer Koha community assets other than THT which was being dissolved. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Feb. 2024 possibility of Koha list delivery problems for Gmail, etc.
except for the general list. 4. Please be Nice to the People Who Gave Koha to the World. The Koha general mailing list is a special problem only because Katipo for which we are all grateful for giving Koha to the world no longer has the capacity to actively maintain the Koha general mailing list which has been fine as the existing configuration was good for a very long time and did not seriously require maintenance until recently. Even though DMARC support is a trivial matter of changing three lines and (maybe updating a DNS serial number for 4 lines), it has not happened for Katipo in the past few months since I have raised the issue. It may be possible that people assisting Rachel Hamilton-Williams are not certain where DNS is configured for lists.katipo.co.nz to update that record for DMARC support. DNS configuration could be at the domain registrar, some intermediate service, some VPS hosting provider, or on the very system which runs the katipo.co.nz server or lists.katipo.co.nz server. If using BIND for DNS line to add would be: _dmarc.lists.katipo.co.nz. IN TXT "v=DMARC1; p=none" or the equivalent in some other system where the leading underscore is needed and the policy is "p=none" matches the DNS configuration for the the BibLibre managed Koha mailing lists such as the Koha-devel list. If using BIND, the zone file where lists.katipo.co.nz is configured would need a serial number update. The BIND9 daemon would also restart. Maybe a change was made without a serial number update or daemon restart. There are two equally trivial Mailman configuration changes also needed but a DNS update for DMARC comes first. I have sent messages but response discussion was only about having another party take over running the mailing list for more active maintenance which would necessarily take time and the Koha community is pursuing a new system which takes time. 5. New System Fixes Everything Except New Problems. Please be patient. People are working on setting up, configuring, testing etc. a new system which can give people email for doing everything and a message forum for people who prefer forums instead of email which is important because mailing list engagement is declining everywhere. People need time from the other more pressing tasks of every day to work on all that is necessary for a fully working system. I have weeks of research into various issues for configuration, bugs, some tests etc. If we rush things we may have much unhappiness with any of a variety of common problems: from email not working properly;posts mangled; message lists jumbled where distinctive content is difficult to find; database backups silently corrupted and not restoring after a software update; contented list readers having their accounts deleted after a time; etc. People need to take time to do things reasonably well so that unpleasant surprises are minimised. I expect that it may take several weeks to a few months for a new system to be well setup, configured, tested, reconfigured, and retested before we should have confidence in a new system informed by the problems which other people had before us. Meanwhile, fixing DMARC on Mailman 2.1 which we are running is trivial by comparison. 6. Reference. See the message I posted on the Koha-devel mailing list about prospective delivery problems especially the prospect for the Koha general mailing list, "[Koha-devel] Feb. 2024 prospects of Koha lists delivery problems for Gmail, etc." - https://lists.koha-community.org/pipermail/koha-devel/2023-November/048441.html . [I resolved the ARC permissions problem mentioned in the message by having the startup script change the permissions but with DMARC Gmail has been satisfied in my testing even when DKIM and ARC are not present.] Please report verified mailing list receipt problems in "Bug 34927 - Adding DMARC compatibility to mailing lists" - https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34927 . [Once someone has reported that mailing list X messages are not being accepted by subscribers using big service Y , not even in the spam box, we do not need the same information again. Not every user of some big mail service may have the same experience because such large services do not tend to implement changes worldwide all at the same time.] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
[Reply inline.] On Fri, March 10, 2023 14:24, David Liddle wrote: [...] > > 1. Can you clarify in which sense you mean "offline use"? Some people > describe themselves as offline when they don't have a web browser open > but are still very much connected to the internet. For others, it just > means that they're not logged in to the specific site or service in > question. Then there are the people who are fully offline, making only > occasional connections to the internet to collect mail by POP. I had meant some form of only occasional connections to the internet. The vast majority of mailing list subscribers may have high availability relatively low cost internet connections. However, we should not exclude the less fortunate where Koha may still serve people well. Some less developed places have institutional islands where Koha would be suitable to an institution which is an island with some connectivity in the midst of an internet connectivity desert where internet connectivity has limited availability and high metered expense. Institutional intranet can serve Koha while internet access is not used much. In such circumstances, people read messages anytime which had been collected via POP or offline IMAP when briefly online and queue messages which they have composed for when they are briefly online again. The use case is also the same for people who live just outside some internet coverage area but work where internet is more readily available. I have read that some people have configured Discourse so that they can interact entirely from email and never have to interact directly with the Discourse server. However, Hyperkitty for Mailman 3 may serve users better. [...] > Again, a platform change is just something to consider. If there's no > critical mass of people reporting that the communications platforms > are insufficient or unsatisfying, then it's not worth discussing or > pursuing. I just know for a fact that messages are not getting > delivered to some subscribers because of address spoofing. The list > will have to deal with that sooner or later, in one fashion or > another. A Discourse forum has been raised previously as a way to raise engagement for users who do not currently engage on the mailing list. A major issue is how much extra work maintaining a forum would be. Are the anti-spam tools or message review tools as helpful as what we currently have for the mailing list? There have been many subscribers to the mailing list from people whose systems are infected by a variety of spambots. If people want a forum which also severs as a mailing list, Hyperkitty in Mailman 3 provides date based access to archives as opposed to sequence based access to archives. For Discourse servers which I tested, I did not find any evident means to access archives by some date based period of time nor any evident effective means to include date in a search query. Maybe there is some way of configuring date based access to messages which I did not see. Both Discourse and Hyperkitty use continuous scrolling for the next page of content which generally breaks returning to access a particular place in a list of messages without accessing a particular message. Date based access provides some mitigation for Hyperkitty and both Discourse and Hyperkitty provide proper paginated access for indexing robots run by Google, Bing, etc. or otherwise perhaps JavaScript disabled on the client side. Mailman 3 still does not have feature parity with Mailman 2 but maybe we are not using or do not need Mailman 2 features which are not currently present in Mailman 3. The easiest thing to do for the moment is to Mung the from header in Mailman 2 to support DMARC. I have not found notice of any software project mailing list adopting the MIME wrapping approach to DMARC which has too much of an adverse risk of having messages appear as attachments instead of the body for some users. MIME wrapping is probably better suited as a DMARC approach when all subscribers work for the same company using only company supplied email software to read the company mailing list. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
[Resending to correct accidental paste in my message but adding consideration of use of Discourse as a partial workaround.] I added to the meeting agenda some brief consideration of implementation if we adopt DMARC for the Koha mailing list. These issues have had some discussion on the Koha mailing list. There is no problem free way to implement DMARC for mailing lists in part because email and mailing lists were designed before authentication of senders was considered a sufficiently concerning problem. 1. Mailman. Two implementation approaches to consider are the following. Quotations below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC but there are matching parts in the Mailman 2 section. One option: "Munge the From: header - The obvious way to avoid a DMARC rejection [...]" Alternative option: "Wrap the message - This involves MIME wrapping the original message [...] Users of MUAs that can't unwrap this MIME decoration would suffer." The suffering would be some users of the very wide variety of email clients people use from console, to desktop, to some old mobile device may not see any body message and merely have an attachment requiring extra processing outside of the user's email program. See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner - https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on the complexities of mime use in messages and how every email client has an individual implementation to cope. Limiting scope to affected users. It is reportedly possible to configure Mailman to limit the scope of DMARC mitigations to affected users such that the mailing list messages are unaltered for others, "Enable dmarc mitigations" - https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/6MOITVJK4WFXALD6NKR6SJTEN7RMLZLK/ . My current understanding leads me to prefer "munging the from header" as an implementation despite some RFC non-compliance. As stated above; email, mailing lists, and their associated RFCs long preceded considerations of authentication. Having problematic email clients for "MIME wrapping" in the wild seems to me to be a worse problem than some otherwise unavoidable RFC non-compliance with the very diverse subscriber base for the mailing list. Diverse subscribers have diverse computer systems and frequently restrictions on changing them where they actually read and reply to email on work systems and other systems as opposed to some major proprietary webmail intermediaries through which email may pass for many people. 2. Discourse. Does Discourse mailing list mode avoid problems with DMARC in a manner that is still sensible for offline use? Mailing lists are good for offline use. Does discourse provide something similar to Mailman "munging the from header" so that the message poster is identified in the email from header originating from the Discourse server allowing email clients to display lists of messages helpfully including by message poster in addition to subject and time? Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, March 3, 2023 17:43, David Liddle wrote: > Thank you for adding it to the discussion points! > > > On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer > wrote: > >> I have added the DMARC issue to the agenda for the next developer IRC >> meeting, but we might need the people running our mailservers to weigh >> in: >> >> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023 >> >> Hope this helps, >> >> Katrin >> >> On 27.02.23 15:49, Coehoorn, Joel wrote: >> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only >> for >> the >> > last couple of months. The list used to handle this correctly. >> > >> > *Joel Coehoorn* >> > Director of Information Technology >> > *York University* >> > Office: 402-363-5603 | jcoeho...@york.edu | york.edu >> > >> > >> > >> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle >> wrote: >> > >> >> Greetings, all! >> >> >> >> At the encouragement of one of the mailing list administrators, I >> >> would like to present a situation and a proposal to you all. >> >> >> >> Normally, I would write from my work account, >> david.lid...@wycliff.de, >> >> since one of the hats I wear is that of a Koha system administrator. >> >> One of my other hats, however, is that of the email administrator for >> >> our corporate domains. And the latter hat has precedence over the >> >> former. >> >> >> >> To help protect our
Re: [Koha] Can the Koha Mailing List and DMARC become friends?
I added to the meeting agenda some brief consideration of implementation if we adopt DMARC for the Koha mailing list. These issues have had some discussion on the Koha mailing list. There is no problem free way to implement DMARC for mailing lists in part because email and mailing lists were designed before authentication of senders was considered a sufficiently concerning problem. Two implementation approaches to consider are the following. Quotations below are from the Mailman 3 section in https://wiki.list.org/DEV/DMARC but there are matching parts in the Mailman 2 section. One option: "Munge the From: header - The obvious way to avoid a DMARC rejection [...]" Alternative option: "Wrap the message - This involves MIME wrapping the original message [...] Users of MUAs that can't unwrap this MIME decoration would suffer." The suffering would be some users of the very wide variety of email clients people use from console, to desktop, to some old mobile device may not see any body message and merely have an attachment requiring extra processing outside of the user's email program. See "If MIMEs could talk: Email structures in the wild" / Bo Waggoner - https://bowaggoner.com/bomail/writeups/mimes.html for some perspective on the complexities of mime use in messages and how every email client has an individual implementation to cope. My current understanding leads me to prefer "munging the from header" as an implementation despite some RFC non-compliance. As stated above; email, mailing lists, and their associated RFCs long preceded considerations of authentication. Having problematic email clients for "https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023MIME wrapping" in the wild seems to me to be a worse problem than some otherwise unavoidable RFC non-compliance with the very diverse subscriber base for the mailing list. Diverse subscribers have diverse computer systems and frequently restrictions on changing them where they actually read and reply to email on work systems and other systems as opposed to some major proprietary webmail intermediaries through which email may pass for many people. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Fri, March 3, 2023 17:43, David Liddle wrote: > Thank you for adding it to the discussion points! > > > On Fri, Mar 3, 2023 at 6:08 PM Katrin Fischer > wrote: > >> I have added the DMARC issue to the agenda for the next developer IRC >> meeting, but we might need the people running our mailservers to weigh >> in: >> >> https://wiki.koha-community.org/wiki/Development_IRC_meeting_9_March_2023 >> >> Hope this helps, >> >> Katrin >> >> On 27.02.23 15:49, Coehoorn, Joel wrote: >> > FWIW, I'm seeing the same thing for our "york.edu" domain, but only >> for >> the >> > last couple of months. The list used to handle this correctly. >> > >> > *Joel Coehoorn* >> > Director of Information Technology >> > *York University* >> > Office: 402-363-5603 | jcoeho...@york.edu | york.edu >> > >> > >> > >> > On Mon, Feb 27, 2023 at 8:00 AM David Liddle >> wrote: >> > >> >> Greetings, all! >> >> >> >> At the encouragement of one of the mailing list administrators, I >> >> would like to present a situation and a proposal to you all. >> >> >> >> Normally, I would write from my work account, >> david.lid...@wycliff.de, >> >> since one of the hats I wear is that of a Koha system administrator. >> >> One of my other hats, however, is that of the email administrator for >> >> our corporate domains. And the latter hat has precedence over the >> >> former. >> >> >> >> To help protect our email domains from being used fraudulently, I >> have >> >> implemented DMARC policies according to current recommendations. You >> >> can read more about the Domain-based Message Authentication, >> Reporting >> >> & Conformance protocol at https://dmarc.org/. The policies direct >> that >> >> only messages from authorized sources should be allowed to send mail >> >> from wycliff.de and our other domains; messages from all unauthorized >> >> sources should be quarantined. >> >> >> >> With DMARC policies in place, messages that I send from my work >> >> account to the Koha mailing list get quarantined by email providers >> >> that comply with the policies' directives. Why? It happens because >> the >> >> Koha mailing list spoofs the email address
Re: [Koha] Koha Wiki migrated and upgraded
er weight and appear further down the result set or pages with a single category such as [[Category:Circulation]] alone or some particular additional categories such as [[Category:Documentation]] have higher weight and appear further up the result set. VECTORMOD SKIN. Users are free to choose their own preferred MediaWiki skin and we can add others. VectorMod is merely set as the default to help people avoid obsolete pages when submitting search queries from the simple search box which appears on every page. VectorMod is a custom version of the Vector skin which includes a modified version of Vector/includes/templates/SearchBox.mustache supporting dynamic archiving of obsolete content by excluding pages which have been designated obsolete by automatically adding -inCategory:"Obsolete" to basic search querries. The syntax incategory requires using ElasticSearch. Previously, I replaced the SearchBox.mustache file in the Vector skin directly, which certainly worked without the extra effort of creating a custom skin. Automatically inserting -inCategory:"Obsolete" in the basic search box is now somewhat elegant in conjunction with the modified AvancedSearch extension as it uses explanatory language labels with a bubble which has a removal [x] and allows autocompletion of query terms. Significant renaming of references to Vector as VectorMod and vector as vectormod has been scripted allows both Vector and VectorMod to be loaded and available to users. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Please test Koha MediaWiki Canasta with Koha Portainer today
te pages are also noted with a prominent notice using the Obsolete template. Such pages should be updated if they can be, but are otherwise available to consult most importantly for valuable information they often contain which is not yet present in current pages. Archived obsolete pages can be found exclusively by following the navigation link "Advanced search obsolete archive" which includes incategory:"Obsolete" automatically. The result set for search queries with incategory:"Obsolete" can be used to identify the type of pages which should have the Obsolete category and Obsolete template but do not yet, such as installation information for some particular old Debian versions. Various combinations of including and excluding categories and templates can be easily used in the modified AdvancedSearch to find pages which only have one of either the Obsolete category or Obsolete template which should be used together or both removed if the page has been updated to be current. All wiki pages should have some category even if it may be [[Category:Empty]] for people uncertain of what may be appropriate in the moment. Pages missing categories may not be disappearing from query results by category when using ElasticSearch indexing as they had been when using database based search indexing. We can also query for pages missing categories using https://wiki.koha-community.org/w/index.php?title=Special:UncategorizedPages and correct the issue which has been neglected due to loss of time where migrating and upgrading the wiki has been the priority with much less time available otherwise especially since the pandemic. We should take some care when thinking about faceted category use as no wiki software uses fielded categories. Thus there may be no concise way to query for pages which address a topic in a general way or supplement other documentation on a topic containing a lone category such as [[Category:Circulation]], if we then have many other pages with [[Category:RFCs]] and [[Category:Circulation]] but no longer [[Category:Circulation RFCs]] as a possible change for faceting. In such an example, the search results of a query for incategory:"Circulation" might have a result set in which pages for RFCs relating to circulation issues containing both [[Category:RFCs]] and [[Category:Circulation]] might crowd out more generally helpful pages with [[Category:Circulation]] alone. The problem may indicate a need for a navigation link to exclude RFCs from a search query; designating old RFCs as obsolete; or both. Alternatively or additionally, we may be able to adjust the weighting of the ElasticSearch indexing options such that pages containing [[Category:RFCs]] have a lower weight and appear further down the result set or pages with a single category such as [[Category:Circulation]] alone or some particular additional categories such as [[Category:Documentation]] have higher weight and appear further up the result set. VECTORMOD SKIN. Users are free to choose their own preferred MediaWiki skin and we can add others. VectorMod is merely set as the default to help people avoid obsolete pages when submitting search queries from the simple search box which appears on every page. VectorMod is a custom version of the Vector skin which includes a modified version of Vector/includes/templates/SearchBox.mustache supporting dynamic archiving of obsolete content by excluding pages which have been designated obsolete by automatically adding -inCategory:"Obsolete" to basic search querries. The syntax incategory requires using ElasticSearch. Previously, I replaced the SearchBox.mustache file in the Vector skin directly, which certainly worked without the extra effort of creating a custom skin. Automatically inserting -inCategory:"Obsolete" in the basic search box is now somewhat elegant in conjunction with the modified AvancedSearch extension as it uses explanatory language labels with a bubble which has a removal [x] and allows autocompletion of query terms. Significant renaming of references to Vector as VectorMod and vector as vectormod has been scripted will allows both Vector and VectorMod to be loaded and available to users. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Add your KohaCon19 Hosting Proposal to wiki
Anyone who would like to host KohaCon19 (international Koha conference to be held in 2019) should add some brief information about their proposal to the proposals summary table in the page on the Koha Wiki which has been prepared following the model used for previous KohaCons, https://wiki.koha-community.org/wiki/KohaCon19_Proposals and for which there is already a proposal from Stockholm University Library. At the 6 June 2018 Koha General IRC meeting, people concluded that we should solicit bids June to 1 August 2018. Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon19. Do not be discouraged that some other proposal had been selected over yours in some previous year. [In the interest of promoting regional diversity in Koha, we have rules against selecting KohaCon proposals from the same contintent within three years in case the most populous regions might come to excessively dominate voting for selecting a proposal. The rule would be set aside for a particular year if no proposal from a different continent has been introduced. See https://wiki.koha-community.org/wiki/Processes_for_KohaCons .] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you want more information about MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Call for KohaCon18 hosting proposals
Anyone who would like to host KohaCon18 (international Koha conference to be held in 2018) should add some brief information about their proposal to the proposals summary table in the page on the Koha Wiki which I have prepared following the model used for previous KohaCons, http://wiki.koha-community.org/wiki/KohaCon18_Proposals . Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon18. Do not be discouraged that some other proposal had been selected over yours in some previous year. [In the interest of promoting regional diversity in Koha, we have rules against selecting KohaCon proposals from the same contintent within three years in case the most populous regions might come to excessively dominate voting for selecting a proposal. The rule would be set aside for a particular year if no proposal from a different continent has been introduced.] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you want more information about MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Call for KohaCon17 hosting proposals
Anyone who would like to host KohaCon17 (international Koha conference to be held in 2017) should add some brief information about their proposal to the proposals summary table in the page on the Koha Wiki which I have prepared following the model used for previous KohaCons, http://wiki.koha-community.org/wiki/KohaCon17_Proposals . Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon17. Do not be discouraged that some other proposal had been selected over yours in some previous year. People from the Philippenes had again submitted a KohaCon proposal before the general KohaCon17 page was created and I have now moved that merely tabular form content which had used the form of the general KohaCon proposals page to the newly created general KohaCon17 Proposals page. Such persistence of pursuing a KohaCon proposal should be encouraged. [In the interest of promoting regional diversity in Koha, we have sometimes considered rules against selecting KohaCon proposals from the same region successively in case the most populous regions might come to excessively dominate voting for selecting a proposal, but in practise such rules may not have yet been necessary.] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you want more information about MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Call for KohaCon16 hosting proposals
Anyone who would like to host KohaCon16 (international Koha conference to be held in 2016) should add some brief information about their proposal to the proposals summary table in the page on the Koha Wiki which I have prepared following the model used for previous KohaCons, http://wiki.koha-community.org/wiki/KohaCon16_Proposals . Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon16. Do not be discouraged that some other proposal had been selected over yours in some previous year. [In the interest of promoting regional diversity in Koha, we have sometimes considered rules against selecting KohaCon proposals from the same region successively in case the most populous regions might come to excessively dominate voting for selecting a proposal, but in practise such rules may not have yet been necessary. The more important issue for the case of KohaCon15, had been that only one candidate put forward a sufficiently complete proposal. We hope that people would have enough interest in hosting KohaCon that we would generally have multiple sufficiently complete proposals in any year to select from with a community vote.] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you want more information about MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] A Road Map for Koha
I created a proposal for progressively returning to filling the role of Wiki Curator, http://wiki.koha-community.org/wiki/Proposal_for_Wiki_Curator_3.20_Thomas_Dukleth . Please see the detail of that proposal for my suggestion of creating / updating a project roadmap in the wiki which I would not have time to work on until at least March myself. However, I encourage others to use the wiki for creating and updating a roadmap. The great advantage of the wiki is that by linking pages or linking to the documentation one could have a view of development at arbitrary depth. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] A Road Map for Koha
Everyone should be free to contribute, especially as it is a wiki. I added the names of both BWS Johnson to the Arsan Farooq as wiki curators in the plural for release 3.20, http://wiki.koha-community.org/wiki/Roles_for_3.20 . However, nothing should stop everyone else from also contributing. Certainly, the task of curating the wiki may be unmanageable without everyone who contributes to the wiki at least thinking about the task of curation while adding a contribution. I hope that we can coordinate efforts somewhat to the extent which may be helpful. Please see my proposal for my candidacy as one multiple wiki curators, http://wiki.koha-community.org/wiki/Proposal_for_Wiki_Curator_3.20_Thomas_Dukleth . Please give special attention to cautions about the risk of categories in templates breaking authority controlled consistency for navigation in conjunction with the SelectCategory extension. Please also avoid the surprise that upgrading MediaWiki without proper preparation may break many things including my own modifications to MediaWiki extensions as has happened in the past. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 On Wed, November 19, 2014 15:18, Arslan Farooq wrote: Hello Brooke!! Anyhow, if it's more than one person (and I hope that it is) I will certainly continue to help. :) Count me in as your assistant. I'd be honored to help with this under your guidance. Arslan [...] ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Re: [Koha] Code of conduct
to help the participant contact hotel/venue security, local law enforcement, or the home country law enforcement of any person against whom the complaint is made. Additionally, event staff will be happy to provide escorts, or otherwise assist those experiencing harassment to feel safe for the duration of the event. We value your attendance. 2.2.5. Procedures Event organisers will follow rules specified above to guide their procedure. Event organisers will keep a record of information from any participant making a harassment complaint noting the date, time, place, and who was involved with what specific activity. Event organisers will also similarly keep a record of information from witnesses. Event organisers will consider whether warning participants accused of violating the policy is appropriate or whether more serious action may be required. Event organisers will take guidance from event participants about what action may be appropriate but may act independently of that guidance except as stated above that the complainant's choice must be respected about whether contacting security or law enforcement is appropriate. 2.2.6. Attribution This ant-harassment policy is modified from the code borrowed from the folks at Evergreen who borrowed it from the folks at GopherCon, who borrowed it from JSConf, with permission. A section is adapted from the OpenStack Summit Code of Conduct. Another possibly earliest progenitor is the Ada Initiative's Model Conference Anti-Harassment Policy. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Deadline for KohaCon15 hosting proposals
Friday 15 August 2014, is the deadline for adding a proposal to the Koha wiki for hosting KohaCon15 (international Koha conference to be held in 2015). After 15 August 2014, we will be preparing to vote on any proposals which have been added. Anyone who would like to host KohaCon15 should add some brief information about their proposal to the proposals summary table in the page at http://wiki.koha-community.org/wiki/KohaCon15_Proposals . Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. There is currently only one proper proposal, which is for a venue in Ibidan, Nigeria. The information currently supplied for a venue to be held somewhere in Zambia has nothing more than a country name and a contact name which would not be enough to vote upon. If you are involved with the proposal in Zambia, please add sufficient information to be considered. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon15. Do not be discouraged that some other proposal had been selected over yours in some previous year. [In the interest of promoting regional diversity in Koha, we have sometimes considered rules against selecting KohaCon proposals from the same region successively in case the most populous regions might come to excessively dominate voting for selecting a proposal, but in practise such rules may not have yet been necessary.] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you need more information about editing MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
[Koha] Add a proposal for hosting KohaCon15
Anyone who would like to host KohaCon15 (international Koha conference to be held in 2015) should add some brief information about their proposal to the proposals summary table in the page on the Koha Wiki which I have prepared following the model used for previous KohaCons, http://wiki.koha-community.org/wiki/KohaCon15_Proposals . Please link your summary proposal to a more detailed proposal preferably in a new page on the Koha wiki or alternately hosted on your own webserver. If you have submitted a proposal for hosting KohaCon in the past but had not been selected, please submit a new proposal if you are interested in hosting KohaCon15. Do not be discouraged that some other proposal had been selected over yours in some previous year. [In the interest of promoting regional diversity in Koha, we have sometimes considered rules against selecting KohaCon proposals from the same region successively in case the most populous regions might come to excessively dominate voting for selecting a proposal, but in practise such rules may not have yet been necessary.] Anyone should be free to add additional relevant information to proposal information in the wiki, such as links and information for local hotel or other accommodations, attractions, etc. We want whatever information may be helpful for linking to a community wide ballot for selecting a particular proposal. As with all wiki content, it should be easy enough to edit by examining the form in which pre-existing content has been entered, when editing to add your own content. If you want more information about MediaWiki tables, see http://www.mediawiki.org/wiki/Help:Tables . Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783 ___ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
