Announcing ... New koha.org Website based on Plone
Hi all, We're pleased to announce that we've nearly finished migrating koha.org from Kea to the Plone Content Management System--the new site should be ready to launch by the end of this week. The new website, based on the Plone Content Management System, provides a number of advantages over the old website: 1. User Management -- anyone can sign up and add content to koha.org through the built-in review process. When you create an account and log in, you can begin adding content to koha.org (NOTE: your content will not display on the site until it has been approved by a moderator). Here are some examples of content you can add: * a new library listing on the Showcase page to make your library show up on the map * new Koha event from Events * new Koha news item from News * new documentation in the Documentation area 2. Built-in Translation Facilities -- Plone supports multi-language content as well as a translation interface, which will let us provide information about Koha in more languages, right from koha.org. If you want koha.org available in your language or would like to volunteer to translate koha.org, please send a request to the koha-translate list and we'll make sure to enable that language in the interface and set your account up to enable translations. 3. Documentation Center -- we've imported the Koha 3.0 and 3.2 Manuals, as well as added a host of other documentation types, such as How-tos, Tutorials, FAQ, etc., and anyone can contribute to the documentation through the built-in review process outlined above. NOTE: LibLime will discontinue updates to the Koha Manual from the old liblime domain location, all new Manual updates will be added to the new koha.org site. 4. Showcase section -- highlights Koha users throughout the world utilizing a world map, anyone can add their library using a simple form 5. News and Events -- can now be submitted for approval by any user. We'll be updating the DNS this weekend to launch the website and will alert these lists when the process is complete (the old website will continue to be available at http://old.koha.org). In the meantime, you can check out the new site at http://new.koha.org Many thanks to Tina Burger, Nicole Engard and Clay Fouts for their efforts getting this new site ready, and to Paul Poulain for excellent feedback of our first draft. If you'd like to help out there are still a number of things that can be done. For instance, we need help going through the archive of news items on the Kea-based koha.org and adding those to Plone so we don't lose that history. Also, please add your library (or libraries you support) to the new Koha world map. Any volunteers? Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
The work new website design is attractive much in keeping with the former design. Plone is great and has some man years of development sophistication as an advantage over the simple easy to implement design of Kea. Some good work has been put into the new website. However, there are some significant problems which should delay the launch of the new website until they are resolved. This message reads as announcement of what will happen when it should actually have been announcement of a development proposal for community comment. I understand that a few people had seen the development work already but it has been evident to me from merely a few minutes examination that there are some very serious bugs. I also understand that no consensus amongst those developers who had already seen the new website had been reached for at least some important parts of the new website. I strongly recommend delaying the launch of the new website until a satisfactory level of bug fixing has been completed and real consensus has been established even about some contentious pages. I have not yet had time to file the bugs in Bugzilla but that should not be an indication that the bugs are not real. 1. LOCALISATION. Good localisation support is one the advantages of Plone. Yet the French translation is highly incomplete and there may be some design mistakes for how Plone has been implemented which may prevent localisation from working properly. Proper localisation requires preparation for localisation from the beginning. I find no link to koha-fr.org where at least French localisation works. 2. KOHA WORLD MAP. I am very pleased to see the return of a Koha world map. I was quite sad that feature had been lost when migrating to Kea. The word 'showcase' has never been obviously understood but the Koha map conveys a more appropriate meaning for showcase than the previous use for Koha demonstrations. There seem to be many functionality bugs which may be related to JavaScript problems in how Google maps has been used. The actual number of libraries included currently gives a poor inaccurate impression of Koha. The map had been woefully out of date four years ago but gave a much better representation of the distribution of Koha four years ago than the current world map gives now. I hope that libraries will actively populate it. 3. ORGANISATIONAL PROBLEMS. 3.1. DEMONSTRATION. The demonstration links are broken because demonstrations had formerly been linked from showcase which is now more appropriately the Koha world map. Demonstrations are now listed in a links subsection of documentation which does not seem to be an appropriate location to me. Demonstrations require significant work to maintain and update but some considerations to other problems suggests the need to have demonstrations as part of koha.org. The good communitarian example of having demonstrations on the general organisation website has been set by for French demonstrations at koha-fr.org. The case of merely linking to demonstrations hosted on individual support company websites as koha.org has done for English demonstrations should be discontinued, although, having such links as well is probably good. I make no suggestion that the launch of the new website be delayed specifically for a problem which has never been corrected on the current website. 3.2. PAY FOR SUPPORT. The pay for support page no longer seems as communitarian as it should. Attribution for contributions to Koha is very important but there should be an appropriate place to see the contributions of participants in the project. The heavy weighting given on that page to LibLime and BibLibre detracts somewhat from the expectation that everyone will contribute well to the Koha community. The pay for support page would not have enough space to provide the most helpful and fair presentation of such information. I suggest linking to a very detailed page or set of pages of contributions instead of including such information in the manner in which it is now presented on the pay for support page. I hope that the Koha history would merely inform such an attributions page or pages. An analytically arranged document showing the creation and major contributions to features etc. should be used. Linking to such more complete attributions for credits in Koha itself would also be good. The fantastic contributions of LibLime and BibLibre to Koha would be even more obvious in such a document but there would be space to give everyone due acknowledgement. Linking to a more complete attribution document will also avoid the greatest problem present in the new page which has been the source of some controversy recently. The presentation as it now stands violates a principle of the Koha community guidelines of trying to avoid the appearance of any particular Koha support company seeming more official than any other. 3.2.1. ORDERING OF PAY FOR SUPPORT. The ordering of listings on the page has been changed from the arbitrary alphabet to a less arbitrary but incorrectly specified historical ordering. I suggest providing links to various ordering arrangements and allow visitors to the website to choose which arrangement to view. In any historical arrangement, the historical order should be correctly specified as I explain below. 3.2.1.1. ORGANISATIONAL SCHEMES. Commenting in library science terms: 3.2.1.1.1. ALPHABETICAL. Alphabetical arrangement has been the default ordering scheme. The alphabet is not a rational organisational scheme because it is strictly arbitrary by the happenstance of the placement of letters. It has the virtue of being universally understood. The arbitrary has the possibility of seeming fair by being impartial but fairness is not a necessary consequence of arbitrary impartiality. Trade naming choices can also be taken to ensure early placement in alphabetical ordering and undue fairness but we have not seen that problem in the Koha community. 3.2.1.1.2. HISTORICAL. Historical organisation is the next worst organisational scheme unless the material being organised has an intrinsically historical function. Organising the history of something historically is natural. Organising other aspects of something in an historical manner is inappropriate. In a proper historical presentation, Katipo and Paul Poulain would be listed on their own account even if they would be no longer prominently offering Koha support or now using a different name in business. In such cases, there should be links within the page from Katipo to LibLime and Paul Poulain to BibLibre with appropriate annotations at the origin of the links. "Katipo Koha interests acquired by LibLime" and "Paul Poulain formed BibLibre" would be appropriate annotations. The use of 'grandfathered' is a mistaken use of the expression. 3.2.1.1.3. GEOGRAPHICAL. Geographical organisation is the next worst organisational scheme unless the material being organised has an intrinsically geographical function. Organising the geography of something geographically is natural. Organising other aspects of something in a geographical manner is inappropriate. 3.2.1.1.4. LINGUISTIC. Linguistic organisation is the next worst organisational scheme unless the material being organised has an intrinsically linguistic function. Organising the linguistic aspects of something linguistically is natural. Organising other aspects of something in a linguistic manner is inappropriate. 3.2.1.1.5. RATIONAL SCHEMES AND IRRATIONAL MEASURES. Schemes which are rationally related to the content are the ones about which people often have difficulty agreeing because they reflect a particular view about the organisation of knowledge. Contribution to the code base might be a good rational organisational measure but the number of lines fails to account for the quality or importance of contributions. Steve Ballmer is not someone to whom I look for words of wisdom but he is not wrong about everything. His larger than life persona explaining this issue in the context of OS 2 development is the best moment in a television history of the microcomputer revolution. Riding the bear [part 2] [videorecording]. -- In Triumph of the nerds [videorecording] / written by Bob Cringely ; series producers, John Gau, Stephen Segaller ; series director, Paul Sen ; John Gau Productions and Oregon Public Broadcasting, with RM Associates for Channel 4 and PBS. - 1996 - Based on the book Accidental empires by Bob Cringely.
From the transcript, http://www.pbs.org/nerds/part2.html :
"Steve Ballmer In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS 2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always makes my back just crinkle up at the thought of the whole thing." 4. LAYOUT. I also note some cases where text containing layout elements are too narrow for the content included and text is sloppily spilling out of those elements and overlaps the body element. I have not seen it yet in my brief view but the hazard is that text spilling out of one element will overwrite text in other text containing elements. This problem is evident with standard browser settings for any user. Increasing the text size for disability access would only exacerbate such already existing problems. Plone can be perfectly compliant with disability access rules but implementers need to observe them. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783 On Thu, May 7, 2009 8:12 pm, Joshua Ferraro wrote:
Hi all,
We're pleased to announce that we've nearly finished migrating koha.org from Kea to the Plone Content Management System--the new site should be ready to launch by the end of this week.
[...]
On Fri, May 8, 2009 at 10:57 AM, Thomas Dukleth <kohadevel@agogme.com>wrote:
The work new website design is attractive much in keeping with the former design. Plone is great and has some man years of development sophistication as an advantage over the simple easy to implement design of Kea. Some good work has been put into the new website. However, there are some significant problems which should delay the launch of the new website until they are resolved.
This message reads as announcement of what will happen when it should actually have been announcement of a development proposal for community comment. I understand that a few people had seen the development work already but it has been evident to me from merely a few minutes examination that there are some very serious bugs. I also understand that no consensus amongst those developers who had already seen the new website had been reached for at least some important parts of the new website.
This decision to move to Plone is a widely documented one, it was decided in several official IRC meetings and a Plone skinning contest was announced in January of 2008 on the mailing lists. Subsequently, none of the skins that were developed were accepted by the community, so LibLime paid those developers their awards, and used our inhouse resources to work on a skin that was closer to the existing theme for Kea. Given the amount of work we have had on our plates, we're quite excited to have finally gotten this done so that the Koha community has this enhanced resource to better the community. In particulare, I'm sure that some folks in non-English speaking contexts will be quite keen to start transating as soon as possible so that the Koha website can be used widely around the world.
I strongly recommend delaying the launch of the new website until a satisfactory level of bug fixing has been completed and real consensus has been established even about some contentious pages. I have not yet had time to file the bugs in Bugzilla but that should not be an indication that the bugs are not real.
1. LOCALISATION.
Good localisation support is one the advantages of Plone. Yet the French translation is highly incomplete and there may be some design mistakes for how Plone has been implemented which may prevent localisation from working properly. Proper localisation requires preparation for localisation from the beginning.
I find no link to koha-fr.org where at least French localisation works.
There were no localization options on the old website, so this isn't a blocker. Also, I don't find any links to koha-fr.org on the old koha site either.
2. KOHA WORLD MAP.
I am very pleased to see the return of a Koha world map. I was quite sad that feature had been lost when migrating to Kea.
The word 'showcase' has never been obviously understood but the Koha map conveys a more appropriate meaning for showcase than the previous use for Koha demonstrations. There seem to be many functionality bugs which may be related to JavaScript problems in how Google maps has been used.
The actual number of libraries included currently gives a poor inaccurate impression of Koha. The map had been woefully out of date four years ago but gave a much better representation of the distribution of Koha four years ago than the current world map gives now. I hope that libraries will actively populate it.
As do I. This is not a blocker for site launch either.
3. ORGANISATIONAL PROBLEMS.
3.1. DEMONSTRATION.
The demonstration links are broken because demonstrations had formerly been linked from showcase which is now more appropriately the Koha world map. Demonstrations are now listed in a links subsection of documentation which does not seem to be an appropriate location to me.
Demonstrations require significant work to maintain and update but some considerations to other problems suggests the need to have demonstrations as part of koha.org. The good communitarian example of having demonstrations on the general organisation website has been set by for French demonstrations at koha-fr.org. The case of merely linking to demonstrations hosted on individual support company websites as koha.org has done for English demonstrations should be discontinued, although, having such links as well is probably good. I make no suggestion that the launch of the new website be delayed specifically for a problem which has never been corrected on the current website.
The demo links are working fine for me, can you specify where exactly you are seeing broken links?
3.2. PAY FOR SUPPORT.
The pay for support page no longer seems as communitarian as it should.
Attribution for contributions to Koha is very important but there should be an appropriate place to see the contributions of participants in the project. The heavy weighting given on that page to LibLime and BibLibre detracts somewhat from the expectation that everyone will contribute well to the Koha community. The pay for support page would not have enough space to provide the most helpful and fair presentation of such information. I suggest linking to a very detailed page or set of pages of contributions instead of including such information in the manner in which it is now presented on the pay for support page.
I hope that the Koha history would merely inform such an attributions page or pages. An analytically arranged document showing the creation and major contributions to features etc. should be used. Linking to such more complete attributions for credits in Koha itself would also be good. The fantastic contributions of LibLime and BibLibre to Koha would be even more obvious in such a document but there would be space to give everyone due acknowledgement.
Linking to a more complete attribution document will also avoid the greatest problem present in the new page which has been the source of some controversy recently. The presentation as it now stands violates a principle of the Koha community guidelines of trying to avoid the appearance of any particular Koha support company seeming more official than any other.
3.2.1. ORDERING OF PAY FOR SUPPORT.
The ordering of listings on the page has been changed from the arbitrary alphabet to a less arbitrary but incorrectly specified historical ordering. I suggest providing links to various ordering arrangements and allow visitors to the website to choose which arrangement to view. In any historical arrangement, the historical order should be correctly specified as I explain below.
3.2.1.1. ORGANISATIONAL SCHEMES.
Commenting in library science terms:
3.2.1.1.1. ALPHABETICAL.
Alphabetical arrangement has been the default ordering scheme. The alphabet is not a rational organisational scheme because it is strictly arbitrary by the happenstance of the placement of letters. It has the virtue of being universally understood. The arbitrary has the possibility of seeming fair by being impartial but fairness is not a necessary consequence of arbitrary impartiality. Trade naming choices can also be taken to ensure early placement in alphabetical ordering and undue fairness but we have not seen that problem in the Koha community.
3.2.1.1.2. HISTORICAL.
Historical organisation is the next worst organisational scheme unless the material being organised has an intrinsically historical function. Organising the history of something historically is natural. Organising other aspects of something in an historical manner is inappropriate.
In a proper historical presentation, Katipo and Paul Poulain would be listed on their own account even if they would be no longer prominently offering Koha support or now using a different name in business. In such cases, there should be links within the page from Katipo to LibLime and Paul Poulain to BibLibre with appropriate annotations at the origin of the links. "Katipo Koha interests acquired by LibLime" and "Paul Poulain formed BibLibre" would be appropriate annotations. The use of 'grandfathered' is a mistaken use of the expression.
3.2.1.1.3. GEOGRAPHICAL.
Geographical organisation is the next worst organisational scheme unless the material being organised has an intrinsically geographical function. Organising the geography of something geographically is natural. Organising other aspects of something in a geographical manner is inappropriate.
3.2.1.1.4. LINGUISTIC.
Linguistic organisation is the next worst organisational scheme unless the material being organised has an intrinsically linguistic function. Organising the linguistic aspects of something linguistically is natural. Organising other aspects of something in a linguistic manner is inappropriate.
3.2.1.1.5. RATIONAL SCHEMES AND IRRATIONAL MEASURES.
Schemes which are rationally related to the content are the ones about which people often have difficulty agreeing because they reflect a particular view about the organisation of knowledge. Contribution to the code base might be a good rational organisational measure but the number of lines fails to account for the quality or importance of contributions.
Steve Ballmer is not someone to whom I look for words of wisdom but he is not wrong about everything. His larger than life persona explaining this issue in the context of OS 2 development is the best moment in a television history of the microcomputer revolution. Riding the bear [part 2] [videorecording]. -- In Triumph of the nerds [videorecording] / written by Bob Cringely ; series producers, John Gau, Stephen Segaller ; series director, Paul Sen ; John Gau Productions and Oregon Public Broadcasting, with RM Associates for Channel 4 and PBS. - 1996 - Based on the book Accidental empires by Bob Cringely.
From the transcript, http://www.pbs.org/nerds/part2.html :
"Steve Ballmer In IBM there's a religion in software that says you have to count K-LOCs, and a K-LOC is a thousand line of code. How big a project is it? Oh, it's sort of a 10K-LOC project. This is a 20K-LOCer. And this is 5OK-LOCs. And IBM wanted to sort of make it the religion about how we got paid. How much money we made off OS 2, how much they did. How many K-LOCs did you do? And we kept trying to convince them - hey, if we have - a developer's got a good idea and he can get something done in 4K-LOCs instead of 20K-LOCs, should we make less money? Because he's made something smaller and faster, less KLOC. K-LOCs, K-LOCs, that's the methodology. Ugh anyway, that always makes my back just crinkle up at the thought of the whole thing."
This is not an issue that can easily be resolved unfortunately and the koha-manage group decided to list by date of entry rather than the above ideas.
4. LAYOUT.
I also note some cases where text containing layout elements are too narrow for the content included and text is sloppily spilling out of those elements and overlaps the body element. I have not seen it yet in my brief view but the hazard is that text spilling out of one element will overwrite text in other text containing elements. This problem is evident with standard browser settings for any user.
Please detail these issues and provide some suggestions for fixes to the CSS if you can and we'll do our best to update.
Increasing the text size for disability access would only exacerbate such already existing problems. Plone can be perfectly compliant with disability access rules but implementers need to observe them.
If you notice, there is an 'accessibility' link which should address this concern. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Joshua Ferraro <jmf@liblime.com> wrote:
There were no localization options on the old website, so this isn't a blocker. Also, I don't find any links to koha-fr.org on the old koha site either.
It's definitely linked from Discussions on the old koha site (but apparently the link is currently broken. I'll go fix it). Bizarrely, the "Discussions" page is missing from the new site and changing hostname to new.koha.org on the old URL results in 404 Not Found. Please can we keep old page locations even if the logical structure has changed? Remember, Cool URIs Don't Change http://www.w3.org/Provider/Style/URI But, revenons a nos moutons, it's correct that there weren't any localization options on koha.org before, so most Francophones probably go direct to koha-fr now. If we've koha.org in other languages, it'll probably need better links to relevant local sites.
3.2.1. ORDERING OF PAY FOR SUPPORT. [...] This is not an issue that can easily be resolved unfortunately and the koha-manage group decided to list by date of entry rather than the above ideas.
It was suggested, along with other changes, but no consensus was reached and after months of silence, suddenly it's all a rushed launch for some unknown-to-me reason. I didn't think about multiple versions (too blinkered by what we'd got to think of radical best practice in the time I had available). I'm open to making a reorderable searchable listing if that can be done easily in Plone. I've not used a good Plone for years, so I don't remember how to do such things. Any tips from Plone users?
[...] Plone can be perfectly compliant with disability access rules but implementers need to observe them.
If you notice, there is an 'accessibility' link which should address this concern.
That looks like the Plone boilerplate. new.koha.org does not yet comply even with what's currently stated there. Hope that helps, -- MJ Ray (slef) Webmaster for hire, statistician and online shop builder for a small worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/ (Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
On Fri, May 8, 2009 at 12:17 PM, MJ Ray <mjr@phonecoop.coop> wrote:
Joshua Ferraro <jmf@liblime.com> wrote:
There were no localization options on the old website, so this isn't a blocker. Also, I don't find any links to koha-fr.org on the old koha site either.
It's definitely linked from Discussions on the old koha site (but apparently the link is currently broken. I'll go fix it).
Bizarrely, the "Discussions" page is missing from the new site and changing hostname to new.koha.org on the old URL results in 404 Not Found. Please can we keep old page locations even if the logical structure has changed? Remember, Cool URIs Don't Change http://www.w3.org/Provider/Style/URI
This is an excellent idea. Do you have a list of URIs from the old website that you'd like mapped to the new site, preferably in a mod_apache format so we can just drop them into place? That would be an outstanding contribution to this effort.
But, revenons a nos moutons, it's correct that there weren't any localization options on koha.org before, so most Francophones probably go direct to koha-fr now. If we've koha.org in other languages, it'll probably need better links to relevant local sites.
Paul and HDL can let us know whether they want to redirect koha-fr.org to koha.org with an FR localization. Guys, any thoughts?
3.2.1. ORDERING OF PAY FOR SUPPORT. [...] This is not an issue that can easily be resolved unfortunately and the koha-manage group decided to list by date of entry rather than the above ideas.
It was suggested, along with other changes, but no consensus was reached and after months of silence, suddenly it's all a rushed launch for some unknown-to-me reason.
I didn't think about multiple versions (too blinkered by what we'd got to think of radical best practice in the time I had available). I'm open to making a reorderable searchable listing if that can be done easily in Plone. I've not used a good Plone for years, so I don't remember how to do such things. Any tips from Plone users?
[...] Plone can be perfectly compliant with disability access rules but implementers need to observe them.
If you notice, there is an 'accessibility' link which should address this concern.
That looks like the Plone boilerplate. new.koha.org does not yet comply even with what's currently stated there.
Can you give some specific examples of problems that need to be solved please? We'll certainly do our best. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Reply inline: On Fri, May 8, 2009 3:20 pm, Joshua Ferraro wrote: [...]
This decision to move to Plone is a widely documented one
[...] I knew about the decision to move to Plone and supported that move myself years earlier. My complaint is mainly about how it is implemented where there has been no open community discussion. I find some structural and content problems. The CSS is very attractive except for some layout problems I discovered. The CSS design of the current koha.org site has long been considered quite attractive. This design is a good match for that one.
In particulare, I'm sure that some folks in non-English speaking contexts will be quite keen to start transating as soon as possible so that the Koha website can be used widely around the world.
I am concerned that poor planning may have left some elements such as navigation links untranslatable. I may be entirely mistaken. The proof would be in the testing but what I see already translated leaves me in some doubt. [...]
There were no localization options on the old website, so this isn't a blocker.
If some localisation could not be done because of poor planning that should be a blocker.
Also, I don't find any links to koha-fr.org on the old koha site either.
There are some references but no proper links to koha-fr.org as a French localised site in the way which there had been at one time. The koha-fr.org site has been functioning as a community website for the Koha French language community even if it may have once been less communitarian. [...]
2. KOHA WORLD MAP.
[...]
There seem to be many functionality bugs which may be related to JavaScript problems in how Google maps has been used.
There are some significant bugs for the map function but they should not be considered blocking. This is a feature which had been lost after all.
The actual number of libraries included currently gives a poor inaccurate impression of Koha. The map had been woefully out of date four years ago but gave a much better representation of the distribution of Koha four years ago than the current world map gives now. I hope that libraries will actively populate it.
As do I. This is not a blocker for site launch either.
I agree that nothing which I have seen about the map should be considered a blocker. [...]
3. ORGANISATIONAL PROBLEMS.
3.1. DEMONSTRATION.
The demonstration links are broken because demonstrations had formerly been linked from showcase which is now more appropriately the Koha world map. Demonstrations are now listed in a links subsection of documentation which does not seem to be an appropriate location to me.
[...]
The demo links are working fine for me, can you specify where exactly you are seeing broken links?
The link from the main page to demonstrations still points to the page for demonstrations which is no longer being used for that purpose in the new organisation, http://new.koha.org/showcase/ . However, I contend that the demonstrations do not belong as a subsection of documentation, http://new.koha.org/documentation/link/koha-demos , although, they should also be linked from documentation. Other things seem inappropriately placed in documentation even if they should also be linked from documentation. The new organisation is liable to present a difficulty for users finding some material when it should do the opposite. [...]
3.2. PAY FOR SUPPORT.
The pay for support page no longer seems as communitarian as it should.
[...]
Linking to a more complete attribution document will also avoid the greatest problem present in the new page which has been the source of some controversy recently. The presentation as it now stands violates a principle of the Koha community guidelines of trying to avoid the appearance of any particular Koha support company seeming more official than any other.
3.2.1. ORDERING OF PAY FOR SUPPORT.
The ordering of listings on the page has been changed from the arbitrary alphabet to a less arbitrary but incorrectly specified historical ordering. I suggest providing links to various ordering arrangements and allow visitors to the website to choose which arrangement to view. In any historical arrangement, the historical order should be correctly specified as I explain below.
3.2.1.1. ORGANISATIONAL SCHEMES.
[...]
3.2.1.1.2. HISTORICAL.
Historical organisation is the next worst organisational scheme unless the material being organised has an intrinsically historical function. Organising the history of something historically is natural. Organising other aspects of something in an historical manner is inappropriate.
In a proper historical presentation, Katipo and Paul Poulain would be listed on their own account even if they would be no longer prominently offering Koha support or now using a different name in business. In such cases, there should be links within the page from Katipo to LibLime and Paul Poulain to BibLibre with appropriate annotations at the origin of the links. "Katipo Koha interests acquired by LibLime" and "Paul Poulain formed BibLibre" would be appropriate annotations. The use of 'grandfathered' is a mistaken use of the expression.
This is not an issue that can easily be resolved unfortunately and the koha-manage group decided to list by date of entry rather than the above ideas.
When a lack of consensus is present, then the Koha community should solve the problem in the wonderful communitarian way it always has in the software. Provide a system preference and let the users choose. The equivalent to a system preference for this problem on the website should be different pages with different ordering of the information which the user can select to suit the user's interests. I understand that historical presentation had been suggested but that presentation should then actually be historical. See the section above quoted from my previous post and additionally in my previous post for how to correct the problem. This particular problem has been much too contentious to be considered anything other than a blocker until resolved.
4. LAYOUT.
I also note some cases where text containing layout elements are too narrow for the content included and text is sloppily spilling out of those elements and overlaps the body element. I have not seen it yet in my brief view but the hazard is that text spilling out of one element will overwrite text in other text containing elements. This problem is evident with standard browser settings for any user.
Please detail these issues and provide some suggestions for fixes to the CSS if you can and we'll do our best to update.
I need to investigate further but I noticed the layout problem immediately when looking at the news or events pages. I do not find the problem at the moment. Maybe it has been fixed already or too much playing with the website has cached the wrong CSS in my web browser.
Increasing the text size for disability access would only exacerbate such already existing problems. Plone can be perfectly compliant with disability access rules but implementers need to observe them.
If you notice, there is an 'accessibility' link which should address this concern.
I assume that you do not mean the section 508 or WCAG links. Which link do you mean? [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com 212-674-3783
2009/5/9 Eric Bégin <Eric.Begin@inlibro.com>:
Hi,
First, I want to raise my hat to LibLime team for the new website.
Yes me too.
I also want to thanks Thomas for the time he spent to analyse the new site and for bringing those worth to discuss points.
Definitely, also I would like to thank you and MJ for your input also.
Here is, briefly, my comments.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I agree it should be vendor independent. And I also agree with the suggestion to have a separate page detailing contributions. Chris
I'm going to put in a ME Too to agree with Eric. The new site is lovely. However, the site really needs to be vendor independent or small libraries are going to turn away under the impression that they need to use a vendor to install and use the software. As for contributions, I think Eric is correct that contributions by a paid company should be attributed to the people who actually paid for them. Perhaps something that states the contribution was paid for by ... and programming/development by ... One quick CSS fix...the documentation link in the top tabs overruns the right hand line. Thanx. Lenora StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
Chris Cormack <chris@bigballofwax.co.nz> 5/8/2009 2:21 PM >>> 2009/5/9 Eric Bégin <Eric.Begin@inlibro.com>: Hi,
First, I want to raise my hat to LibLime team for the new website.
Yes me too.
I also want to thanks Thomas for the time he spent to analyse the new
site
and for bringing those worth to discuss points.
Definitely, also I would like to thank you and MJ for your input also.
Here is, briefly, my comments.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I agree it should be vendor independent. And I also agree with the suggestion to have a separate page detailing contributions. Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
On Fri, May 8, 2009 at 4:04 PM, Eric Bégin <Eric.Begin@inlibro.com> wrote:
Hi,
First, I want to raise my hat to LibLime team for the new website.
I also want to thanks Thomas for the time he spent to analyse the new site and for bringing those worth to discuss points.
Here is, briefly, my comments.
1. LOCALISATION If we do not make the French (France) link point to koha-fr.org, I strongly recommand to remove it until the french version of the site is almost completed.
Unfortunately, that link is there strictly to allow changing the language of the website from English to French, and any other translation that is added will show up as a link just like the French/English ones. So disabling the language would remove the possibility of translation, that's just how Plone works AFAIK.
3. DEMONSTRATION I'm aware that the demo site are maintained by LL team, however, since this is a demo for the community, wouldn't be faire to remove any reference to LL in the demo site? This includes the username/password, logo and name. As Thomas mentionned, it would also be nice if the URLs were using the same approach as the koha-fr site, I means something@koha.org By the way, I just tried the demo site and here what I noted: - can not log on the intranet using liblime/liblime at the moment (both public and academic)
The liblime user was deleted by someone who logged into the academic demo as the liblime user ... These demos refresh on a daily basis so the problem would have resolved itself by morning, but in any event, its fixed now. The public demo appears to be working fine.
- there is a 404 when we click Catalogue in the public demo
Yep, that's a broken link, but its otherwise fine. BTW: nothing has changed with this Plone site with respect to how we demonstrate Koha ... LibLime has been faithfully providing stable, public, free, demos for the community for years. So that's nothing new and I'm not sure how it relates to the website update.
3.2 PAY FOR SUPPORT
Support companies are listed by the date they joined the Koha community.
I really don't want to remove any credits to LibLime or BibLibre. You guys are doing awesome job. However, I'm a bit confused about the contribution part.
As far as I can tell, a contribution should be something that the company as paid or provide the ressource to do something. Features developped for and paid by a client shouldn't be considered as a contribution.
Has contributed over 55% of the entire Koha codebase, including the integration of Koha and Zebra Has contributed over 35% of the entire Koha codebase Was the developpment payed by a client? If so, the client should be credited for the integrations/development, not LibLime... does it make sense?
Well, I can't speak for BibLibre, but LibLime does not get paid by clients to contribute back to the Koha community. We don't get paid to maintain those contributions. We don't get paid by clients to write and maintain the free documentation we've maintained for the community, and we don't get paid by clients to hold time-consuming official Koha positions such as Release Manager, Translation Manager and Documentation Manager. LibLime pays those expenses ourselves at considerable cost to us. Many of the Koha vendors listed on the support page do not contribute 100% of the code they write for customers to the community, and we've learned over the past fwew years that in some cases this is due to them not being paid for that effort, and in other cases, its a deliberate attempt to proprietize components of the services they offer. LibLime has, from our inception in 2005, contributed back 100% of the code we've created because we believe in the community process and we strive to set an example for other support organizations. Listing notable contributions by vendors on the support page where applicable is additional incentive for vendors to get more actively involved in contribution. Its important that libraries selecting support options know the roles that their support provider is playing in the community.
In March 2007, LibLime acquired the Koha division of Katipo Communications, Ltd., the original developers of Koha 1.0. Not really a contribution... This is marketing stuff and shoud stay on LibLime website.
That is not meant to be a marketing statement, but rather an explanation of LibLime's listing having been grandfathered from Katipo's Koha Division, which could be confusing to first-time visitors.
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
Here some broken links that I found on the new (now current) web site.
www.koha.org (with www) bring a Zope Quick Start Page... In the footer: LibLime Link Support » Free Support » Koha Mailing List Documentation » Reference Manual » Koha 3.0 or Koha 3.2 » All content on one page... It takes a long time to load and after a while, it request to log on our Google Account...
Very helpful, thanks we'll try to locate and fix these asap. Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
2009/5/9 Joshua Ferraro <jmf@liblime.com>:
3.2 PAY FOR SUPPORT
Support companies are listed by the date they joined the Koha community.
I really don't want to remove any credits to LibLime or BibLibre. You guys are doing awesome job. However, I'm a bit confused about the contribution part.
As far as I can tell, a contribution should be something that the company as paid or provide the ressource to do something. Features developped for and paid by a client shouldn't be considered as a contribution.
Has contributed over 55% of the entire Koha codebase, including the integration of Koha and Zebra Has contributed over 35% of the entire Koha codebase Was the developpment payed by a client? If so, the client should be credited for the integrations/development, not LibLime... does it make sense?
Well, I can't speak for BibLibre, but LibLime does not get paid by clients to contribute back to the Koha community. We don't get paid to maintain those contributions. We don't get paid by clients to write and maintain the free documentation we've maintained for the community, and we don't get paid by clients to hold time-consuming official Koha positions such as Release Manager, Translation Manager and Documentation Manager. LibLime pays those expenses ourselves at considerable cost to us.
Many of the Koha vendors listed on the support page do not contribute 100% of the code they write for customers to the community, and we've learned over the past fwew years that in some cases this is due to them not being paid for that effort, and in other cases, its a deliberate attempt to proprietize components of the services they offer.
LibLime has, from our inception in 2005, contributed back 100% of the code we've created because we believe in the community process and we strive to set an example for other support organizations.
Listing notable contributions by vendors on the support page where applicable is additional incentive for vendors to get more actively involved in contribution. Its important that libraries selecting support options know the roles that their support provider is playing in the community.
I'm not going to answer this until I have calmed down enough to not go into flame mode. I do find it highly insulting to the rest of the community who are not liblime though.
In March 2007, LibLime acquired the Koha division of Katipo Communications, Ltd., the original developers of Koha 1.0. Not really a contribution... This is marketing stuff and shoud stay on LibLime website.
That is not meant to be a marketing statement, but rather an explanation of LibLime's listing having been grandfathered from Katipo's Koha Division, which could be confusing to first-time visitors.
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
The community is what the community decides it should be. Chris
2009/5/8 Chris Cormack <chris@bigballofwax.co.nz>
2009/5/9 Joshua Ferraro <jmf@liblime.com>:
3.2 PAY FOR SUPPORT
Support companies are listed by the date they joined the Koha community.
I really don't want to remove any credits to LibLime or BibLibre. You guys are doing awesome job. However, I'm a bit confused about the contribution part.
As far as I can tell, a contribution should be something that the
company
as paid or provide the ressource to do something. Features developped for and paid by a client shouldn't be considered as a contribution.
Has contributed over 55% of the entire Koha codebase, including the integration of Koha and Zebra Has contributed over 35% of the entire Koha codebase Was the developpment payed by a client? If so, the client should be credited for the integrations/development, not LibLime... does it make sense?
Well, I can't speak for BibLibre, but LibLime does not get paid by clients to contribute back to the Koha community. We don't get paid to maintain those contributions. We don't get paid by clients to write and maintain the free documentation we've maintained for the community, and we don't get paid by clients to hold time-consuming official Koha positions such as Release Manager, Translation Manager and Documentation Manager. LibLime pays those expenses ourselves at considerable cost to us.
Many of the Koha vendors listed on the support page do not contribute 100% of the code they write for customers to the community, and we've learned over the past fwew years that in some cases this is due to them not being paid for that effort, and in other cases, its a deliberate attempt to proprietize components of the services they offer.
LibLime has, from our inception in 2005, contributed back 100% of the code we've created because we believe in the community process and we strive to set an example for other support organizations.
Listing notable contributions by vendors on the support page where applicable is additional incentive for vendors to get more actively involved in contribution. Its important that libraries selecting support options know the roles that their support provider is playing in the community.
I'm not going to answer this until I have calmed down enough to not go into flame mode. I do find it highly insulting to the rest of the community who are not liblime though.
Certainly not my intent to insult anyone, nor to start a flame war, appologies if I've done so. I think LibLime's record speaks for itself on this matter, we've given everything we have to this community.
In March 2007, LibLime acquired the Koha division of Katipo Communications, Ltd., the original developers of Koha 1.0. Not really a contribution... This is marketing stuff and shoud stay on LibLime website.
That is not meant to be a marketing statement, but rather an explanation
of
LibLime's listing having been grandfathered from Katipo's Koha Division, which could be confusing to first-time visitors.
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
Please don't re-write history.
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical
order
is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
The community is what the community decides it should be.
I'm not sure I understand what you mean, Chris, could you explain? Do you mean to imply that the Koha community is not a meritocracy? Koha, like the Apache community has always represented 'Meritocracy in Action!' from my POV. Cheers, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
Please don't re-write history.
What? So I do still work for liblime? I didn't resign? Wow, i guess im owed a pile of backpay then. I'm not sure what you mean here, it's totally accurate that neither Russel, Mason or I work for liblime, and havent since april last year.
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
The community is what the community decides it should be.
I'm not sure I understand what you mean, Chris, could you explain? Do you mean to imply that the Koha community is not a meritocracy? Koha, like the Apache community has always represented 'Meritocracy in Action!' from my POV.
I mean that no one person gets to decide what this community does, or how it decides things. Chris
2009/5/8 Chris Cormack <chris@bigballofwax.co.nz>
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
Please don't re-write history.
What? So I do still work for liblime? I didn't resign? Wow, i guess im owed a pile of backpay then. I'm not sure what you mean here, it's totally accurate that neither Russel, Mason or I work for liblime, and havent since april last year.
It is not, however, accurate that the three of you 'left liblime'. I'd strongly recommend against public discussion of your record as an employee at LibLime and the circumstances of your departure, not to mention the record or departure of any other of LibLime's employees. You're clearly upset about something Chris, but please don't dampen the hundreds of hours of effort that some of us have invested in this website launch over the past few months. Cheers, Josh
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
The community is what the community decides it should be.
I'm not sure I understand what you mean, Chris, could you explain? Do you mean to imply that the Koha community is not a meritocracy? Koha, like the Apache community has always represented 'Meritocracy in Action!' from my POV.
I mean that no one person gets to decide what this community does, or how it decides things.
Chris
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
2009/5/9 Joshua Ferraro <jmf@liblime.com>:
2009/5/8 Chris Cormack <chris@bigballofwax.co.nz>
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
Please don't re-write history.
What? So I do still work for liblime? I didn't resign? Wow, i guess im owed a pile of backpay then. I'm not sure what you mean here, it's totally accurate that neither Russel, Mason or I work for liblime, and havent since april last year.
It is not, however, accurate that the three of you 'left liblime'. I'd strongly recommend against public discussion of your record as an employee at LibLime and the circumstances of your departure, not to mention the record or departure of any other of LibLime's employees.
Ok, let me rephrase the 3 of us no longer work for liblime. I resigned from Liblime, I'm happy for that to be on public record. Mason and Russel can speak for themselves. As far as my resignation was concerned, that's all there is to it, I resigned. Do not threaten me please. I also have nothing to do with the departure of any subsequent employees. Do I understand that you are saying I can not comment publicly if someone leaves liblime?
You're clearly upset about something Chris, but please don't dampen the hundreds of hours of effort that some of us have invested in this website launch over the past few months.
Following Lee's suggestion I am going to withdraw from this discussion, It isn't helping anything. Chris
Friends and co conspirators, I like the chronology idea personally, when we migrated we looked for folks out there that had a depth of experience. Also if I sponsor code development I would like credit whether ByWater or Liblime does the work. A "sponsored by" is sufficient. Obviously Koha and support companies are on the right track because there has been an explosion of interest. (poor Sirsi). I think we are not focusing on the real issues that will next be on my agenda and that is what is up with OCLC, Worldcat Local and Quick Start. Koha will outlast OCLC morphing as long as there is some interoperability, but all the folks out there- ready to manage libraries ILSs and CMSs.... ummm I am not buying any stock in their start ups. There needs to be a Koha strategy for development and growth that everyone can reference. The tactics to be successful must support the strategy. We ALL need to look ahead and plan for the future of this amazing collaborative community. Okay the library is closing and I am off for the weekend! WOOHOO. Keep the baby and the bath water! Cheers Lee in Butte Montana! ----- Original Message ----- From: "Chris Cormack" <chris@bigballofwax.co.nz> To: "Joshua Ferraro" <jmf@liblime.com> Cc: <koha-announce@lists.koha.org>; <koha-translate@lists.koha.org>; <kohadevel@agogme.com>; <koha@lists.katipo.co.nz>; <koha-devel@lists.koha.org> Sent: Friday, May 08, 2009 4:20 PM Subject: Re: [Koha] [Koha-translate] [Koha-devel] Announcing ... Newkoha.org Website based on Plone
2009/5/9 Joshua Ferraro <jmf@liblime.com>:
3.2 PAY FOR SUPPORT
Support companies are listed by the date they joined the Koha community.
I really don't want to remove any credits to LibLime or BibLibre. You guys are doing awesome job. However, I'm a bit confused about the contribution part.
As far as I can tell, a contribution should be something that the company as paid or provide the ressource to do something. Features developped for and paid by a client shouldn't be considered as a contribution.
Has contributed over 55% of the entire Koha codebase, including the integration of Koha and Zebra Has contributed over 35% of the entire Koha codebase Was the developpment payed by a client? If so, the client should be credited for the integrations/development, not LibLime... does it make sense?
Well, I can't speak for BibLibre, but LibLime does not get paid by clients to contribute back to the Koha community. We don't get paid to maintain those contributions. We don't get paid by clients to write and maintain the free documentation we've maintained for the community, and we don't get paid by clients to hold time-consuming official Koha positions such as Release Manager, Translation Manager and Documentation Manager. LibLime pays those expenses ourselves at considerable cost to us.
Many of the Koha vendors listed on the support page do not contribute 100% of the code they write for customers to the community, and we've learned over the past fwew years that in some cases this is due to them not being paid for that effort, and in other cases, its a deliberate attempt to proprietize components of the services they offer.
LibLime has, from our inception in 2005, contributed back 100% of the code we've created because we believe in the community process and we strive to set an example for other support organizations.
Listing notable contributions by vendors on the support page where applicable is additional incentive for vendors to get more actively involved in contribution. Its important that libraries selecting support options know the roles that their support provider is playing in the community.
I'm not going to answer this until I have calmed down enough to not go into flame mode. I do find it highly insulting to the rest of the community who are not liblime though.
In March 2007, LibLime acquired the Koha division of Katipo Communications, Ltd., the original developers of Koha 1.0. Not really a contribution... This is marketing stuff and shoud stay on LibLime website.
That is not meant to be a marketing statement, but rather an explanation of LibLime's listing having been grandfathered from Katipo's Koha Division, which could be confusing to first-time visitors.
Maybe then in that case in order to no confuse first time visitors you need to put that the three people hired in that grandfathering have all since left liblime.
the koha-manage group decided to...
What are the factor making for someone to be in the Koha-manage group? There is no mention of such a group on koha.org.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
I respectfully disagree. Listing by date joined is the most vendor-independent and community-focused. Another fair option would be to list in order of contributions, most to least. This community is, after all, a meritocracy :).
The community is what the community decides it should be.
Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
HI All, After some thought, I have a suggestion for how to order the the listings on the pay for page which I hope is both fair, accurate, has longevity, and is useful to the people visiting the page for whom we're providing the info. In the past we've ordered by region and we've ordered alphabetically. At the moment the suggestion is to order by date joined and I don't think that's a good idea (see below for why). FIRST 3-4 PLACES I'd like to propose that the first "3" positions (possibly more but no more than 4), be ordered by current release manager position held in the community, and that after that, depending on how many listings we have, they be ordered by region & alphabetically. I'd like to see the first position on the list be given to the current release manager's company (Lilime ATM). I think that the job of current release manager is huge, and that the company who is currently providing the resources/employment of the release manager deserves all the support and credit we can give, even if they joined yesterday! I agree with Josh that there can seem like not much benefit to being the release manager (or being their boss!), and so this seems to me like a "no brainer". ALSO if I was a library wanting to get some development done then that's the first thing I would want to know, and lets face it, we want to encourage those libraries who DO want development done. The second position on the list would be given to the current release maintainer- ie the release manager for the current stable release (Bib Libre ATM). Again, I think this is a big job, they are still doing a lot of patching, answering a lot of questions on lists and generally putting in a goodly amount of time and effort getting the current release more stable, mostly I'm sure not directly funded. Again I think that supporting the company that is providing the resources for someone to do this job is the least we can do. It again would mean that a library was "buying into" the idea of supporting the current stable release. The third & fourth positions on the list could be to either the immediate past release maintainer (in our case v 2.x - assuming they are a different company), or the next company providing the most tangible support to the community. I think however that we stop this system after the top 3-4 positions, because it is less useful after that. It may be that when there is a KSF (or similar) there are some other positions which because of the amount of work they entail, justify giving this same privileged to their supporting company in which case we can extend it, and have clear rules around it too. I quite like the idea of the immediate past release managers being listed (ie if they have stopped being current and aren't funding another release themselves), because again being release manager is such a big job, I think they deserve recognition beyond their "active term" - and it kinda means they get a guaranteed "cash in" time for all that hard work, even if they need to pass the torch to someone else for the next release and concentrate or just building their own business. REST OF THE LIST THEN thinking about our actual website users, I imagine that what they mostly want is to see who supports their area, so I'd like to see the list split into countries or regions, ordered alphabetically, and with the vendors listed alphabetically within them, including info on contributions, positions held etc, if they are on/members of a KSF or similar. It may be that we get big enough it's worth having the company who supports or is principle sponsor of the local usergroup get first position in that grouping - but that's a bit down the track. WHY - well I think it's easier to read and understand, and to re-find a company that way. It will also make it easier to split up the list into "sane" chunks if it gets to big for one "page". Ie it's pretty easy to have a North America page, a South America page, a European Page, An African page, an Australasian page etc in the future, and will make more sense to the libraries trying to use it I think that having a "started in 2005" page. WHY NOT BY DATE I don't think that date joined is the best way to actually indicate who is a good company (or person) to deal with, and date joined is no inherent indicator of current involvement in a release, or even that the company would be a good choice for getting the current release installed & supported. Katipo is a prime example of why not list by date (Even before selling to Liblime), we had not funded a release manager for a few years, and hadn't as a company been able to afford much official involvement in the project, even though individuals still participated. I don't think that it would be fair particularly, for us to be top of a page when others were doing so much more (and indeed we listed alphabetically in part to avoid that temptation). While at the moment, the longest involved (listed) companies are at the top of the page, I would would like to see us have a policy that effectively achieves the same thing because I think those companies should be at the top of the listings, but is "defensible", and understandable for both libraries and vendors, and that allows for other worthy companies in years to come to also get a spot in the sun if they put in the hard yards like these guys have. Cheers Rachel -- ----------------------------- Rachel Hamilton-Williams General Manager Katipo Communications Ltd Phone: +64-4-934 1285 Mobile: 021 389 128 E-mail: rachel@katipo.co.nz Web: www.katipo.co.nz
I think this sounds extremely fair - but I think we need a bit of an explanation for why companies are listed as such. While the community will understand the ordering - people who are new to open source often have trouble understanding the roles we assign and what that means to the community. I have been altering my 'Intro to Open Source' talks to include community definitions and governance to try and better educate librarians - but I can't be all over the world :) Anyway, my point was that we might want a page explaining the community role in open source and the reason the page is ordered as it is. I also agree that most people are going to want to find support companies based on where their libraries are located. --- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ 2009/5/9 Rachel Hamilton-Williams <rachel@katipo.co.nz>:
HI All,
After some thought, I have a suggestion for how to order the the listings on the pay for page which I hope is both fair, accurate, has longevity, and is useful to the people visiting the page for whom we're providing the info.
In the past we've ordered by region and we've ordered alphabetically. At the moment the suggestion is to order by date joined and I don't think that's a good idea (see below for why).
FIRST 3-4 PLACES
I'd like to propose that the first "3" positions (possibly more but no more than 4), be ordered by current release manager position held in the community, and that after that, depending on how many listings we have, they be ordered by region & alphabetically.
I'd like to see the first position on the list be given to the current release manager's company (Lilime ATM). I think that the job of current release manager is huge, and that the company who is currently providing the resources/employment of the release manager deserves all the support and credit we can give, even if they joined yesterday! I agree with Josh that there can seem like not much benefit to being the release manager (or being their boss!), and so this seems to me like a "no brainer". ALSO if I was a library wanting to get some development done then that's the first thing I would want to know, and lets face it, we want to encourage those libraries who DO want development done.
The second position on the list would be given to the current release maintainer- ie the release manager for the current stable release (Bib Libre ATM). Again, I think this is a big job, they are still doing a lot of patching, answering a lot of questions on lists and generally putting in a goodly amount of time and effort getting the current release more stable, mostly I'm sure not directly funded. Again I think that supporting the company that is providing the resources for someone to do this job is the least we can do. It again would mean that a library was "buying into" the idea of supporting the current stable release.
The third & fourth positions on the list could be to either the immediate past release maintainer (in our case v 2.x - assuming they are a different company), or the next company providing the most tangible support to the community.
I think however that we stop this system after the top 3-4 positions, because it is less useful after that. It may be that when there is a KSF (or similar) there are some other positions which because of the amount of work they entail, justify giving this same privileged to their supporting company in which case we can extend it, and have clear rules around it too.
I quite like the idea of the immediate past release managers being listed (ie if they have stopped being current and aren't funding another release themselves), because again being release manager is such a big job, I think they deserve recognition beyond their "active term" - and it kinda means they get a guaranteed "cash in" time for all that hard work, even if they need to pass the torch to someone else for the next release and concentrate or just building their own business.
REST OF THE LIST
THEN thinking about our actual website users, I imagine that what they mostly want is to see who supports their area, so I'd like to see the list split into countries or regions, ordered alphabetically, and with the vendors listed alphabetically within them, including info on contributions, positions held etc, if they are on/members of a KSF or similar. It may be that we get big enough it's worth having the company who supports or is principle sponsor of the local usergroup get first position in that grouping - but that's a bit down the track.
WHY - well I think it's easier to read and understand, and to re-find a company that way.
It will also make it easier to split up the list into "sane" chunks if it gets to big for one "page". Ie it's pretty easy to have a North America page, a South America page, a European Page, An African page, an Australasian page etc in the future, and will make more sense to the libraries trying to use it I think that having a "started in 2005" page.
WHY NOT BY DATE
I don't think that date joined is the best way to actually indicate who is a good company (or person) to deal with, and date joined is no inherent indicator of current involvement in a release, or even that the company would be a good choice for getting the current release installed & supported.
Katipo is a prime example of why not list by date (Even before selling to Liblime), we had not funded a release manager for a few years, and hadn't as a company been able to afford much official involvement in the project, even though individuals still participated. I don't think that it would be fair particularly, for us to be top of a page when others were doing so much more (and indeed we listed alphabetically in part to avoid that temptation).
While at the moment, the longest involved (listed) companies are at the top of the page, I would would like to see us have a policy that effectively achieves the same thing because I think those companies should be at the top of the listings, but is "defensible", and understandable for both libraries and vendors, and that allows for other worthy companies in years to come to also get a spot in the sun if they put in the hard yards like these guys have.
Cheers Rachel
-- ----------------------------- Rachel Hamilton-Williams General Manager Katipo Communications Ltd
Phone: +64-4-934 1285 Mobile: 021 389 128 E-mail: rachel@katipo.co.nz Web: www.katipo.co.nz
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
2009/5/8 Eric Bégin <Eric.Begin@inlibro.com>
As far as I can tell, a contribution should be something that the company as paid or provide the ressource to do something. Features developped for and paid by a client shouldn't be considered as a contribution.
Was the developpment payed by a client? If so, the client should be credited for the integrations/development, not LibLime... does it make sense?
I realize this section is going to be the point of some discussion, so I am happy to have it. But I do not agree with your logic. The point of the "for pay" support page is to direct users to companies with Koha expertise. If a client paid for a feature, that does not make the client any more able to provide Koha support, or interested in providing it! Most clients too busy running their own libraries to establish financial relationships for Koha support to other users around the world. So this is not a list of "benefactors" or "contributors". Rather it is about people that can help you now. A "History of Koha Features" page would be correct to credit the paying client. Perhaps the confusion results from the historical structure applied to a "koha credentials" problem, as Thomas suggested.
In March 2007, LibLime acquired the Koha division of Katipo Communications, Ltd., the original developers of Koha 1.0. Not really a contribution... This is marketing stuff and shoud stay on LibLime website.
All of the entries on the "for pay" page serve a marketing purpose. Again, I think you are confusing "contribution" in the charitable sense with its usage here, and perhaps more broadly the purpose of a more general "history" or "credits" page with the purpose of this one.
My main point here is that the Koha.org website should be as vendor-independant as possible. I really think that the Alphabetical order is the best way to reach that goal.
Why would chronological order be less informative? It is certainly less volatile (additions only to the tip). I'm not against alphabetical, I just don't see that all other orders are necessarily "vendor dependent". -- Joe Atzberger LibLime - Open Source Library Solutions
participants (10)
-
Chris Cormack -
Eric Bégin -
Joe Atzberger -
Joshua Ferraro -
Lee Phillips -
Lenora Oftedahl -
MJ Ray -
Nicole Engard -
Rachel Hamilton-Williams -
Thomas Dukleth