I agree with Tom's points. I want OpenLibrary's code to live on and be maintained, since it continues to be useful even outside the context of openlibrary.org. I don't know the details, but even if the project were to be de-funded to the point where openlibrary.org went down, it doesn't cost any money to maintain a library of code on github, as long as people are willing to put in the time to work on it.
I'm really interested in the bookreader JavaScript code. Can I help maintain this library? Which of these repositories is the canonical one? * https://github.com/internetarchive/bookreader * https://github.com/openlibrary/bookreader Also, regarding the 4 years of unreviewed pull requests for this library, I have time to review these if no one else does. My github username is nikolas. On Tue, Jan 19, 2016 at 12:10 PM, Tom Morris <tfmor...@gmail.com> wrote: > I'm disappointed that no OpenLibrary or Internet Archive staff ever replied > to this thread. I guess that shows where community communication ranks in > the priority scheme of things. > > Below are some comments on the replies from Karen and Charles (thanks for > taking the time to reply!). Perhaps reviving the thread will stimulate > discussion. > > On Mon, Aug 24, 2015 at 5:37 PM, Karen Coyle <kco...@kcoyle.net> wrote: >> >> On 8/24/15 1:57 PM, Tom Morris wrote: >>> >>> What would it take to convince IA/OpenLibrary that a public bug tracker >>> is a critical part of the open source development process? >> >> >> Tom, IMO the issue isn't about bug tracking but staffing and costs. There >> is virtually no staff time dedicated to OL, so the question of being open >> source and tracking bugs is somewhat moot. Even an open source project needs >> to make use of some human time. With the project essentially de-funded, >> having a "crowd sourced" bug list means that the bug list will grow, but few >> bugs will be addressed. It took something like two years to get OL >> re-indexed, and that seems like a no-brainer. >> >> As for it being open source, I'm not sure that is indeed the current >> thinking. Even if it were, it appears to me that the project lacks the tools >> needed to make code contributions possible (e.g. the test capabilities that >> I have mentioned before). Perhaps step one is to clarify whether the project >> is indeed intended to be open source (not just "source code lives in >> github"). That could help us manage expectations. > > > If the intention is for OpenLibrary to abandon it's 7+ year open source > legacy, that would be certainly be a much bigger issue than whether or not > there's a public bug tracker. Having read writings by Aaron, George, and > other early OL leaders, it was certainly my impression that the choice of > being open source was intentional, not an accident, but I could be mistaken. > > Cultivating a vibrant set of open source contributors could actually reduce > funding requirements, improve responsiveness, as well as overall community > engagement. Ben, Charles, and others have already contributed a number of > bug fixes to OpenLibrary. Willingness to promptly review, merge, and deploy > bug fixes would encourage others to contribute and provide a low cost way to > leverage scarce development resources. A recent email highlighted the 4 > years worth (!) of community provide bug fixes which are being ignored at > https://github.com/openlibrary/bookreader/pulls. The first of the epub > issues, which have been around for years and years, finally got addressed > because two community members isolated and fixed the problem. > > Public issue trackers aren't just for the technical community. They also > help give the general OpenLibrary community which provides crowdsourced > metadata insight into the issues which hamper their work and the progress > which is being made to fix them. > > Community engagement drives not only in-kind contributions of programming & > data-entry hours, but also real dollars for things like the recent year end > funding drive. Engaged communities contribute more in all dimensions. > Disconnected and disenfranchised communities don't contribute in any way. > > Grant writing organization also have a reasonable expectation that the > grantees will conduct themselves in a way aligns with their publicly stated > values and the values that they claim on their grant applications. If > things like transparency, communication, public dissemination of open > knowledge, etc become perceived as buzz words which are paid lip service > rather than core values, it could easily reduce funding levels from granting > organizations. > > On Fri, Sep 18, 2015 at 2:42 AM, Charles Horn <charles.h...@gmail.com> > wrote: >> >> >> Here are my thoughts on the Jira and Github situation, I don't think >> having both is necessarily a sign of a problem in an open source project. > > > I agree. The main problems are that 1) the change was made years ago with > no notice and 2) there's no way to access the canonical issue tracker > (Jira). > >> >> Jira is a tool for tracking employee time spent on projects, development >> velocities and other internal and cross project metrics, not just issue >> tracking. It makes sense to me that the IA would have an internal system to >> track the work they are prioritising for devs who are likely working on many >> things, and not have this open to the public. > > > Jira can be used in lots of way. If it's used to manage scrums as well as > track issues, access to the scrum boards can almost certainly be restricted, > if that's deemed important. Jira also offers all sorts of options for > multiple projects, different security levels, etc. > >> >> I have worked in places where we used Jira extensively and hosted open >> source projects on Github too. There is an extra effort to keep the two in >> sync if there is demand for it, but I think Github is always an appropriate >> place for community raised issues to be tracked, if the project is publicly >> hosted. It is up to IA to manage how that relates back to their internal >> systems. Hopefully community contributions are considered valuable and the >> extra effort of potentially double tracking in separate systems will be >> worth it for IA. > > > There are many different ways that things could be configured and at least a > few of them are likely workable solutions which would provide both a shared > communication space as well as provide for any perceived privacy needs > (although, I must admit, I don't understand the need for secrecy in a > non-profit dedicated to knowledge dissemination). > >> >> Having an idea of IA priorities in regards to Open Library would be >> helpful, as would a clear set of contribution guidelines, but as a community >> we can put forward our own ideas too. > > > Yes, that would be great. As would the ability to provide input into those > priorities (assuming that meeting the needs of the community is a goal at > some level). > > I'd love to hear where the powers that be stand on this stuff. Is there some > kind of edict from on high that prevents communication about plans, > priorities, intentions, anything? > > Tom > > _______________________________________________ > Ol-tech mailing list > ol-tech@archive.org > http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech > Archives: http://www.mail-archive.com/ol-tech@archive.org/ > To unsubscribe from this mailing list, send email to > ol-tech-unsubscr...@archive.org -- Nik Nyby Programmer Columbia University's Center for Teaching and Learning nn...@columbia.edu | (212) 854-7076 _______________________________________________ Ol-tech mailing list ol-tech@archive.org http://mail.archive.org/cgi-bin/mailman/listinfo/ol-tech Archives: http://www.mail-archive.com/ol-tech@archive.org/ To unsubscribe from this mailing list, send email to ol-tech-unsubscr...@archive.org
