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 n...@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ 2009/5/9 Rachel Hamilton-Williams <rac...@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: rac...@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 > > _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
